v26.3.7
v26.3.7
Force sessions to AAL2 with session.whoami.required_aal
Setting session.whoami.required_aal: aal2 now forces every session to reach AAL2 before it is treated as valid. Users who
already have a second factor are sent through the existing ?aal=aal2 step-up. Users who do not have a second factor are
redirected to the settings flow to enroll one, instead of being silently allowed through.
While a session still owes a second factor, its settings flow becomes enrollment-only: it carries a new UI message (ID 1050024)
telling the user to set up a second factor, offers only the second-factor enrollment methods (TOTP, lookup secrets, and WebAuthn
when configured for MFA), and rejects a submission for any other method. Native and API clients receive a show_settings_ui
continue_with item on the login response and a new error ID session_aal2_enrollment_required alongside the existing
session_aal2_required. The required_aal setting on the settings flow itself is unchanged and still accepts only aal1 or
highest_available.
GET /sessions continues to require the configured AAL, as it did before. DELETE /sessions and DELETE /sessions/{id}
deliberately do not: signing other devices out is what a user needs after losing a second factor, so revocation stays available to
a session that has not yet met the requirement. Such a revocation is recorded in the log with the configured required_aal and
the session's own AAL.