I believe that right now the OIDC2 claims are only checked at authN time. Once a user has been logged in, the sessions lasts until the session is invalidated and all OIDC2 workflows are shortcut. This means that the sessions length of the claim is ignored and we don't leverage the refresh tokens to refresh the auth token so a user who is no longer authenticated to the IdP, has exceeded the timeout of the session as dictated by the IdP, or has had access within the IdP removed will still remain logged in. This is probably not desired or expected behavior and we should probably change it.
I'm not clear store in the session today and how much of it is necessary. Maybe in the case of federated auth we can allow the IdP to provide that information in the auth token's scope or maybe we continue to maintain an application specific session but when the user has authenticated via federated auth, we force it to recheck the validity of the session where applicable.
This might make sense to do along side #1027 as some aspects may change as part of that if we decide to make any changes.
I believe that right now the OIDC2 claims are only checked at authN time. Once a user has been logged in, the sessions lasts until the session is invalidated and all OIDC2 workflows are shortcut. This means that the sessions length of the claim is ignored and we don't leverage the refresh tokens to refresh the auth token so a user who is no longer authenticated to the IdP, has exceeded the timeout of the session as dictated by the IdP, or has had access within the IdP removed will still remain logged in. This is probably not desired or expected behavior and we should probably change it.
I'm not clear store in the session today and how much of it is necessary. Maybe in the case of federated auth we can allow the IdP to provide that information in the auth token's scope or maybe we continue to maintain an application specific session but when the user has authenticated via federated auth, we force it to recheck the validity of the session where applicable.
This might make sense to do along side #1027 as some aspects may change as part of that if we decide to make any changes.