"RPError: nonce mismatch, expected undefined, got: ..." error when using federated identities

[lpsinger]

I am using openid-client in a Remix app to do Authorization Code Flow with Amazon Cognito, closely following the walkthrough in the README file. If my Cognito user pool is set up to federate a social auth provider (Facebook, Google), then I get error messages that look like this:

RPError: nonce mismatch, expected undefined, got: 5ynH...

I don't think that this is a problem with Cognito itself: although there are reports of similar issues when using openid-client with Cognito (see nextauthjs/next-auth#3551), there are similar problems with Okta (nextauthjs/next-auth#3403) too.

I found a workaround. In my own code (which isn't public yet, sorry, I can't point to it in context on GitHub), I have this:

  const tokenSet = await client.callback(getRedirectUri(request), params, {
    code_verifier,
  })

But it works if I change it to this:

  const tokenSet = await client.callback(getRedirectUri(request), params, {
    code_verifier,
    // @ts-expect-error: Set this to null to disable nonce check.
    //
    // When Cognito is federating a social IdP, it adds a nonce to the callback
    // request, which causes validation to fail, because we did not provide a
    // nonce.
    //
    // Setting nonce to null disables the nonce check entirely, but it angers
    // TypeScript because the nonce property is typed as string | undefined.
    nonce: null,
  })

This workaround allows this if statement in openid-client (https://github.com/panva/node-openid-client/blob/main/lib/client.js#L795) to be skipped:

    if (nonce !== null && (payload.nonce || nonce !== undefined) && payload.nonce !== nonce) {
      throw new RPError({
        printf: ['nonce mismatch, expected %s, got: %s', nonce, payload.nonce],
        jwt: idToken,
      });
    }

Pardon me for being a little bit new to JavaScript and not fully understanding the subtleties of null vs undefined, but is this a bug in openid-client in the if statement above? Or am I not using openid-client correctly? Or is it a bug in Cognito and Okta?

[panva]

It's not an openid-client bug and you've just disabled a very rudimentary check of openid connect. I would not call that a workaround, that's a dangerous action. Sounds like a bug in the IdP openid-client talks to, meaning Cognito.

This check is not meant to be disable-able with null by users, so i'll likely just fix that and devise different means of passing internal signals when nonce is to be ignored (e.g. id token returned from refresh token grant.

[lpsinger]

@panva, thanks, this is super helpful. I'm taking this back to AWS and reporting it as a bug.

[lpsinger]

I noticed 5120a07 adding the skipNonceCheck symbol. As a workaround until AWS resolves this bug, should I be using that symbol?

[lpsinger]

OK, I know this is a bug in Cognito, but what workaround do you suggest with openid-client?

[panva]

I don't have one. Working around non conform IdP behaviours is not something I do.

[panva]

I've reached out to people close to cognito about this bug in their implementation as well. That's about as much as I can do.

[lpsinger]

Ha ha, fair answer. I'll submit this as a bug report with AWS and just pin openid-client until they fix it.

[lpsinger]

I found a safer workaround: as long as I provide my own nonce in my call to client.authorizationUrl, Cognito will return that instead of generating its own.