refresh tokens vs full page redirects - how should the resource authorization server check the IdP session?

[aaronpk]

This was brought up on the May 6 call. Scenario:

• a mobile app starts an OAuth flow to its (first-party) authorization server
• the authorization server federates to the enterprise IdP to log in the user
• the authorization server receives an ID token, then creates an access token and refresh token and sends it to the mobile app
• later, the access token expires, the mobile app goes to use the refresh token at its authorization server

[IPSIE enters the chat]

• the authorization server ideally should check back with the IdP before issuing a new access token
• If the authorization server has a refresh token from the IdP, it could use the refresh token in the backchannel to check in with the IdP.

If the authorization server doesn't have a refresh token, the only way to accomplish this is actually to do a full OAuth flow from scratch again, including the user-visible popup browser on mobile. The "happy path" would complete relatively quickly, since the user would have an active session at the IdP and wouldn't need to re-authenticate. However that "happy path" is still somewhat disruptive to the user experience on mobile.

So the question for the group is how do we want to enable this use case: the authorization server ideally should check back with the IdP before issuing a new access token

[dhs-BI]

See #71 under Section 3.11.3. These are the FAL2 requirements. When this issue is resolved, we should document how it aligns to these requirements.

• Access to the identity API SHOULD be limited to the duration of the federation transaction plus time necessary for synchronization of attributes, as discussed in Sec. 4.6.4.
• Since the time limitation is separate from the validity time window of the assertion and the lifetime of the authenticated session at the RP, access to an identity API by the RP without an associated valid assertion SHALL NOT be sufficient for the establishment of an authenticated session at the RP.

[mcguinness]

I am a fan of having a RP use a refresh token as a long-lived handle to check account status with the IdP. This is one of the big advantages OIDC has over SAML being based on OAuth 2.0 and inheriting all the machinery. I think its the simplest way to introduce another policy evaluation at the Enterprise IdP without the RP needing to add support for an additional protocol such as OP Commands or SCIM.

I do see some challenges that we would we might need to address

• Can we get away away with requiring proof-of-possession for token refresh such as DPOP and keep allowing public clients for SL1?
• We need to define the behaviors that MUST revoke the RT for this be meaningful. Today these are all optional and vary across OPs (e.g revoke on credential change)
• Should we provide extended lifecycle states during token refresh errors similar to OP Commands so an RP knows why a RT was revoked? This might improve UX and enable RP to respond to more fine-grained states then just token revoked, re-auth user (e.g user was deprovisioned so please don't try to re-auth).
• Having online_access that binds the RT to the OP session would add a lot of value to the enterprise for zero-trust/continuous authentication use cases as well as Single Logout. Authentication context is frozen with offline_access to when the authentication event occurred to generate the RT.

[ttripp]

Just adding +1 based on the meeting discussion today. It makes sense to me that we define the acceptable methods and detail to update the session expiration:

Front Channel - Full Page Redirect following typical IPSIE requirements
Back Channel - Refresh token that can get an updated session expiration in the same claim which it honors to update (or possibly revoke) the session.

DPOP seems like it needs more discussion, so not commenting yet except that of course from a security perspective it makes sense, but I'm unclear if the adoptability for this is high enough to be in SL1.

[aaronpk]

We discussed on the May 20 call and came to this conclusion:

• DPoP is required for refresh tokens, question of whether to bind on the authorization flow or only at the token endpoint
• Update the description of the session lifetime requirement in the levels to add the refresh token mechanism as an alternative to the full page redirect method of reauthenticating the users
• Add some discussion of the session expiration claim in OIDC Enterprise Extensions
• Update the IPSIE SL1 OpenID profile to describe this behavior
• The refresh token mechanism can be opt-in by the RP, not required, because the alternative is they do a redirect to the IDP after the session expiration anyway so it is purely a UX benefit for them
• We can add guidance to the security considerations to recommend IdPs use client registration of the refresh token grant type as a signal about whether the client supports this mechanism and can shorten the session expiry claim appropriately

[aaronpk]

• The RP needs to be able to indicate it plans to use a refresh token so the OP can communicate a shorter session lifetime (e.g. with a scope value of online_access)
• Will push a PR to update the text in the IPSIE levels
• We should make it more explicit in the text that the IdP session and RP session are distinct, and that the IdP can dictate different session lifetimes to each RP.

[deansaxe]

@aaronpk have you pushed a PR on this yet? Trying to align my language in https://github.com/openid/ipsie-openid-sl1/pull/3/files with this update.