OAuth2 Authorization grant flow not refreshing expired access/ID tokens

[hauntingEcho]

Summary

When a user's access and ID tokens expire, they should be considered invalid and refreshed using the refresh token. If unable to do so, the user's session should be expired.

Actual Behavior

currently, the behavior of HttpSecurity::oauth2Login, when used with an openid scope, will:

• retrieve a user's tokens at login
• not use the tokens' expiration time to dictate session lifespan
• not attempt to use refresh tokens to renew an expired session

Expected Behavior

• OpenID user sessions should be considered invalid whenever their ID token is invalid
• When using the authorization grant type, the refresh-token flow should be preferred whenever possible.

Configuration

in the WebSecurityConfigurerAdapter:

// this actually comes from Springboot properties:
String loginPage = "/oauth2/authorization/wso2";
// ...
http
    .addFilterAfter(ajaxTimeoutRedirectFilter, ExceptionTranslationFilter.class) // return 401 when attampting unauthenticated AJAX
    .logout().logoutSuccessHandler(oidcLogoutRedirectHandler()).permitAll()  // should go away with support in spring-security 5.2
    .and()
    .authorizeRequests()
      .antMatchers("/censoredPage1.html").hasRole("role1")
      .antMatchers("/censoredPage2.html").hasRole("role2")
      .anyRequest().authenticated() // functional controllers responsible for their own authorization
    .and()
    .oauth2Login()
      .loginPage(loginPage) // only one identity provider should be configured - just go directly there
      .userInfoEndpoint().oidcUserService(userService) // add internal numeric user ID which maps to incoming subject
    .and().and()
    .sessionManagement().maximumSessions(1).sessionRegistry(sessionRegistry) // allows session-killing to refresh authorization grants when they change
    .expiredSessionStrategy(new CallFailureSessionInformationExpiredStrategy(loginPage)); // on expired sessions: redirect synchronous requests, 401 async requests

in Spring-boot properties:

# NOTE: you need these two, but they're given by the OIDC provider (WSO2 Identity Server)
# spring.security.oauth2.client.registration.wso2.client-id =
# spring.security.oauth2.client.registration.wso2.client-secret =
# spring.security.oauth2.client.registration.wso2.client-name =
spring.security.oauth2.client.registration.wso2.provider=wso2
# Note well:  The scope list MUST be separated by commas.  There are multiple uses for this and some will work
# if you use spaces but others will fail in significant ways (like bypassing OIDC support and using OAuth2).
spring.security.oauth2.client.registration.wso2.scope=openid,email,phone
spring.security.oauth2.client.registration.wso2.redirect-uri-template=${my_url}/login/oauth2/code/wso2
spring.security.oauth2.client.registration.wso2.client-authentication-method=basic
spring.security.oauth2.client.registration.wso2.authorization-grant-type=authorization_code

spring.security.oauth2.client.provider.wso2.authorization-uri=${wso2.oauth2-root}/authorize
spring.security.oauth2.client.provider.wso2.token-uri=${wso2.issuer}
spring.security.oauth2.client.provider.wso2.user-info-uri=${wso2.oauth2-root}/userinfo
spring.security.oauth2.client.provider.wso2.jwk-set-uri=${wso2.oauth2-root}/jwks
spring.security.oauth2.client.provider.wso2.user-name-attribute=sub

server.port = 8443
my_hostname = https://localhost
my_url = ${my_hostname}:${server.port}
wso2.baseUrl = ${my_hostname}:9443
wso2.oauth2-root = ${wso2.baseUrl}/oauth2
wso2.issuer = ${wso2.oauth2-root}/token

Version

5.1.5 (via spring-boot 2.1.4)

[jgrandja]

@hauntingEcho oauth2Login() is another authentication mechanism provided that allows a user to log into an application and establish an authenticated session via HttpSession. Even though OpenID Connect is leveraged to achieve this in oauth2Login(), the end result is an authenticated HttpSession with the application. However, the user has also logged into the OpenID Connect provider during this flow and therefore has another authenticated session with the Provider. These are 2 completely separate sessions that are indirectly related as a result of oauth2Login. And keep in mind that the session policies are likely different at the provider than the application. For example, the default session timeout at the Provider may be 2 hrs, which means the ID Token exp would be 2 hrs. However, the default session timeout for the underlying application server where the application is running may be 30 mins. So using the ID Token as the primary source of session information for the application would be quite complicated to override for that one specific authenticated session. Also, to me this does not make sense either as the 2 established sessions are not directly associated and can't be - of course without introducing another level complexity.

To expand further, the end result of oauth2Login() is an OidcIdToken and an OAuth2AccessToken. The OidcIdToken is only used at time of authentication to validate the signature and claims but after validation passes and authentication is achieved it's never used (or needed) again by oauth2Login(). The same applies to the OAuth2AccessToken, which is used to fetch the UserInfo. After the user's attributes are obtained during authentication and an OidcUser is associated to an OAuth2AuthenticationToken, it's no longer needed to call the UserInfo endpoint either. Both OidcIdToken and OAuth2AccessToken are only needed during the authentication processing time.

Tying the user's session within the application using the OidcIdToken doesn't make sense here as the sole purpose of the ID Token is to provide information (claims) to the client application about the authentication of an End-User at the Provider.

Based on all these reasons I'm going to close this issue as the current functionality is working as designed. I hope this explanation make sense?

[hauntingEcho]

The way I'm reading the spec, the session lifespan of Relying Parties should be the minimum between the two of the RP's configured maximum lifespan, and the ID token's expiration. This is similar to the behavior of SAML2's SessionNotOnOrAfter in an AuthnStatement. If a user's session at RPs is intended to be able to outlive sessions at the provider, there's nothing in the spec stopping the provider from setting exp farther into the future than its own session lasts.

per section 3 of OpenID Connect Core: "The Authentication result is returned in an ID Token, as defined in Section 2. It has Claims expressing such information as the Issuer, the Subject Identifier, when the authentication expires, etc."

section 4 of the OpenID Connect Session spec draft also states: "An ID Token typically comes with an expiration date. The RP MAY rely on it to expire the RP session. However, it is entirely possible that the End-User might have logged out of the OP before the expiration date. Therefore, it is highly desirable to be able to find out the login status of the End-User at the OP. " This again supports that ID token expiration should be the maximum lifespan of RP sessions, although RPs may want to keep in communication with OPs for session termination before that time.

[jgrandja]

@hauntingEcho Great points. In reference to section 4. Session Status Change Notification:

The RP MAY rely on it to expire the RP session

The keyword here is MAY. Also, the OpenID Connect Session Management spec is OPTIONAL as part of an OpenID Connect 1.0 implementation. Therefore, session management may not be supported by certain OpenID Connect providers.

Furthermore in section 4:

it is highly desirable to be able to find out the login status of the End-User at the OP. To do so, it is possible to repeat the Authentication Request with prompt=none. However, this causes network traffic and this is problematic on the mobile devices that are becoming increasingly popular. Therefore, once the session is established with the Authentication Request and Response, it is desirable to be able to check the login status at the OP without causing network traffic by polling a hidden OP iframe from an RP iframe with an origin restricted postMessage as follows.

Based on the highlighted text, the recommendation is to poll the authentication status using a hidden OP iframe from a RP iframe.

I've read this part of the spec before and quite honestly I feel this introduces unnecessary complexity to the mix. Regardless of my opinion though, this is a new feature request and is not a required implementation of the existing oauth2Login feature. If users are asking for this feature than we will prioritize it into a release but this is the first request to-date. FYI, we've recently added RP-Initiated Logout.

[hauntingEcho]

I agree that it could make sense to consider this a feature request. My reading of section 4 there was as a method to determine whether the OP session had ended early (which could otherwise end up using a much more frequent prompt=none heartbeat than the id_token's expiry and cause obnoxious amounts of traffic). My understanding of "[...]expiration date. The RP MAY rely on it[...]" was that the expiration date is a logical upper bound on the expected lifespan of the OP session, and therefore the "may" distinction was "may rely on, or may fall back to" not "may rely on, or may ignore entirely" as I'm interpreting your understanding to be. I had discussed it some on the gitter thread, but the conversation moved on pretty quickly.

I agree it does add a decent amount of complexity, but would argue there's value in having a timeout-based mechanism for OPs to bound RP sessions (again, as SessionNotOnOrAfter does for SAML2) in addition to more-active mechanisms. Additionally, as those active mechanisms are all in the draft stage still (session management, front channel, & back channel), I'd argue that time-bounded tokens are currently the only finalized part of the spec that gives OPs control over sessions at their relying parties.

Thanks for the heads-up on RP-Initiated logout. I've currently got it TODO'd to remove our custom implementation after 5.2 releases (which, as I understand it, is when that feature arrives), but that should help us get rid of that second line of configuration & the associated handler code

[hauntingEcho]

to follow back up on this a bit, I think this ultimately would become two tickets:

• requesting support for limiting the session lifespan to that set by identity providers via the ID token's expiration. I haven't really found where this would best go (the best solution we've had internally so far is extending SessionRegistryImpl) - would this make the most sense against this project?
• requesting support for a mechanism which silently refreshes the current session with the identity provider if it has expired (via OIDC with prompt=none or SAML2's redirect flow with isPassive set true). Mechanisms already exist by which the current session can be forcibly expired, so this support would also give access to updating the session using the iframe setup detailed in the session draft spec. Would this make sense for spring-security-web?

I understand that these may not get prioritized right away, but let me know if I'm totally off-base with these. I'll go ahead and create tickets for them next week if I haven't heard back from you.

[hauntingEcho]

I've broken those two into #6814 & #6815 - I understand that these may not be a priority for spring-security overall right now, but my short-term goal at this point is just to have viable feature-request tickets that I can reference from our internal tickets