RP-initiated logout: require valid id_token_hint to take action on post_logout_redirect_uri

[Vladimir Dzhuvinov]

The current draft implies that sending the end-user's browser to the post_logout_redirect_uri of a logout request without an id_token_hint is OK to proceed, provided the OP is able to locate the URI in a registered client's metadata and the end-user confirms the action (the latter is not normatively required though).

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

http://openid.net/specs/openid-connect-session-1_0.html#Security

If a valid ID token hint isn't required to clear the redirection, which provides a way to "authenticate" the caller, any website could potentially cause the OP to redirect to an RP's post_logout_redirect_uri.

Even if the OP installs a confirmation before the redirection, as suggested in section 8, there may be problems with that. Regarding the confirmation to log out (or not), the end-user will probably know how to respond to that. Regarding the other confirmation - to redirect (or not) in the case of no ID token hint being present - I'm not sure we can rely on the user to discern correctly here, e.g. that the redirection URI belongs to the website that initiated the logout. That will also rely a lot on the UX at the OP.

There may also be unforeseen security and privacy risks with redirecting the end-user to an RP where they didn't log in, for example for OPs with dynamic client registration or where we have RPs with common CORS JS included.

My suggestion therefore is to require an id_token_hint when a post_logout_redirect_uri is included (with alg:none ID tokens not qualifying).

This issue is related to #1032

[Filip Skokan]

There may also be unforeseen security and privacy risks with redirecting the end-user to an RP where they didn't log in, for example for OPs with dynamic client registration or where we have RPs with common CORS JS included.

This part is not clear to me and I feel the same could be said about prompt=none authorization request being made by someone else with a valid redirect_uri of another RP. A well-behaved RP would reject the post logout request redirect request since there would be no state matching its records. The use of the state parameter should be RECOMMENDED.

I'd like to hear other opinions on this but in my mind this makes RP-Initiated Logout less flexible and if deployed in a high trust environment where i.e. RPs require acrs, auth times or specific sub claims and those cannot be met because of a pre-existing session this RP would have to first step down on its requirements for a valid authentication in order to first obtain any id token so that i can start an op logout. It's this stepping down that I don't have a good feeling about.

If it helps I'd suggest that the OP end-user prompt be REQUIRED for all requests where a valid and still not expired id_token_hint is not provided.

[Kevin Cathcart]

I'm not sure that requiring the token to be non expired to have a no-confirmation flow really makes sense.

Fundamentally the draft specification draft seems a bit confused due to some poor wording. It talks about a Session with an RP, which is really something defined by the RP and user agent. On the other hand the specification is really more concerned with the users session (which it terms login status) with the OP. per @mbj the discussion in issue #1024, it seems like it really wants to talk about the portion of the user's session with the OP that relates to being authenticated with the given RP.

This may be relevant because of a desire for a single sign off experience, or because that the OP will stop accepting Access Tokens issued during that session, after the user logs out at the OP.

Other similar confusion: "An ID Token typically comes with an expiration date. The RP MAY rely on it to expire the RP session". Unfortunately that sentence is pretty much useless. It makes places no normative requirements or even recommendation on server or client, nor does it in any way reflect any existing requirements on either. It also seems to direct contradict the intended meaning of the exp claim as per @mbj over in issue #1002

In the normal case it is good security practice to make the expiration period of the ID Token really short (like perhaps 5 minutes, or even less). The idea being that the shorter the validity period the less time an attacker has to attempt to use the token in some form of attack.

To not allow the use of such super short lived tokens for confirmation-less logout would discourage what is otherwise good security practice. The OP can very easily use other heuristics to determine if it should prompt for logout, that avoid replaying of old ID tokens as a denial of service mechanism. One very good such heuristic would be: Token was issued by this OP, is otherwise valid (except for being expired, and of course potentially the issuer not being in the audience claim), and it contains an "sid" claim that corresponds to an active login session at the OP. Obviously once the OP logs out that token can never be used for logout again since that sid refers to a session that no longer exists.

[Vladimir Dzhuvinov]

Yes, that the ID token "exp" is only intended to establish a short time window after which the RP must not accept the token was already clarified in WG discussions, in the mentioned ticket #1002 and hopefully will soon make it into the spec / errata. I.e. the "exp" does not in any way translate to the lifetime of the end-user session at the OP.

I think we'll be able to resolve this issue easily if we agree on the purpose and security properties of the RP initiated logout. All else will fall into place then.

[Nat Sakimura]

Touched on the Aug. 20 call. Will discuss it in the Atlantic call so that both Vladimir and Filip can weigh in.

[Michael Jones]

Note that #1071 seems to be a duplicate of this. I'm leaving both open for now.

[Michael Jones]

Fixed #1033 - Removed misleading statement about ID Token expiration

→ <<cset e58bce7e0cb6>>