You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The OpenIdAuthenticator goes through the Authorization Code Flow and obtains the ID Token, which it keeps in the session and in the Authentication object. It validates the expiry time of the ID Token when it receives it.
From that point on, the session is authenticated, and remains so for as long as it asks. By default, the only mechanisms for ending the session are an explicit logout, the idle timeout of the session handler, and the cookie max age.
Since there isn't an Access Token being passed around, one reason for having a limited lifetime is not really applicable. However, if a user has permissions removed or withdrawn in the ID Provider, Jetty will not be aware of it for the lifetime of the session. Note that cookie max age can be ignored by the Browser (and doing so is a feature of at least one browser).
I think there should be an option to have the OpenId authentication remain valid only for the valid lifetime of the ID Token. This would be implemented in OpenIdLoginService.validate(). That should mean that after expiry of the ID Token, the OpenIdAuthenticator.validateRequest() would fall through and repeat the Authorization Code Flow, which is correct. Normally this would be transparent to the user, if they still have a valid session with the OpenId Provider, but if their rights were changed or their OpenId Provider session invalidated in the meantime, they would have to log in again.
Possibly the check should be implemented not in OpenIdLoginService, but in a separate LoginService provided to the OpenIdLoginService in its constructor.
It could also be argued that the check belongs in 'whatever is accessing Session.getAttribute("org.eclipse.jetty.security.openid.claims")' since that includes the "exp". But that would make it awkward to seamlessly reauthenticate the session.
There's also a possibility of using the Refresh Token supplied in the initial response from the OpenId provider, to fetch a new token. On reflection, I don't think that's the right approach since it's for "offline_access", whereas Jetty is really extending an active online session, and is linked to the Authorization Token, which Jetty isn't using. But it is an option.
The text was updated successfully, but these errors were encountered:
There is now a setting in openid.mod for this called jetty.openid.logoutWhenIdTokenIsExpired.
This is also available to be set with OpenIdConfiguration.setLogoutWhenIdTokenIsExpired().
Jetty version(s)
Jetty 9.x is now at End of Community Support
10.0.14
Enhancement Description
The OpenIdAuthenticator goes through the Authorization Code Flow and obtains the ID Token, which it keeps in the session and in the Authentication object. It validates the expiry time of the ID Token when it receives it.
From that point on, the session is authenticated, and remains so for as long as it asks. By default, the only mechanisms for ending the session are an explicit logout, the idle timeout of the session handler, and the cookie max age.
Since there isn't an Access Token being passed around, one reason for having a limited lifetime is not really applicable. However, if a user has permissions removed or withdrawn in the ID Provider, Jetty will not be aware of it for the lifetime of the session. Note that cookie max age can be ignored by the Browser (and doing so is a feature of at least one browser).
I think there should be an option to have the OpenId authentication remain valid only for the valid lifetime of the ID Token. This would be implemented in OpenIdLoginService.validate(). That should mean that after expiry of the ID Token, the OpenIdAuthenticator.validateRequest() would fall through and repeat the Authorization Code Flow, which is correct. Normally this would be transparent to the user, if they still have a valid session with the OpenId Provider, but if their rights were changed or their OpenId Provider session invalidated in the meantime, they would have to log in again.
Possibly the check should be implemented not in OpenIdLoginService, but in a separate LoginService provided to the OpenIdLoginService in its constructor.
It could also be argued that the check belongs in 'whatever is accessing Session.getAttribute("org.eclipse.jetty.security.openid.claims")' since that includes the "exp". But that would make it awkward to seamlessly reauthenticate the session.
There's also a possibility of using the Refresh Token supplied in the initial response from the OpenId provider, to fetch a new token. On reflection, I don't think that's the right approach since it's for "offline_access", whereas Jetty is really extending an active online session, and is linked to the Authorization Token, which Jetty isn't using. But it is an option.
The text was updated successfully, but these errors were encountered: