The Code_Verifier does not match the code_challenge

Library

• msal@1.x.x or @azure/msal@1.x.x
• @azure/msal-browser@2.x.x
• @azure/msal-node@1.x.x
• @azure/msal-react@1.x.x
• @azure/msal-angular@0.x.x
• @azure/msal-angular@1.x.x
• @azure/msal-angular@2.x.x
• @azure/msal-angularjs@1.x.x

Framework

• Angular
• React
• Other

Description

Error Message

Uncaught (in promise) ServerError: invalid_grant: 501481 - [2021-03-19 13:18:03Z]: AADSTS501481: The Code_Verifier does not match the code_challenge supplied in the authorization request.

MSAL Configuration

const initMsal = ({msalConfig}) => {
  const postLogoutRedirectUri =
    process.env.AZURE_AD_REDIRECT_URL + '?redirectTo=' + origin + '/logout'

  const auth = {
    postLogoutRedirectUri,
    cloudDiscoveryMetadata,
    authorityMetadata,
    ...msalConfig.auth
  }

  const cache = {cacheLocation: 'localStorage', ...msalConfig.cache}
  const config = {...msalConfig, auth, cache}

  return new PublicClientApplication(config)
}

Reproduction steps

I’m using silent SSO and using a cross-domain postMessage broker to retrieve the login hint. The first time the page is loaded (clean cache) I get the above error. It would further seem that the user is actually logged in: .getAllAccounts() has an account and the next load logs the user in instantly. Didn’t include code as it doesn’t seem pertinent, would be happy to provide anything necessary.

Expected behavior

The user should log in with no interaction

Identity Provider

• Azure AD
• Azure B2C Basic Policy
• Azure B2C Custom Policy
• ADFS
• Other

Browsers/Environment

• Chrome
• Firefox
• Edge
• Safari
• IE
• Other (Please add browser name here)

Regression

• Did this behavior work before? Version:

Security

• Is this issue security related?

Source

• Internal (Microsoft)
• Customer request

[tnorling]

Found that the application code is passing in state with the current url and making several ssoSilent requests. On the 2nd call to the /authorize endpoint this url stored in state somehow has the response hash from the first call to the /authorize endpoint this results in a response url that has 2 codes in it: the code returned from the server and the code from the first call that was added to state. This resulted in a mismatch when exchanging the code for a token.

Mitigations are to:

1. Strip the hash off of the url before passing into state
2. Make sure the page used as redirectUri is not invoking msal APIs or altering the hash on page load (you can use a blank page for silent and popup scenarios)

MSAL should be blocking auth requests inside hidden iframes so it’s not clear how the 2nd call is getting the response url from the first.

[tnorling]

@mbrevda This is likely a usage issue, can you provide as much relevant code so that I can try to reproduce? Also a fiddler trace would be helpful so I can check against server logs. You can email it to me, my emails on my profile. Thanks!