ID Token visible to User Agent during logout

[pamiel]

Hello,

I’m using the mod_auth_openidc to protect the access to a Web UI server, managing the authentication of end-users through the OIDC Authorization Code flow. Authorization Code flow (in opposition to the Implicit Flow) is used on purpose to avoid sending information related to the end user to the external world: ID and Access Tokens, that may contain sensitive/private data on the end user (e.g. e-mail address, roles…), are never sent to the User Agent during the authentication phase.

However, when implementing the logout use case as described in your wiki, the call to the “logout uri” returns a HTTP redirect which Location parameter targets the OP and includes an id_token_hint query parameter. And it looks this query parameter contains the ID Token. If so, we are consequently not compliant with our initial requirement as this Token is now accessible on User Agent side (and not consistent with what is achieved by the Authorization Code flow at login time).

I know that the session is then about to be terminated as we are logging out, but the point is that sensitive data are provided to the external -and untrusted- world during this logout mechanism: there is a consistency issue between the login and the logout use cases, and then security and privacy issues.

Instead of using a HTTP redirect to implement the logout, why not implementing it by manually calling the OP from within the mod_auth_openidc, while processing the HTTP call to the logout endpoint? (as what is done to retrieve the Tokens from the OP (giving the Authorization Code), during the login flow)

Thanks for your answer.

[zandbelt]

This happens to be what the spec defines: http://openid.net/specs/openid-connect-session-1_0.html#RPLogout, a recommended parameter in the request, which is an implementers draft but the thing closest to a standardized logout feature.

A backchannel logout standard is under development http://openid.net/specs/openid-connect-backchannel-1_0.html but that has its own challenges and the spec is not stable, so not implemented yet.

You may want to add a configuration option for omitting the id_token_hint parameter from the logout request. I'd be happy to merge such a PR.

[pamiel]

You mean that we could have an additional query parameter to be set in the "logout uri": when present, mod_auth_openidc would not include the ID Token hint in the redirect URI, but still, the OP (when navigated by this redirect) would be able to identify the logged user to correctly perform the logout? (I'm using Keycloak as OP)

Concretely, instead of having a uri like the following "/protected/redirect_uri?logout=", then we would rather use a uri "/protected/redirect_uri?logout=&noToken=true" where "noToken=true" would act as presented above ?

If yes, then it looks ok for me!

[zandbelt]

well I was thinking about a configuration option in .conf/Apache files so the parameter cannot be modified in the browser at will but your approach looks fast/easy and may be enough for your use case

[pamiel]

Talking with security guys, you proposal looks better as it avoids any attempt to forge a URL that will workaround the protection => having a parameter in Apache conf that would state whether the hint is used or not is finaly preferred for me. Do you have any rough idea on when this enhancement could be made available? Thanks a lot.

[pamiel]

Any idea on when this enhancement could be integrated into a release?

[zandbelt]

I'm working on a commercial offering around mod_auth_openidc; you can contact me on [email protected] to discuss making it part of that.

[pamiel]

By "commercial offer around mod_auth_openidc", do you mean providing commercial support?

Can you confirm that, beyond this commercial offer, you still plan to provide a free opensource delivery of mod_auth_openidc under Apache 2 license? with the full set of features?

Thanks

[zandbelt]

The free open source version will still be provided in the same fashion as today. I'll provide more info on the commercial program asap. (on a separate note)

[zandbelt]

there are two known workarounds: 1. use backchannel logout or 2. use OIDCSessionType client-cookie so no compelling need for this (anymore)