zitadel/internal/api/grpc/session/v2
Livio Spring aabefb9382
feat(session api): respect lockout policy (#8027)
# Which Problems Are Solved

The session API was designed to be flexible enough for multiple use
cases / login scenarios, where the login could respect the login policy
or not. The session API itself does not have a corresponding policy and
would not check for a required MFA or alike. It therefore also did not
yet respect the lockout policy and would leave it to the login UI to
handle that.
Since the lockout policy is related to the user and not the login
itself, we decided to handle the lockout also on calls of the session
API.

# How the Problems Are Solved

If a lockout policy is set for either password or (T)OTP checks, the
corresponding check on the session API be run against the lockout check.
This means that any failed check, regardless if occurred in the session
API or the current hosted login will be counted against the maximum
allowed checks of that authentication mechanism. TOTP, OTP SMS and OTP
Email are each treated as a separate mechanism.

For implementation:
- The existing lockout check functions were refactored to be usable for
session API calls.
- `SessionCommand` type now returns not only an error, but also
`[]eventstore.Command`
  - these will be executed in case of an error

# Additional Changes

None.

# Additional Context

Closes #7967

---------

Co-authored-by: Elio Bischof <elio@zitadel.com>
2024-05-30 22:08:48 +00:00
..
server.go feat: user v2 service query (#7095) 2024-01-17 10:00:10 +01:00
session_integration_test.go feat(session api): respect lockout policy (#8027) 2024-05-30 22:08:48 +00:00
session_test.go fix(API): remove deprecated organisation_id from user factor in session service (#7631) 2024-03-26 11:25:40 +00:00
session.go feat(session): allow update of session without token (#7963) 2024-05-22 05:56:11 +00:00