4

OpenID Connect, in the implicit flow, returns the id token as a #fragment on the return URI specifically so that the id token doesn't get logged in web server logs.

However, the OpenID Connect logout specifies a querystring parameter id_token_hint which would be the id token of the user who is being logged out.

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

RP-Initiated Logout

An RP can notify the OP that the End-User has logged out of the site, and might want to log out of the OP as well. In this case, the RP, after having logged the End-User out of the RP, redirects the End-User's User Agent to the OP's logout endpoint URL. This URL is normally obtained via the end_session_endpoint element of the OP's Discovery response, or may be learned via other mechanisms.

This specification also defines the following parameters that are passed as query parameters in the logout request:

id_token_hint

RECOMMENDED. Previously issued ID Token passed to the logout endpoint as a hint about the End-User's current authenticated session with the Client. This is used as an indication of the identity of the End-User that the RP is requesting be logged out by the OP. The OP need not be listed as an audience of the ID Token when it is used as an id_token_hint value.

post_logout_redirect_uri

OPTIONAL. URL to which the RP is requesting that the End-User's User Agent be redirected after a logout has been performed. The value MUST have been previously registered with the OP, either using the post_logout_redirect_uris Registration parameter or via another mechanism. If supplied, the OP SHOULD honor this request following the logout.

state

OPTIONAL. Opaque value used by the RP to maintain state between the logout request and the callback to the endpoint specified by the post_logout_redirect_uri query parameter. If included in the logout request, the OP passes this value back to the RP using the state query parameter when redirecting the User Agent back to the RP.

At the logout endpoint, the OP SHOULD ask the End-User whether he wants to log out of the OP as well. If the End-User says "yes", then the OP MUST log out the End-User.

On one hand I can understand why it is desirable to only allow an authenticated user to log themselves out, to prevent certain denial of service attacks. On the other hand though, this process will leave id_tokens scattered through the logs of any server which logs querystring parameters.

Can anyone shed any light on why this is considered to be a good idea?

Thanks

  • I also have this question. I do not understand why it doesn't use the access_token, rather than the id_token. – Rikki Jan 23 at 22:10
1

Fragment encoding does indeed help with the web server logs scenarios, but I wouldn't go so far as saying that it's specifically used because of that.

Nonetheless, you pose an interesting question about including the ID token credentials in a GET request. I think a few things may allow this to be acceptable:

  • If the client is using the implicit flow, the specification also mandates the use of a nonce and additionally mentions that it should be used to prevent replay attacks. If this is the case, leaking the token after it's already been used should not lead to a significant problem as that token would not be accepted again by the client in order to start a new session.

    The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.

  • It's highly likely that the token itself might already be expired when the logout actually happens so reusing it on the client would not be possible. (the authorization server uses it only for context so it does not strictly requires a valid token)

Overall, I think you'll have secure implementations for which passing the token in that request will cause no additional harm and then have other implementations where it may prove to be a significant threat.

However, this trait does not apply only to that specific part of the specification, it's a general thing... authentication and authorization are complex subjects where small details make a big impact and where the landscape is always changing. That's why it's so dangerous to roll your own authentication systems.

  • Isn't the issue that you're including a token that contains user credentials (name, email, etc) in a call to end the session? It feels like it would make much more sense to use the access_token to end the session. Or a 1-way hash of the id_token. – Rikki Jan 23 at 22:09
  • That's an interesting point; technically you can have an ID token without name and email information, but if you need to consider just the disclosure of data as an issue then you may need to go with JWT encryption. However, I don't think encryption is commonly in use at this time. – João Angelo Feb 15 at 11:09
  • Is it possible to request an id_token with no name and email? With the providers I've been testing against (AzureAD, Okta, PingFederate, OneLogin), I typically get a lot of identifying information even though I only request the 'openid' scope. – Rikki Feb 19 at 21:20
  • I guess I just don't understand the rationale behind needing to use the id_token to logout, when there is a specific flow ('code') which stops the id_token getting to the client, which suggests that it's a vulnerable piece of information. – Rikki Feb 19 at 21:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.