Hi! I have a problem with privileged session in Ory Network. After the user passes 2FA challenge session gets promoted to AAL2. And while I have Privileged Session Lifespan set to 15m it never reverts to AAL1. Other possibly important things: • Total session lifespan is set to 120h • I have password authentication enabled • I have "Allow Login without Second Factor" – enabled and "Allow Self-Service Settings without Second Factor" – disabled • I have Lookup Secrets and TOTP both enabled as a second factor. User uses TOTP as a Second Factor to raise session AAL to 2 • User logs in with email and password • The first time user logs in (registers) via recovery link ◦ We have our custom invitation system on top of Ory with user exchanging invitation token for the one-time recovery link and immediately following it • Also see session JSONs attached (I've downloaded those yesterday) • Yet at the time of the posting both sessions are still at AAL2 Right now I don't understand whether we implemented or configured something wrong, or is it a bug. So any help or advice would be much appreciated!

Hi @busy-pizza-65563 afaik: the assurance level referrers to the session and the associated credentials. Meaning, were both credentials/factors used to authenticate the session (email+password && biometric passkey). I think what you are trying to do is: Use the second factor create/promote a privileged session (sudo mode). We were working on a similar scenario (accelerated/prepopulated ecommerce checkout). From what I recall, you can’t promote an active session to a privileged session. You would create a flow where you sign out and re-sign in the user, after which the privileged sessions begins and demotes to a regular sessions after the defined lifetime (15m). You can use the second factor only (such as passkeys) to sign in the user. At this point the session is aal1 but privileged for 15m. As to distinguish a regular session from a privileged session via the public/admin whoami, I believe this is currently not possible other than comparing the time stamp of when the session has been created with the lifetime of privileged sessions. Or trying to perform the action and receiving a 403. I did talk to the Ory team on adding something to the session to identify privileged session which resulted in this issue. I am not sure (didn’t check) if this is live in Ory network yet. cc @steep-lamp-91158

Hi Thomas! Thanks for the reply! Well, you are mostly correct – you need to request authentication flow, but Ory doesn't log the user out. Instead, it goes straight to the next authentication step and requests 2FA. So after successful authentication, the session is kept all the same but with AAL2 now. That's why it feels like a session promotion. So you don't happen to know by any chance a solution for my use case? I'll describe it in more detail: • user tries to make an action that requires additional authentication • backend app checks session privileges and requests additional authentication • web app initializes the MFA scenario • the user passes the MFA scenario • web app retries action • action is success • user comes back after some time • they can't make any actions that require privileged access Maybe I can lower the session AAL with a hook?

Hey Stanislav, in terms of aal, prompting for the second factor will promote the session to aal2 but conceptually aal2 != privileged. So if a user signs in with both factors he is immediately aal2 and privileged but after 15m the privilege ends but the session is still aal2. I think the most convenient solution for an application developer would be to simply have a flow that promotes any session with either (or both) factor to privileged sessions, perhaps even with a parameter for its lifetime. A property in the session indicating whether a session is privileged or not, would also help to display a prompt for a session promotion in the front end. Alternatively add an option to set a lifetime for aal2 lifetime but not all applications implement 2fa. But this is up to Ory to implement. They might have a better solution.

So instead of checking AAL itself we could look at time difference between the current request and AAL2 challenge completion.

Yes. This is basically how we solved it. But this might be outdated by now or perhaps there is a more elegant solution. $serverTimestamp - $createdAt > $15m ? revoke session via admin api Now the client has to sign in again and the session will be privileged. If your application does not require an active auth session across multiple browsing sessions of the user, you could also make your privileged session the same duration as your regular session (30m for example). This way, every time the user returns, the user will have to sign in again and his session will be privileged in order to perform sensitive actions.

That was really helpful! Thanks a lot, Thomas!

@kind-fireman-77262, thank you for your insightful replies! Appreciate it a lot 🙂