Repository navigation
refresh tokens vs full page redirects - how should the resource authorization server check the IdP session? #74
Description
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
Activity
dhs-BI commentedon May 8, 2025
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.
mcguinness commentedon May 20, 2025
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
online_accessthat 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 withoffline_accessto when the authentication event occurred to generate the RT.ttripp commentedon May 20, 2025
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 commentedon May 20, 2025
We discussed on the May 20 call and came to this conclusion:
aaronpk commentedon May 27, 2025
online_access)deansaxe commentedon Jul 3, 2025
@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.