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: ec2bacb
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 ramosbugs/openidconnect-rs#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 :) 6a24868