Invalid Id Token Nonce

[DanielMalmgren]

Hi again. I've bumped into another problem... I've finally got my idp to send correct id tokens (it turned out it never did because of a certificate problem here) but now when it gets to jitsi-openid I only get the response "Invalid Id Token Nonce".

I've checked that the functionality to return nonce in my idp works fine, if I manually send in a nonce I get the same nonce back in my id token, so it seems jitsi-openid handles this wrong in some way. Could you check in to it? One alternative would be if there was any way to disable the nonce verification entirely?

[DanielMalmgren]

After more testing I can verify that the nonce check is broken, the exact same string is sent back and yet it says that it's invalid. Big question is what it expects to get instead...

[DanielMalmgren]

This goes very slow because of my limited understanding of the strange rust language, but I think I have a new angle on this problem. If I understand things correctly, the IdToken::claims() method can return a ClaimsVerificationError which may signal a whole load of different problems ((https://github.com/ramosbugs/openidconnect-rs/blob/main/src/verification.rs#L32-L71)). If I understand the map_err method correctly it seems that you then squash all these errors into one single error message, "Invalid Id Token Nonce". So I think this actually isn't related to the nonce at all but could be something completely different.

However, I haven't succeeded in actually showing what IS wrong, all my attempts turn up with the code not compiling at all. Do you think I'm on the right track here? And is there anything you can do to help?

[DanielMalmgren]

Ok, I have now confirmed that I was right, this has nothing with nonce to do. I put the following code in my error.rs:

impl From<openidconnect::ClaimsVerificationError> for AppError {
    fn from(error: openidconnect::ClaimsVerificationError) -> Self {

        info!("Claims error: {}", error);

        AppError::InvalidIdTokenNonce

    }
}

...and now I get "Error: Signature verification failed" in my log, so obviously something is wrong with my signature, though I can't find any fault. If I understand https://github.com/ramosbugs/openidconnect-rs/blob/main/src/verification.rs#L78-L116 correctly I'm supposed to somehow get a more detailed description of the problem, but I don't know how :-/

[DanielMalmgren]

Hi again. I think I've fixed the big problems (I filed a issue with ramosbugs and got help). Turns out I'm using RS512 and the standard is RS256. So I added a little call to allow_any_alg() before the call to claims(), now it accepts my id token!

Then I got another problem worth mentioning here, I got "Missing Access Token Hash - if you can't configure your IDP to provide an access token hash (delivered using the id token), reach out to me to implement some kind of workaround: https://github.com/MarcelCoding/jitsi-openid/issues/new". I got around it by simply commenting out the check (lines 186 to 201 in routes.rs) but I guess I should handle it in a better way. Not really sure which hash it's talking about here?

[MarcelCoding]

Ohh, I am really sorry. I've let this issue unread in my inbox as a reminder for myself. And because of that I didn't noticed that you wrote. Yes I think there should be a besser solution, I'll try to look into it tomorrow evening what tge reason for the check is and if there are any alternatives? Did you found any permanent solution for the signature alugrithen, other then playing in the code, maybe I have tge option to configure them. Normally all supported algorythem are transfered in the discovery endpoint. Maybe you could post an snapshot of your idp's response. Just open the list in the browser, no fancy configuration needed. I think it is issuer-URL/.well-known/openid-configuration

[DanielMalmgren]

Well, I'm not really clear on why the algorithm used is important. My code currently looks like this and works fine:

  let verifier = client.id_token_verifier();

  let new_verifier = IdTokenVerifier::allow_any_alg(verifier);

  let claims = id_token
    .claims(&new_verifier, nonce)?;

I suppose the correct solution would be to use set_allow_algs() instead and adding an option for configuring it.

My openid-configuration has "id_token_signing_alg_values_supported" : [ "RS512" ] but if I understand things correctly ramosbugs doesn't currently read this. (so maybe the optimal solution would be to fix it in that end?)

[MarcelCoding]

Wow, ok, I think I am going to create a pr in the upstream library and temporally use my fork again

[MarcelCoding]

I am nearly home :D

[MarcelCoding]

I've just done it so, that the signing algorithms for the id token are being respected for the validation. Could you perhaps try it: https://github.com/MarcelCoding/jitsi-openid/commit/ec2bacb22b762b92e27da130509b8720f3159473 The docker image is tagged with edge and the binaries are available via GitHub Actions artifacts. (see linked commit)

[MarcelCoding]

If everything is working fine, I will change this PR https://github.com/ramosbugs/openidconnect-rs/pull/87 to a real one (remove the draft state). I may also implement the discovery of the algorithms of the other stuff.

[DanielMalmgren]

Looks good! Unfortunately I don't think I can't test it out-of-the-box, since the hash checking doesn't seem to like my hashes (currently I'm running on a version that I compiled myself where I commented out line 186-201 in routes.rs). Is it worth digging into that problem first?

[MarcelCoding]

Ok, I forgot about that, I'll look into this as well ths evening.

[MarcelCoding]

Hi, I am back :) Sorry for the long time of inactivity here, work is hard... I'll look into this week, for sure :)

