Open berilee opened 2 years ago
Discussed during the 3 December 2021 fedidcg call
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:
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.
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).
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.
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 | |
| |-----------| |-------------| |
| |
|----------------------------------|
changed
RP re-authenticatesQ: In scope for 3PCD for the variant that stores info in IDP cookie?
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
|-----|
code
along with id_token
or token
.redirect_url
with the code and any tokenscode
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?
|-----|
| IDP |
|-----|
^ |2--+
|---+ |
|-----|--|-------|
| RP | | |
| 1| v |
| |------------| |
| | IDP iframe | |
| |------------| |
|----------------|
OR
|-----|
| IDP |
|-----|
^ |2
| |
| |
1| V
|-----|
| RP |
|-----|
In scope for 3PCD.
|-----|
| IDP |
|-----|
^ |2--+
|---+ |
|-----|--|-------|
| RP | | |
| 1| v |
| |------------| |
| | IDP iframe | |
| |------------| |
|----------------|
OR
|-----|
| IDP |
|-----|
^ |2
| |
| |
1| V
|-----|
| RP |
|-----|
Q: Out of scope for 3PCD, correct?
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.
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.
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
Security considerations
Complicating characteristics
[TBD]
Additional information
[N/A]