[openid-connect-session] Checking post_logout_request_uri

[Clément OUDOT]

Hello,

I am try to implement RP initiated logout in my OP, following these
instructions: http://openid.net/specs/openid-connect-session-1_0.html#RPLogout

I see that post_logout_request_uri must be checked against
post_logout_request_uris, but to do that I need to identify from which
RP comes the logout request.

In the login flow, we receive the client_id, so we can easily get
configuration of this RP on OP side.

But in the logout process, we just have:
* The referrer, which may not be a safe way to identity the client
* The ID Token hint, but it is only recommended, not mandatory

How are we supposed to identity the RP of the logout request?


--
Clément OUDOT
http://www.lemonldap-ng.org

[John Bradley]

You can't unless they send the id_token hint.

Without knowing that it is a trusted RP you need to present the user with a dialog to determine what they want to do.

John B.

> --
> You received this message because you are subscribed to the Google Groups "OpenID Connect Interop" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openid-connect-in...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Clément OUDOT]

2015-04-03 17:06 GMT+02:00 John Bradley <ve7...@ve7jtb.com>:
> You can't unless they send the id_token hint.
>
> Without knowing that it is a trusted RP you need to present the user with a dialog to determine what they want to do.
>

Thanks for the answer.

As the openid-connect-session standard is still a draft, maybe your
explanation should be added to it? Or we should require to client_id
as request parameter if post_logout_request_uri is sent.

Clément.

[Brian Campbell]

This question (or very close) has come up before. It sure seems like something needs to be added or adjusted or clarified in the spec.

If a request is received at the end_session_endpoint with only post_logout_redirect_uri and state parameters, what should the OP do? Is that an error condition? Are the parameters just ignored? Is the expectation that the calling client be looked up based on the post_logout_redirect_uri (I'm guessing some OP/AS implementations won't want to index on the value just to support sending the user back somewhere after maybe logging out)?

What if a client wants to use post_logout_redirect_uri but doesn't want to hold onto the id token in order to use it as an id_token_hint? Or doesn't like the idea of passing id tokens around as parameters?

Does the id_token_hint mean that, to use John's words, "it is a trusted RP"? Nothing says that that I see. It mostly just talks about being a "hint about the End-User's current authenticated session with the Client." What if it's expired? What if it's encrypted? Should the signature verify? What if keys have rotated so as to make signature verification impossible? If there is a problem, should the client be informed of the error? Or the user? Or ignore it and move on?

I feel like a different set of questions come to mind each time I read this bit of the spec. That's what came to mind today.

[Clément OUDOT]

2015-04-16 21:31 GMT+02:00 Brian Campbell <bcam...@pingidentity.com>:
> This question (or very close) has come up before. It sure seems like
> something needs to be added or adjusted or clarified in the spec.
>
> If a request is received at the end_session_endpoint with only
> post_logout_redirect_uri and state parameters, what should the OP do? Is
> that an error condition? Are the parameters just ignored? Is the expectation
> that the calling client be looked up based on the post_logout_redirect_uri
> (I'm guessing some OP/AS implementations won't want to index on the value
> just to support sending the user back somewhere after maybe logging out)?
>
> What if a client wants to use post_logout_redirect_uri but doesn't want to
> hold onto the id token in order to use it as an id_token_hint? Or doesn't
> like the idea of passing id tokens around as parameters?
>
> Does the id_token_hint mean that, to use John's words, "it is a trusted RP"?
> Nothing says that that I see. It mostly just talks about being a "hint about
> the End-User's current authenticated session with the Client." What if it's
> expired? What if it's encrypted? Should the signature verify? What if keys
> have rotated so as to make signature verification impossible? If there is a
> problem, should the client be informed of the error? Or the user? Or ignore
> it and move on?
>
> I feel like a different set of questions come to mind each time I read this
> bit of the spec. That's what came to mind today.

I agree, so why not just change the specification (it is still a
draft) to require client_id (if redirection is asked) as GET parameter
of the logout request?


Clément.

[Mike Jones]

If the RP doesn't send you an id_token_hint to authenticate its identity, the simple thing (and probably the best thing) to do is to not do a post-logout redirect. The problem with sending a client_id is that it's not a secret. Anyone can spoof it, so it has no value in authenticating the client.

-- Mike

[Brian Campbell]

(adding the WG mailing list this oldish thread from the interop list https://groups.google.com/forum/#!topic/openid-connect-interop/lcvz7EXcUJ4)

"If the RP doesn't send you an id_token_hint to authenticate its identity, the simple thing (and probably the best thing) to do is to not do a post-logout redirect." -> if that's the expected/intended behavior, the spec should say so

"The problem with sending a client_id is that it's not a secret.  Anyone can spoof it, so it has no value in authenticating the client."  -> that's true but the same mechanism is used in OAuth/Connect at the authorization endpoint to identify the client and determine allowed redirect URI(s). Why is it different here?