Repository navigation
Replies: 2 comments 4 replies
|
A suggestion to an alternative to "store LoA in session" and also on how to handle if the cookie is considered level 0, or something else. Add a max_age to a step-up level condition. The identity cookie should allow being used as an alternative of the authenticators for this amount of time. Let's say we have 3 levels:
So basically we consider the identity cookie as long lived if it is older than the max age for the step-up levels. If identity cookie is 30 min old, then it would return level 2. If identity cookie is 120 min old, then it would return level 1, if it's older than 1 day, then it would return 0. |
|
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 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 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 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. |
Uh oh!
There was an error while loading. Please reload this page.
Feedback and questions around step-up authentication
All reactions