Use of id_token in RP-Initiated Logout as the id_token_hint

[Rasitha Wijesinghe]

Re: https://openid.net/specs/openid-connect-session-1_0.html#RPLogout

Current spec recommends using id_token in the RP-initiated logout as the id_token_hint but there are two issues with this approach:

1. When an id_token contains additional claims, the size of the id_token becomes too big for a URL query parameter and can run into logout issues. This is esp. an issue when id_token includes role claims in an enterprise Active Directory environment.

2. id_token can contain sensitive information about the user such as name, email, phone. Because it is used as a GET query parameter, the value can be easily extracted by a middle party as well as gets logged in a standard logging configuration.

Is there a way to recommend using a different value for this? The reason for using id_token_hint makes sense but does the value have to be the id_token itself? Can the OP issue some other value (within the id_token) at sign-in time that can be used as the logout id_token_hint? Then OP can still verify the logout request in a secure manner.

Thanks!

[Brian Campbell]

Related to Issue #1032 this ticket mentions a couple of other reasons that an RP/client might not want to or be able to use id_token_hint for invoking the end session endpoint.

[Filip Skokan]

When an id_token contains additional claims, the size of the id_token becomes too big for a URL query parameter and can run into logout issues.

id_token can contain sensitive information about the user such as name, email, phone. Because it is used as a GET query parameter, the value can be easily extracted by a middle party as well as gets logged in a standard logging configuration.

Would opening the end_session_endpoint to a POST be a solution here?

[Michael Jones]

I agree that using POST would solve both problems.

[Rasitha Wijesinghe]

Yes that will solve both issues. Only concern would be the extra complexity for the RP where RP has to generate a 200 response with a form that will get submitted to OP from the browser.

[Michael Jones]

John and Filip and I discussed this and we agreed that allowing POST is reasonable. John pointed out that this should be easy for most servers, as the frameworks will typically hide whether a parameter cam in as query string or in the POST body anyway.

[Michael Jones]

On the 30-Jul-20 call, we discussed whether we should allow and/or require supporting POST to the logout endpoint. Filip said that Connect Core requires POST support to the authorization endpoint whereas it's a MAY in OAuth.

Filip said that the POST support at the authorization endpoint isn’t tested by certification.

Mike will propose specific text changes modelled after Core’s POST support at the authorization endpoint..

[Michael Jones]

Fixed #1056 - Support both GET and POST at the Logout Endpoint

→ <<cset 4147bd5a5b3f>>