This can replace the store in LoA in session, but neither are the best solution if the use-case is to always for example require an OTP for certain transactions in the application (transfer > $2000 dollars, etc.). The better approach to this is leveraging client policies and require a specific max-age, or re-authentication (maybe with a given level), etc. for a specific client, client scope, or in the future for a authorization type in a RAR request.

@stianst When thinking more abound this, I see one potential issue with relying only on the time of update of the cookie. Consider the use-case like:

1 - password with max-age 60 min
2 - WebAuthn with max-age 10 min

Now consider that potential attacker steal my laptop (together with WebAuthn key, which was attached in USB) and the session is already opened. Attacker will be able to "refresh" the cookie by sending login request every 10 minutes with acr_values=2 . Every login will require attacker to re-authenticate with WebAuthn key, which he is able to do. And every login will refresh SSO cookie and hence will allow attacker to being logged forever without a need to re-login with password.

IMO it will be better to track login time of every level and make sure that particular level is tried at least once per that interval. So for example when re-authenticate every 10 minutes with acr_values=2, it will asks only WebAuthn in first 5 times, but 6th time will ask also for password as last authentication with password was older than 60 minutes.

I consider using userSession note instead of login cookie. The userSession note will track last login time of every level. Hence will be able to detect when exactly should be particular level re-authenticated.

@mposolda I fully agree and that was actually what I had in mind, but perhaps didn't articulate clearly enough. The identity cookie should be valid at a given level since last time that level was verified, not since the time the cookie was created or updated.

Doesn't matter if it's stored in cookie or user session from a behaviour perspective. What I had in mind was that the identity cookie would include additional claims like "level-2-last-verified-at" or something, similar to what the user session would.

Whether or not to store in the cookie or session is more a performance issue. We will want to make sure the user session is updated as infrequently as possible, so if we can track things like max-age, authentication level (including what time each level was verified) in the cookie without having to update the user session that is a good thing. However, we still have the issue with session keep-alive, which is updating the session anyways, so right now storing additional things in user session isn't as bad, but it would be great if we actually didn't need to update the session for the keep-alive feature though.

@stianst Thanks for the clarification. So the only question is if we use cookie or user session?

I see the limitation of cookie is, that it cannot be queried by admin (or user himself). Since we have various Keycloak functionality, which relies on the session last-access-time (EG. Session Idle checker, both admin or account console, newly added session-limits authenticator etc), I am not sure if we can stop saving session keep-alive in the session...

I don't see any issue with saving authentication levels in the cookie itself. As I don't see much use-case in querying authentication levels in the session. Will it be useful for admin or user to see what are the authenticated levels of particular user session? If not, we can probably stick to have authentication levels in the cookie.