rp-initiated logout - proposal for client_id parameter

[Filip Skokan]

I'd like to request that a parameter (recommended?) client_id is defined for rp-initiated logout request.

rationale:

Currently the id_token_hint is the only way of identifying the client that's making the request. In scenarios where a client does not yet have an id_token but makes a request to authenticate which fails (e.g. due to being requested with essential sub claim through claims) the next step will be to trigger an rp initiated logout with a registered post_logout_redirect_uri but without an id_token_hint. This can be problematic for OP deployments with a high number of clients as it is not efficient or sometimes even not possible to iterate over all of them to see if this post_logout_redirect_uri is whitelisted or not. Hence the client_id parameter to make this lookup possible and efficient.

Further processing may be defined such as if both client_id and id_token_hint are provided the audience of the id_token_hint must include the client_id etc.

[Michael Jones]

We discussed this on the 20-Aug-18 working group call. It wasn't clear to people that a client_id on the query string would add any actionable reliable information, since there's no client authentication associated with it. An attacker could spoof it.

As such, this seems like then just extra mechanism.

We hope to discuss it on an upcoming call with Filip.

[Filip Skokan]

I will be there in the next call to discuss the proposal, it would be great if #1033 had a clear answer by then as it might make this one obsolete.

[Filip Skokan]

If i recall correctly, we discussed this proposal on the Aug 30 call.

@gffletch mentioned the inclusion of id_token_hint was not to help "authenticate" the logout call but rather help the AS identify the session id, for instance when the AS supports multiple concurrent sessions and the select_account prompt.

So, if id_token_hint remains optional and it's presence is not a prerequisite for post_logout_redirect_uri being used I'd like to see a client_id optional identifier in as well to support the following.

Provided id_token_hint is symmetrically encrypted
In order to decrypt it the right client's client_secret needs to be identified in order for the AS to get the contents.

can be solved with the client re-encrypting the id token and putting the client_id in the JWE header (similar proposal was made by @b_d_c in the mailing list discussion for #1049) or by the OP pushing it there in the first place. This mechanism is however not mentioned in neither of the final or draft specifications as of today)

id_token_hint is not provided but post_logout_redirect_uri is
The AS needs to check a whitelist of post_logout_redirect_uris, to load or iterate through all clients is too inefficient an operation to proceed as mentioned in the description. As of today the post_logout_redirect_uri will be ignored if it can't be verified to be whitelisted and the UX suffers as well as likely adoption given the RPs will be sending the end-users away for good. This was a very common feedback in my last project. RPs seldom want to give away control of the user-agent's location. Even during logout.

Raised concerns

@mbj We discussed this on the 20-Aug-18 working group call. It wasn't clear to people that a client_id on the query string would add any actionable reliable information, since there's no client authentication associated with it. An attacker could spoof it.

I feel the same can be said about a prompt=none response_type=none authorization endpoint call, very little difference to allowing client_id in end_session_endpoint to aid identifying the client. Both allow for state to be utilized by the Client and in both cases the server will do final location uri validation, if uri mismatches, an error is thrown and no redirect happens.

[Brian Campbell]

I think the main point is that if the AS doesn't know the calling client, it is prohibitively difficult or even impossible to validate the post_logout_redirect_uri. And there are definitely cases where a client won't want to or even be able to hold onto the original ID token just to (maybe) send the user back to the end_session_endpoint with it. Just from the perspective of allowing the functionality to be reasonably implemented, it might make sense to allow client_id at the end_session_endpoint and require that either id_token_hint or client_id be sent when post_logout_redirect_uri is present. Or maybe just require one or the other in order for the AS to honor post_logout_redirect_uri.

[Michael Jones]

Per today's working group call, what are the security implications are of passing the client_id a non-tamper-resistant manner?

[Roland Hedberg]

Have just started to work on the session/backchannel/frontchannel logout tests. Executing all the necessary steps to verify that the tests are doing what they should I'm left with a number of questions that touch Filip's concern.

If the request can be done without including id_token_hint then there is very hard for the AS to know the calling client. Now sending a client_id without doing any client authentication doesn't add much.

But It's been pointed out that what really matters is that the AS knows who the user is. Which client the user is coming from is of less concern. I can to some degree sympatize with that but that means that the AS MUST redirect the user to a logout page at the AS to have any chance of knowing the user. This under the assumption that no id_token_hint was sent as part of the request.

If the client is unknown finding the user given id_token_hint might be costly but can be done.

Whether id_token_hint is provided or not I think we should strongly recommend that the user should be met with a logout page at the AS.

[Filip Skokan]

@Rohe:

If the client is unknown finding the user given id_token_hint might be costly but can be done.

ID Token always must contain aud (or azp) so finding the client to verify post_logout_redirect_uri is therefore a simple identifier lookup.

[Filip Skokan]

@b_d_c:

I think the main point is that if the AS doesn't know the calling client, it is prohibitively difficult or even impossible to validate the post_logout_redirect_uri.

Exactly.

@mbj:

what are the security implications are of passing the client_id a non-tamper-resistant manner?

As @gffletch mentioned in one of the past call, the point of id_token_hint was not to authenticate the client but merely aid the OP in identifying the session the RP is asking to drop and it is already suggested in section 8 that requests without a valid id_token_hint are a potential DoS and OPs may therefore require user confirmation. Adding an optional client_id parameter to allow for post_logout_redirect_uri to be honored does not change those considerations, only makes the endpoint usable by RPs in that case.

The id_token_hint parameter to a logout request can be used to determine which RP initiated the logout request. Logout requests without a valid id_token_hint value are a potential means of denial of service; therefore, OPs may want to require explicit user confirmation before acting upon them.

I'm commonly seeing two implementations of rp initiated logout

1. those who implement this specification but they make the id_token_hint required - this can be either so that they don't have to implement an OP logout prompt or need the hint to identify the client
2. those who have a proprietary logout endpoint where client is identifiable by the OP and post logout is honoured

At the very least i think we could agree that an RP-initiated logout without the possibility to redirect back to the RP (or it being unreliable) is not something the RPs would accept and adopt. In cases when id_token_hint is missing or invalid we already suggest rendering an OP prompt for the end-user, but are lacking a way to verify the post logout uri to handle what happens after this prompt.

[gffletch]

Additionally, there may be value in allowing the session id (sid) to be specified as it's own parameter rather than passing the entire id_token as a hint to the logout spec. This does not help in validating the post_logout_redirect_uri though.

[Michael Jones]

Filip, John, Aaron Parecki, Daniel Fett, Torsten, and I discussed this. We agreed that the right fix is to require that id_token_hint be present when post_logout_redirect_uri is used, so that the post_logout_redirect_uri can be validated. When post_logout_redirect_uri is present and the id_token_hint is not present, the request should return an error.

[Roland Hedberg]

OK, I’ll update the tests accordingly.

[Filip Skokan]

see https://bitbucket.org/openid/connect/issues/1071