RP-Initiated Logout Spec Changes and Post Logout Redirect Request

[SteveLPKI]

The OIDC logout-related specs are all now final (as of 12 September 2022). This includes the RP-Initiated Logout, Front-Channel Logout, Back-Channel Logout and Session Management specs. The corresponding references in the CATS 3.0 OIDC deployment profile will be updated accordingly.

The changes to the RP-initiated Logout spec (from the first draft dated 7 August 2020) include the addition of the client_id and logout_hint parameters as well as changes/clarifications regarding the id_token_hint parameter – particularly in association with the post_logout_redirect_uri parameter. Some of the rationale for the changes is provided here [https://bitbucket.org/openid/connect/issues/1182/add-logout_hint-parameter-to-rp-initiated]. One thing to note is that the id_token_hint is no longer REQUIRED if the post_redirect_logout_uri is present in the RP-initiated logout request (it is now RECOMMENDED instead). In addition, the client_id should be present if the id_token_hint is not, but this is not mandatory.

A potential issue for discussion is that an RP can send a logout request with the post_logout_redirect_uri parameter without including either the id_token_hint or the client_id (or any other parameters for that matter). While I would argue this violates the “spirit” of the new RP-initiated Logout spec (i.e., at least one of those two parameters should be present), my interpretation is that an RP can omit both yet still claim compliance with the spec as it is currently worded. Based on the discussions that led to these changes in the first place (see link provided above), this surprised me as I would have expected the presence of at least one of those parameters to be REQUIRED. While there are always trade-offs between placing burden on the RPs versus the OPs, it seems to me that requiring an RP to include client_id in the absence of an id_token_hint is little to ask if the RP wants their post logout redirect request to be honored.

So, should a constraint be added to the CATS 3.0 OIDC deployment profile in order to make it mandatory that either the id_token_hint or the client_id parameter MUST be present if the post_logout_redirect_uri parameter is included in the RP-initiated logout request? (Of course, both may be present as well, but at least one of them MUST be present.) Or, should a CATS 3.0 compliant OP be able to reliably action a post logout redirect request in the absence of either parameter (keeping in mind that the post_logout_redirect_uri in the logout request must match a pre-registered post_logout_redirect_uri known to the OP)? And, if the latter, should this be clarified in the CATS 3.0 OIDC deployment profile?

[harrdou]

Thanks Steve; The discussion linked to above is informative as it seems these new optional parameters (logout_hint, client_id) were suggested for cases when an RP does not provide the id_token_hint.

My concern with these new optional parameters is that there is no mechanism in place for the OP to verify the integrity of the client_id or logout_hint parameters, so they could be manipulated by an attacker just as easily as the post_logout_redirect_uri. This might be acceptable in some implementations, but it basically allows an attacker to use the post_logout_redirect_uri of any RP that is registered with the OP.

On the other hand...

When an id_token_hint parameter is present, the OP MUST validate that it was the issuer of the ID Token.

This can be done for example, by verifying the signature on the JWT. The OP can then use the aud claim in the ID token to identify the specific client, and ensure only that client's registered post_logout_redirect_uri(s) are allowed.

There is also a middle ground mechanism that is stronger than the client_id/logout_hint, although not as strong as using the id_token_hint. Section 3 of the new spec states that:

...if it is not supplied with post_logout_redirect_uri, the OP MUST NOT perform post-logout redirection unless the OP has other means of confirming the legitimacy of the post-logout redirection target.

In the case of CATS-compliant OPs, the mandatory support for both front-channel and back-channel logout provides just such an "other means". OPs supporting either of these specs need to keep track of the set of logged-in RPs so that they know what RPs to contact, via front-channel or back-channel, to cause them to log out. Because of this, the OP, in the absence of an id_token_hint, is still able to validate the post_logout_redirect_uri and only allow those which belong to an RP that is a participant in the session being logged out. This is the mechanism used by Sign In Canada when an id_token_hint is not provided, and it works well. It is also IMHO stronger than honoring any client_id or logout_hint provided in the URL.

Do we want to add a new CATS requirement for OPs with some "processing rules" that lay out an order of precedence? E.g.

1. Use id_token_hint if provided
2. Use session participant list if id_token_hint is not provided
3. Use client_id or logout_hint if all else fails.

[SteveLPKI]

This is more a question for the authors of the RP-initiated logout spec, but why isn’t there another mechanism in place to verify the source and integrity of the RP-initiated logout request? If requiring RPs to store an id_token so it can be returned in the id_token_hint parameter is too much to ask (e.g., due to storage limitations), or if there are privacy concerns wrt exposing PII at the user’s browser, then shouldn’t another method be defined to verify the source and integrity of the logout request? For example, the SAML 2.0 Web Browser SSO profile supports both message origin authentication and integrity by digitally signing the logout requests. There doesn’t appear to be an equivalent defined in the OIDC specs for logout requests (although there is an option to do this for authentication requests).

This is probably a non-starter, but to be thorough should we consider making the id_token_hint parameter mandatory (REQUIRED) in the CATS 3.0 OIDC deployment profile? I have seen another profile that does this (see https://e-gov.github.io/GOVSSO/TechnicalSpecification). On the other hand, we have already encountered RPs that do not support the id_token_hint. And in contrast, Login.gov (US government) has removed support for the id_token_hint altogether (even though it is RECOMMENDED in the RP-initiated logout spec) and they actually display an error message to the user if the id_token_hint is present (see https://developers.login.gov/oidc/#logout). Login.gov expects the client_id to be present instead, and they also display a logout confirmation screen to the user (but note they don’t support single logout).

If it unreasonable to make the id_token_hint mandatory (and that may very well be the case), then it seems we have no choice but to define the “processing rules” as Doug suggests, which could be coupled with the user prompt behaviour stemming from related Issue #40. We are working on additional details, but at a high-level it could be something like this:

1. Use the id_token_hint to validate and action the logout request if it is present; do not prompt the user. In this case, the RP-initiated logout spec states “the OP SHOULD ask the End-User whether to log out of the OP as well”. This may require a constraint in the CATS 3.0 OIDC deployment profile to change this to “SHOULD NOT” (or “MUST NOT”?)
2. If the id_token_hint is absent, use the session participant list to action the logout request but do not prompt the user. Prompting the user is REQUIRED by the RP-initiated logout spec in this case so this will require a constraint in the CATS 3.0 OIDC deployment profile to change this to “SHOULD NOT” (or “MUST NOT”?).
3. Failing numbers 1 and 2 above, fallback to client_id and/or logout_hint if present. Whether or not the user should be prompted in this case needs to be discussed. It is unclear to me under what circumstances these parameters would successfully resolve an applicable session if the id_token_hint is absent and number 2 above is unsuccessful, but admittedly there may be nuances that I am unaware of. Thoughts?
4. If none of the above are successful the logout request cannot be actioned, display error to the user

Very interested to learn what others think…