User Story: Session extension

[berilee]

User story

As a user I want to have my session silently extended so when I return to the tab at a later time I don’t have to sign-in again.

1. User signs in to dashboard example.rp.com
2. User leaves dashboard open in a tab
3. User returns 3 days later and they are still signed-in and the dashboard can update to the latest information.

Q: Does this require a refresh_token in order to get an extended id_token or access_token?

Q: How do multi page apps typically do token refresh?
Are they affected by third-party cookie deprecation?
Is it a top-level navigation to get a new token?

Context of the story

Consumer, Enterprise, EDU, Healthcare

Should this be considered sanctioned or unsanctioned tracking?

Unknown / TBD

Explicit list of parties involved

• IDP
• RP
• User

Security considerations

• How long does the session continue to extend for? Is it indefinite?
• What happens if the session extension fails? Is the user redirected somewhere? Is the redirection automatic?

Complicating characteristics

[TBD]

Additional information

[N/A]

[hlflanagan]

Discussed during the 3 December 2021 fedidcg call

[dj2]

As pointed out in the conference call, we’ve tied together two things that shouldn’t be tied together. This CUJ should probably be split into two:

• RP Session Extension
• Token renewal

When creating this CUJ we were tying those two things together thinking the act of getting a token was equivalent to extending the session. As was pointed out recently in another discussion, while that thinking was kinda valid, it’s fallen out of favour with OAuth 2.1 (please correct me if I’m wrong here).

For the two potential CUJs listed above, the first one feels out of scope for the current FedCM effort (that’s not to say it’s out of scope for FedID CG, just can we choose to ignore it in the near term as we work on 3rd party cookie deprecation). The reason I make this distinction as it doesn’t depend on a 3rd party cookie. The RP session is a first party cookie to the RP.

The question of Token Renewal falls within the scope of 3rd party cookie deprecation and so needs to be flushed out with respect to how it works and how we preserve the flow.

So, let’s try a re-phrasing/clarification of the CUJ.

As a user I want to load an embedded calendar and have that calendar continue to be up to date
without having to sign-in again.

• User signs in to dashboard example.rp.com where user has granted permission to access their calendar (assume for CUJ access_token has a 1 day lifetime)
• User leaves dashboard open in a tab
• User returns 3 days later and they are still signed-in and the dashboard can update to the latest calendar information.

In terms of the technical way this can be implemented, I believe there are two possibilities in play. The old SPA way, you fetch a new token. If that token comes back you’ve extended the token. If it doesn’t the user is no longer signed into the IDP and the sign-in flow is triggered.

The newer way is that a refresh_token is provided in the initial request, that refresh_token has a longer lifetime then the access_token (call it 30 days for this example). When the request to get the token is done after expiry the refresh_token is provided in order to authenticate the request.

If the refresh_token is expired then the user will be forced to re-authenticate.

Q: For the refresh flow, is the IDP cookie required? Or is the refresh_token sufficient to request a new access token? I.e. is the constraint on FedCM that we must provide a way to retrieve a refresh_token, but don’t have to provide a way to use the refresh token? (Not to say that we won’t I’m just wondering if it’s required).

[dj2]

From previous discussions, there are a lot of cases here, this is an attempt to
articulate what those cases are and how they currently work.

OIDC Session Management

As an RP I want to log the user out of the RP if the user logs out of the
IDP. The IDP/RP do not support front-channel logout.

 |----------------------------------|
 |  RP                              |
 |                                  |
 | |-----------|    |-------------| |
 | | RP iframe |    |  IDP iframe | |
 | |-----------|    |-------------| |
 |                                  |
 |----------------------------------|

• RP iframe sends postMessage() to IDP iframe to check login status
• IDP iframe determines status of user with IDP
  • This could be loading an IDP cookie to read the value (3rd party cookie)
  • This could be loading information from the IDP local storage (3rd party storage access)
  • Notably, this is not a network request
• IDP iframe returns status to RP iframe
• If IDP iframe reports changed RP re-authenticates

Q: In scope for 3PCD for the variant that stores info in IDP cookie?

Token Renewal

Code flow (or hybrid flow)

As an RP I want to renew an access token and I do not have a refresh token.

|-----|
| IDP |<-------------+
|-----|              | 4
  ^ |2          |------------|
  | |         > | RP Backend |
  | |       /   |------------|
 1| V      /
|-----|  /
|  RP |/ 3
|-----|

1. The PR does a top-level navigation to the IDP and requests code along with id_token or token.
2. The IDP does a redirects back to the provided redirect_url with the code and any tokens
3. The RP sends a request to the RP backend including the code
4. The RP backend makes a back-channel request to the IDP with the code and retrieves access_token (and possibly refresh_token)

The renewal of the tokens returned in (4) to the RP backend will be done through
the same back-channel. The browser is not involved.

The renewal of any tokens returned in (2) due to a hybrid request will be
renewed using one of the methods below.

Q: Out of scope for 3PCD, correct?

Implicit flow (or hybrid tokens in the browser) no refresh token

Either from an IDP iframe or RP code

|-----|
| IDP |
|-----|
  ^  |2--+
  |---+  |
|-----|--|-------|
| RP  |  |       |
|    1|  v       |
| |------------| |
| | IDP iframe | |
| |------------| |
|----------------|

OR

|-----|
| IDP |
|-----|
  ^ |2
  | |
  | |
 1| V
|-----|
|  RP |
|-----|

1. When it's determined the token needs to be refreshed the IDP iframe makes a
   XHR request to the IDP

• Q: This request always requires 3rd party cookies, correct?
  (there isn't some other thing that is used as a proxy for the user)

2. If the user is still authenticated to the IDP the new tokens are returned
   • If the user is no longer authenticated an error is returned and no tokens

In scope for 3PCD.

With Refresh Token

From an IDP iframe or RP code

|-----|
| IDP |
|-----|
  ^  |2--+
  |---+  |
|-----|--|-------|
| RP  |  |      |
|    1|  v       |
| |------------| |
| | IDP iframe | |
| |------------| |
|----------------|

OR

|-----|
| IDP |
|-----|
  ^ |2
  | |
  | |
 1| V
|-----|
|  RP |
|-----|

1. When it's determined the token needs to be refreshed the IDP iframe makes a
   XHR request to the IDP sending the refresh_token along.

• This request does not use 3rd party cookies.

2. If the user is still authenticated to the IDP the new tokens are returned
   • If the user is no longer authenticated an error is returned and no tokens

Q: Out of scope for 3PCD, correct?

[dj2]

Transcribing some of my notes of updates to the above comment so they don't get lost. I plan on creating a combined document that puts all this back together in a more coherent fashion.

1. Remove "The IDP/RP do not support front-channel logout." as it isn't relevant
2. Mark things as pre-conditions to make it clear what is being exercised (e.g in the token renewal code flow steps 1-3 are preconditions)
3. Renewing by iframe isn't implicit flow as it's getting the token directly (or they could be using the iframe to get a code instead of a token). Rename this to something more generic.
4. In the cases where an iframe is used there is a side-effect of touching the IDP token to extend the lifetime.
5. In the RefreshToken section, remove bullet 2.