Since upgrading to Auth0-PHP 7 to satisfy the sameSite with secure cookie flags, I’m receiving the an Audience (aud) claim mismatch in the ID token error when trying to run
$token_verifier->verify($idToken)
The full error is Audience (aud) claim mismatch in the ID token; expected “MY_CLIENT_ID” was not one of “https://MY_CLIENT_DOMAIN/api/v2/, https://MY_CLIENT_DOMAIN/userinfo”
When I enter the token stored in $idToken at jwt.io for verification, it comes back as valid. I realise I will probably have to provide more info, just not sure what to include.
I am using @auth0/auth0-spa-js 1.6.3 in an Angular 8 app on the front end, redirecting to the Auth0 hosted login page. The token that is issued is then processed by AUTH0-PHP 7.0… That’s where I get the 500 error.
suggests that what you’re sending to the API is an access token suitable to call the Management API or the user information endpoint. In other words this is not the ID token and although the ID token would indeed contain the client identifier as the token audience the recommended approach would likely be to represent the PHP API in the APIs section of your tenant dashboard and then request an access token for that API.
The above would get you an access token with the audience containing the identifier you used to represent your own API and that would be the identifier that you would use for access token validation. There’s reference information about this flow (SPA calling an API) available at (Implicit Flow with Form Post) although this is still using the implicit flow the relevant aspects associated with calling an API (audience parameter) are also applicable to the use of auth0-spa-js with authorization code grant.
Thank you jmangelo. I’ll review carefully the information and links you’ve provided. While I do that, a quick question: why did decoding this token work in version 5 of auth0-php?
One reason I can think of is that it was the wrong process, and v7 is stricter so it now fails… I know that my implementation was wrong in a couple places, and improving it is part of our official backlog. Perhaps this is where I get forced to address these items now.
Yes, when I provided my previous reply I also wondered what could have changed to trigger this simply due to the update in versions. I confess I don’t have vast experience with the PHP SDK, but I would agree with you that a plausible explanation would be that the SDK now performs additional checks. For example, it was previously only checking the issuer of the token and now also checks the audience, but this is just guessing; I’m afraid from past experience I never came upon this particular outcome so unsure about the exact root cause.
Indeed, the problem is an attempt to decode an access token, not the id token.
After following the Angular docs for a setup, all I can get is the access token. I see the id token returned along with the access token on one of the calls to an end-point (think it’s just /token) during the login process… but I’ve not found a way to feed it back to my Angular observable that builds the HTTP interceptor for API calls.
Auth0 v5.5.x decodes the access token just fine. In v7.x I’ve not found a way to do so. I’ve had to give up on this for the time being. Hoping to discover some details toward a working implementation passively, while working on a few other unrelated tasks that need doing.