Auth0 PHP SDK - id token always opaque

  • Which SDK this is regarding: auth0-php
  • SDK Version: ^8.0
  • Platform Version: php 7.4+

Hi. We’re using an application with a m2m configuration, such as:

    $config = new SdkConfiguration([
      'httpClient'      => $this->httpClient,
      // 'strategy'        => 'management',
      'clientId'        => $clientId,
      'clientSecret'    => $clientSecret,
      'domain'          => $this->domain,

    $this->authentication_client = new Authentication($config);

To perform authentication according to a Resource Owner Password Flow. The flow starts with:

  public function login_user(string $email, string $password) {
    return $this->_run_op(function ($arg) {
      return $this->authentication_client->login(
      ['scope' => 'openid offline_access' , 'audience' => $this->audience . '/userinfo'],
    }, ['username' => $email, 'password' => $password]);

In this case, the application is marked as OIDC-compliant, and the audience is the default API URL for our tenant. https://<tenant>.<region>

This roughly corresponds to the case where our application doesn’t need to call an API, because further authorization is performed using custom claims.

See: Adopt OIDC-Conformant Authentication

The first login request above gets the id token fine. The access token is opaque, but that’s not a concern. The id token has all our custom claims, and we can use it to perform authorization successfully.

However, when we try to refresh the id token and access token, ie:

  public function refresh_access_token(string $refresh_token) {
    return $this->_run_op(function ($arg) {
      if (!empty($this->authentication_client)) {
        return $this->authentication_client->refreshToken(
    }, $refresh_token);

The id token (and access token) returned are both opaque. No custom claims are added.

Our custom claims are, of course, scoped properly to a relevant domain, using a rule. Etc. The tokens returned are visibly opaque, and cannot be decoded against the jwt spec.

Please advise.


The only things I needed were:

  • Of course for whichever API to be enabled on the application.
  • To add the custom API, only that custom API, as audience to each call, whether login or subsequent requests for refresh.

That’s all. The only way to obtain fully fledged tokens is to truly signal through API calls that the intended audience is a custom API (whether the app is marked as OIDC-compliant, or otherwise).

1 Like

Thanks for sharing that with the rest of community!

1 Like