Decrypt id_token_hint and pass it at disconnection

[maxime-helen]

Hello,

Many thanks for the module, it unlocks our oauth setups very fast

However we hit an unusual issue with a single identity provider requiring JWE, only at disconnection. They indeed expect us to provide decrypted id_token_hint to the /session/end/ call, but we send it raw as we receive it. The request ends up to a bad request because the identity provider doesn't have our private key to verify the id token hint, from what we heard from them

Would you have some suggestions on how to deal with this problem ? Would there be some configurations to tweak to send id_token_hint with the expected format ?

Thanks again

[zandbelt]

that is interesting: why would they want to send encrypted ID tokens if they want to be able to inspect that same token at logout? the spec suggests to use a shared symmetric key in that case: https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout so the OP would have the decryption key as well as the client

[maxime-helen]

Oh really? Here is the official technical doc of the OP (no english translation available sadly, pardon our french ahah). I am not sure why they made their key assimetric. Contacting support at the same time about the matter

[sherman-dinum]

Dear maxime-helen and zandbelt,

Following the support ticket we received from maxime team, we would like to exchange information about the OpenIdConnect spec and the id_token_hint parameter so that maxime can have his problem solved.

We also agree that it would be better to share on the logout endpoint the id_token_hint encrypted when the token endpoint is configured to use encryption. The issue is more of the complexity of the implementation and the lack of clear information (from our point of view) in the OpenIdConnect spec.

To give you some context, we are using a NodeJS module OP library listed in the OpenId Foundation's certified libraries: https://github.com/panva/node-oidc-provider. From what we understand, it seems to be the case too for zandbelt implementation.

Regarding the logout, our library use https://openid.net/specs/openid-connect-rpinitiated-1_0-final.html#RPLogout spec (the link is not the same as the one provided upper, but seems to have mostly the same content regarding the RP-Initiated Logout).

From what we understand, the only part mentioning encryption is described in the client_id parameter. This is the only time it is specified in this section to use a "symmetrically encrypted" id_token_hint. The spec says :

client_id: OPTIONAL. OAuth 2.0 Client Identifier valid at the Authorization Server. When both client_id and id_token_hint are present, the OP MUST verify that the Client Identifier matches the one used when issuing the ID Token. The most common use case for this parameter is to specify the Client Identifier when post_logout_redirect_uri is used but id_token_hint is not. Another use is for symmetrically encrypted ID Tokens used as id_token_hint values that require the Client Identifier to be specified by other means, so that the ID Tokens can be decrypted by the OP.

We understand that the encryption mentioned here is an exemple of use. The client_id could be used to retrieve a previously shared key between RP and OP so the later can decrypt the id_token_hint. So there is no spec here, just an example of how it could be done and why. We found no other mention and think that it should at least be reported in the id_token_hint parameter description if there was any. Feel free to comment.

We found a draft spec that seems to be more precise about the encryption / decryption of the id_token_hint in the logout endpoint: https://openid.net/specs/openid-connect-messages-1_0-20.html. The draft tells :

id_token_hint : OPTIONAL. Previously issued ID Token passed to the Authorization Server as a hint about the End-User's current or past authenticated session with the Client. This SHOULD be present when prompt=none is used. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return a negative response. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value.
If the ID Token received by the RP is encrypted, the Client MUST decrypt the signed ID Token contained within the encrypted ID Token. The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token.
For a Self-Issued ID Token, the sub (subject) of the signed ID Token MUST be sent as the kid (Key ID) of the JWE.

So, there seems to be at least a attempt from the OpenID Connect foundation to clarify the encryption / decryption process of the id_token_hint in the logout endpoint. Although, the draft does not specify how the shared key should be exchanged between RP and OP and if it shall be symmetric or asymmetric. Sadly, it seems that this point is left to the implementer. Since the Client MAY re-encrypt the signed ID token, it has two implications:

