Difference between revisions of "Relying Party Refresh"
(→Full Title or Meme) |
(→Solutions) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 7: | Line 7: | ||
It seems that the concept of RP Refresh is a topic that should be considered independently of these various use cases as it needs to be controlled by the user agent in any case. | It seems that the concept of RP Refresh is a topic that should be considered independently of these various use cases as it needs to be controlled by the user agent in any case. | ||
Perhaps an entirely separate standard for RP Refresh. | Perhaps an entirely separate standard for RP Refresh. | ||
| + | ==Solutions== | ||
| + | From Jake Feasel Sr. Product Manager, IDM ForgeRock | ||
| + | |||
| + | I had a quick talk at Identiverse this year covering the OIDC Session Management draft spec, in particular my take on the upcoming "Cookiepocalypse" and how it will render the current draft completely obsolete. You can see my slides [https://docs.google.com/presentation/d/1uU3KvK6ayTpjB2OEmrSqQnUdJDPSdfxxetJrks1czvI/edit#slide=id.g11aa5093f19_0_63 here]. | ||
| + | |||
| + | The main points: | ||
| + | * The current session management spec already identifies its own demise, here: https://openid.net/specs/openid-connect-session-1_0.html#ThirdPartyContent | ||
| + | * IDP-initiated logout and idle timeout reset will be unavailable once [[Third Party]] cookies are blocked (if there is no alternative solution available) | ||
| + | * Back-channel logout is a viable (albeit challenging to implement) alternative for apps which have a back-end; pure client-side single page apps do not have this option, however. | ||
| + | |||
| + | The biggest point I want to raise is that we need an alternative implementation to become the new standard; one that is not susceptible to third-party cookie blocking. To that end, I propose the introduction of a new grant type - "session_check". It would work like so: | ||
| + | |||
| + | The OP will include the "sid" claim (as defined in the Front and Back-channel logout drafts) as a claim in the id_token used in an auth_code grant. This "sid" value will be included in a POST request to the "token" endpoint on the OP on a periodic basis (likely prompted from user activity within the RP). It would like something like so (note the absence of a cookie in this request): | ||
| + | |||
| + | POST /token HTTP/1.1 | ||
| + | Host: server.example.com | ||
| + | Content-Type: application/x-www-form-urlencoded | ||
| + | Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW | ||
| + | |||
| + | grant_type=session_check&sid=1234xyz | ||
| + | |||
| + | The response code from this could be a 401 if the sid is not associated with a valid OP session, or 200 if it is. The response body in the case of a 200 could include a new id_token with updated session claims (to provide better context for when the session expires or if other important details about the session change). | ||
| + | |||
| + | Any client which is capable of calling the token endpoint in an auth_code grant should be just as capable of making a similar request to the token endpoint for this new session_check grant. All of the same authentication methods used for an auth_code grant should be suitable for this grant too (meaning public clients such as SPAs and Mobile apps should also be able to call it). | ||
| + | |||
| + | Another advantage of this approach is that it could be performed completely in the backchannel. Confidential clients which have never had access to the OP session cookie could make a session_check request and learn whether or not the user is still logged in. | ||
==References== | ==References== | ||
Latest revision as of 12:07, 1 September 2022
Full Title or Meme
There are many reasons for a short duration Authorization ticket to be issued to users. Those cases typically require a refresh of the ticket without a heavy cognitive load on the user.
Context
This pattern IS TRACKING by the IdP of accesses by the user to the RP. That is considered to be a problem in the case of the mDL. It seems that the concept of RP Refresh is a topic that should be considered independently of these various use cases as it needs to be controlled by the user agent in any case. Perhaps an entirely separate standard for RP Refresh.
Solutions
From Jake Feasel Sr. Product Manager, IDM ForgeRock
I had a quick talk at Identiverse this year covering the OIDC Session Management draft spec, in particular my take on the upcoming "Cookiepocalypse" and how it will render the current draft completely obsolete. You can see my slides here.
The main points:
- The current session management spec already identifies its own demise, here: https://openid.net/specs/openid-connect-session-1_0.html#ThirdPartyContent
- IDP-initiated logout and idle timeout reset will be unavailable once Third Party cookies are blocked (if there is no alternative solution available)
- Back-channel logout is a viable (albeit challenging to implement) alternative for apps which have a back-end; pure client-side single page apps do not have this option, however.
The biggest point I want to raise is that we need an alternative implementation to become the new standard; one that is not susceptible to third-party cookie blocking. To that end, I propose the introduction of a new grant type - "session_check". It would work like so:
The OP will include the "sid" claim (as defined in the Front and Back-channel logout drafts) as a claim in the id_token used in an auth_code grant. This "sid" value will be included in a POST request to the "token" endpoint on the OP on a periodic basis (likely prompted from user activity within the RP). It would like something like so (note the absence of a cookie in this request):
POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
grant_type=session_check&sid=1234xyz
The response code from this could be a 401 if the sid is not associated with a valid OP session, or 200 if it is. The response body in the case of a 200 could include a new id_token with updated session claims (to provide better context for when the session expires or if other important details about the session change).
Any client which is capable of calling the token endpoint in an auth_code grant should be just as capable of making a similar request to the token endpoint for this new session_check grant. All of the same authentication methods used for an auth_code grant should be suitable for this grant too (meaning public clients such as SPAs and Mobile apps should also be able to call it).
Another advantage of this approach is that it could be performed completely in the backchannel. Confidential clients which have never had access to the OP session cookie could make a session_check request and learn whether or not the user is still logged in.
References
- See wiki page on Revocation