[DanielMalmgren]

No problem. I'm running my own version here (where I've disabled the hash checking and allow all algorithms) which works for me so I kinda forgot about this :-)

[MarcelCoding]

Ok, sorry for the another late response. I dug into the internals and found out that the error you are describing, can be thrown for multiple reasons. As for that, I've updated the error message. It would be fantastic if you could run my version (branch main) just for a short time and send me the new message. That would help to further track down the reason for this error. That you in advance :) https://github.com/MarcelCoding/jitsi-openid/commit/6a248686719d335fe4410d62db80bd8e76669a6d

[Dleewee]

I am seeing this issue now after recent upgrade of IDP tool (Authentik). I have pulled latest docker image for this project but seeing the error after successfully redirecting and signing in to IDP, then I tries to redirect back but shows: Invalid Id Token Nonce: Signature verification failed

If I generate a new certificate and use for signing, I actually get a different error: Missing Access Token Hash - if you can't configure your IDP to provide an access token hash (delivered using the id token), reach out to me to implement some kind of workaround: https://github.com/MarcelCoding/jitsi-openid/issues/new

As it seems related to the IDP certificate, do I need to embed it somewhere in jitsi-openid? Also, if I set - 'VERIFY_ACCESS_TOKEN_HASH=false' Then the response becomes Failed to deserialize query string: missing field "code"

Let me know how I can help troubleshoot. Thanks!

[MarcelCoding]

Hi, since recently I also maintain a authentik instance and noticed a similar behavior while updating to v2024 and signing in to netbox. As the error seems similar, I will come back after I have solved the error with netbox.

[Dleewee]

Hi again. I changed a couple of things and now once again have authentication working.

• Upgraded Authentik to latest release (2024.2.1), I believe this was just pushed out today as the official release notes still say unreleased in the title
• Added - 'VERIFY_ACCESS_TOKEN_HASH=false' to jitsi-openid docker environment
• Removed - 'SCOPES=openid email jitsi offline_access' from jitsi-openid docker environment (the offline access scope was added in 2024's release, so I had added it earlier while troubleshooting. Seems this refresh token is not needed by this project.

Still, I hope you are able to identify why the token hash error is generated, as I assume it would be more secure to enforce token hash verification. Thanks!

[MarcelCoding]

Could it be that authentik does not support access token hashes? I could not find any kind of documentation.

[Dleewee]

Could be, though it's odd that it just cropped up after the 2024 release. Maybe we'll see a big fix on their end.

On Sat, Mar 2, 2024, 12:28 PM Marcel @.***> wrote:

Could it be that authentik does not support access token hashes? I could not find any kind of documentation.

— Reply to this email directly, view it on GitHub https://github.com/MarcelCoding/jitsi-openid/issues/148#issuecomment-1974872052, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4HLYBEHIBBUEJ7GNNXDCLYWIK4PAVCNFSM6AAAAAAQMKFDOSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZUHA3TEMBVGI . You are receiving this because you commented.Message ID: @.***>

[jeehoonkang]

I wonder if anyone solved this issue with the recent Authentik upgrades. For me,

• Auth initial works;
• After for a while (a week or so) auth becomes not-working with the message "Token verification failed. Invalid ID token nonce";
• The problem is resolved if jitsi-openid docker container is restarted.

[MarcelCoding]

Is your authentik regenerating keys? Jitsi-openid only executes the discovery (including public keys) at startup.

Sorry if this is a stupid question, I am not familiar with authentik.

[jeehoonkang]

My Authentik instance has used only one public/private key pair.

(In fact, it seems Authentik developers are considering to support key regeneration feature in the future, https://github.com/goauthentik/authentik/issues/7242 :)