JWTVerifier alternatives

[kuma-guy]

Document says that JWTVerifier is used to decod token, but the current version has no JWTVerifier. How can I decode token?

https://auth0.com/docs/libraries/auth0-php/jwt-validation

[joshcanhelp]

@kuma-guy - Apologies for that! It looks like that was not updated since the latest major release. You can see how it works in the SDK here:

https://github.com/auth0/auth0-PHP/blob/master/src/Auth0.php#L645-L670

But, in short, your code should look about like this, assuming you're working with an RS256 token and are checking for a nonce:

$jwksFetcher = new JWKFetcher($this->cacheHandler, $this->guzzleOptions);
$jwks        = $jwksFetcher->getKeys(JWKS_URL_HERE);
$sigVerifier = new AsymmetricVerifier($jwks);

$idTokenVerifier = new IdTokenVerifier(TOKEN_ISSUER_HERE, $this->clientId, $sigVerifier);
$decodedToken = $idTokenVerifier->verify($idToken, ['nonce' => NONCE_VALUE_HERE]);

I'll make sure the docs get updated ASAP. Thank you for the report!

[kuma-guy]

@joshcanhelp Thank you for the explanation and updating the docs!

[kuma-guy]

@joshcanhelp

I'm sorry to ask you again.

I notice that IdTokenVerifier accepts audience as second parameter
https://github.com/auth0/auth0-PHP/blob/master/src/Helpers/Tokens/IdTokenVerifier.php#L51

On the other hand, updated document set client_id . Are client_id and audience same?

[joshcanhelp]

No apology needed, we're here to help!

On the other hand, updated document set client_id . Are client_id and audience same?

The audience of a JWT depends on the context. If you are an application and you're validating an ID token for the purpose of signing in, then the audience will be the client ID (the ID token was generated for that specific application). If you are an API accepting JWT-formatted access tokens (like the ones that Auth0 generates), then the audience will be the audience that represents you, the one requested on the authorization endpoint.

[chillyistkult]

So TokenVerifier class does not accept multiple audiences in the config anymore (like JWTVerifier did before). What is the desired authentication flow if I have an API that is consumed by a client and another API, hence the need for being able to validate for multiple audiences?

[joshcanhelp]

an API that is consumed by a client and another API

Can you explain this a bit more? I'm not following what the use case is here.

But, to explain the change here ... ID tokens should only be validated by the application (Client) that's being signed into. Access tokens should only be validated by the API (Resource) that's receiving them. If you have a token of either kind that's being validated by two entities, then there might be a problem with how your solution is architected.

[chillyistkult]

Can you explain this a bit more? I'm not following what the use case is here.

I have two APIs developed by different teams (API 1 and API 2). Additionally we have a SPA (Frontend). Both APIs (M2M applications) are "grouped" into an Auth0 API (so they have the same audience). However the frontend (Auth0 SPA application) has a different audience. So when the frontend is calling API 1, API 1 needs to check for the audience of the frontend token, but API 1 is also called by API 2 which has a different audience.

This wasn't a problem in the past because there was a field in the config valid_audiences and I could pass the audience of API 2 and the frontend there. Now it only allows to check for a single audience...

[joshcanhelp]

API 1 needs to check for the audience of the frontend token, but API 1 is also called by API 2 which has a different audience.

I'm still confused here. The API that's being called should be receiving access tokens with itself as the audience. Different applications calling the same API should be requesting access tokens with the API's audience.

[chillyistkult]

Actually we do that already from the frontend:

new auth0.WebAuth({
  audience: 'API AUDIENCE',
  clientID: 'SPA CLIENT ID',
  domain: 'AUTH0_DOMAIN,
  redirectUri: `${window.location.origin}${routes.auth}?v=${VERSION}`,
  responseType: 'id_token token',
  scope: 'email openid profile roles',
});

But the idToken has the SPA CLIENT ID as an audience. So to not confuse you: Yes API 1 and API 2 have the same audience, the problem is the audience of the frontend idTokens.

[joshcanhelp]

Your API should be accepting access tokens generated for that API, not ID tokens generated for your applications. Your API should not need to be aware of the applications that call it and ID tokens should not be sent to other entities. I would take a look at our API documentation for more detailed guidance or our recommended way to architect this:

https://auth0.com/docs/api-auth

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.