1. "MAY" could mean that it's the Client choice and the OP must comply with it, but doing so implies that there is a spec somewhere that tells how the key should be exchanged between RP and OP or each Client could have its own ways. This can't be the case since it would be a disaster for OPs.
2. "re-encrypt" could mean that the key used could be different from the one used to encrypt the id_token_hint in the first place. This add to the credibility of the OP exposing a public encryption key to the RP if the chosen algorithm for the id_token endpoint is asymmetrical (We aggree here that symmetrical with CEK or other ket is way better, see after).
   If one of you have a final spec that we missed, please share it with us.

The library we are using does not implement the decryption of the id_token_hint in the logout endpoint and fails immediately when it has more than 3 parts.

At this point, we have not many options from our OP point of view:

1. We could implement the decryption of the id_token_hint in the logout endpoint before passing it to our library, making up for the lack of spec and implementation. This would be a good solution for us, but we would prefer to have a final spec to rely on since other Clients could arg that there is no backing for our interpretation.
2. We could ask the OpenID Connect foundation to clarify the spec or just wait. It would take time and we would have to wait for the answer if there is any (and it could be "not our problem").
3. zandbelt could add an option (if not already the case) to pass a decrypted version of the id_token_hint to the OP logout endpoint. This would be the best solution for maxime and I, but it would be a workaround for the lack of spec and implementation and it means more work for zandbelt.
4. We somehow missed a spec that would clarify the encryption / decryption process of the id_token_hint in the logout endpoint. If this is the case, if anyone passing by find something, please share it here.

To conclude: 1. and 2. would take time and would not be a good solution for maxime. 4. would be the best solution for all and 3. would be the best solution for maxime and I.

Best regards,

[sherman-dinum]

To add to 1., it would need for us to make use of the CEK part of the KEK / CEK pair and that is generated by the OP (US) and used to encrypt the payload. To make this happens, we would probably need to intercept our library call to its own dependencies (npm modules). This is not trivial but would had the advantage to use the already pre-shared key from the token interaction. The downside is that since the library we use generate a CEK for each token as it is a best practice (by design symmetrical is only used for performances of the payload encryption, not for reuse), we would have to store each key for each id_token exchanged in the session since the spec says that OP must accept expired valids tokens.

[zandbelt]

since your implementation allows for storing information, instead of storing the CEK you could store a hash of the encrypted ID token and compare it at logout with the hash of the id_token_hint, which would solve your issue (in fact you may also use that approach for signed ID tokens)

[sherman-dinum]

Thanks for your suggestion, the library we use need the JWS, so we would need to store it too since we would not be doing any decryption. I agree that a hash would be more secure, that's why we are searching for a way to not break the security of the library. Since the CEK would be stored in volatile memory only (we do not have long validity tokens), that would be the less impacting since we let the library handle the rest. Although we would need to intercept one way or another the CEK generated by the library since it is kept internally.

[zandbelt]

Thanks for following up and agreed on this being a bit underspecified, but it just makes no sense to try and decrypt asymetrically encrypted tokens at the OP logout endpoint since:

1. the ID token is encrypted with the public key of the RP (mod_auth_openidc) and can only be decrypted with the corresponding private key which necessarily is only known to the RP (and the typically the reason for using assymmetric encryption in the first place...)
2. the purpose of applying encryption is to make sure only the receiver can see the ID token content; if one is forced to decrypt and pass the token over the internet, that would obsolete the encryption in the first place and possibly leak PII ; to make matters worse, the encrypted token is typically sent over a backchannel upon issuance at the token endpoint but the logout is done over an arguably more insecure front (redirect) channel which would contain the unencrypted ID token...

Rather than creating a workaround in the client, the OP in this case should just issue a signed ID token (since it seems to be OK with the information in the token being public after all?), or ignore the encrypted ID token at logout time. [edit] or act on the encypred value itself or a hash of it, see #1302 (reply in thread) [/edit]

[sherman-dinum]

The problem is that we need the encryption (set mandatory by auditors), even with this incoherence. We can't disable it. We will try to work around something but as said for @maxime-helen it will take time.