Custom domains on Prod Tenant with Laravel API returning unauthorized

Help
,
1

We have 3 Tenants, Production, Staging and Development. Production uses a paid account for the custom domain feature, amongst others.

While upgrading our App (a React/Typescript SPA + Laravel BE API) we were using the default domains eg: foobar-test.uk.auth0.com and foobar-staging.uk.auth0.com and got the app working with Auth0.

But for Prod, we also made a custom domain, eg auth.foobar.app

In the FE we have:

      import { Auth0Provider } from '@auth0/auth0-react';
          ...
          <Auth0Provider
            domain={auth0Domain}
            clientId={auth0ClientID}
            authorizationParams={{
              audience: `${auth0Audience}`,
              redirect_uri: `${window.location.protocol}//${window.location.host}/callback`
          }}>
           ...
          </Auth0Provider>

and In the BE .auth0.api.json:

{
    "id": "123abc123abc123abc123abc",
    "name": "Test App API",
    "identifier": "https://test.foobar.app/api",
    "signing_alg": "RS256",
    "allow_offline_access": true,
    "token_lifetime": 86400,
    "token_lifetime_for_web": 7200,
    "skip_consent_for_verifiable_first_party_clients": false
}

auth0Audience in FE matches “identifier” in BE .auth0.api.json
auth0Domain in FE is foobar-test.uk.auth0.com, foobar-staging.uk.auth0.com and auth.foobar.app for Dev, Staging and Prod respectively.

For Test and Staging, we get successful API calls returning data, but for Prod we get 401 unauthorised.

Reverting Prod to use default domain, eg: foobar.uk.auth0.com works.

One added complexity might be we are also using the the Management API in the BE to retrieve user data.

        use Auth0\Laravel\Facade\Auth0;
        $endpoint = Auth0::management()->users();
        $profile = $endpoint->get($user['sub']);
        $profile = Auth0::json($profile);

We’ve been through https://auth0.com/docs/customize/custom-domains/configure-features-to-use-custom-domains but it’s not obvious how it applies in our scenario and can’t figure out the root cause of the 401.

We’ve also been through https://github.com/auth0/laravel-auth0/blob/main/docs/Configuration.md and noticed there is a value called AUTH0_CUSTOM_DOMAIN but it’s not clear how this should be used when our configuration is via .auth0.api.json (and .auth0.app.json).

Any help on how to get this working for Prod/Custom Domain would be appreciated.

Also, it seems we have no way to test this without upgrading the Test or Staging Tenant to a paid service so we can use a custom domain there, which seems like overkill just for testing this. Is there any alternative way to test?

Many thanks.

2

Hey @andy.miller , good to hear from you again.

Understanding your use case is not straightforward with the provided information (not clear where the 401 is coming from), but since you are requesting Access Tokens, I want to make sure you read the APIs section carefully: Configure Features to Use Custom Domains

Some of the things people might fail at first when implementing Custom Domains are related to APIs:

  1. For Auth0 APIs, continue to use your default tenant domain name (such as https://{yourDomain}/userinfo and https://{yourDomain}/api/v2/ ) instead of your custom domain when specifying an audience.

  2. All requests (i.e. obtaining the token, and actually calling the API) must use the same domain. Tokens obtained via a custom domain must be used on an Auth0 API using the same custom domain.

If you use an authentication flow with your Custom Domain to request Access Tokens to access the Management API, you must call the Management API endpoint with your Custom Domain too.

POST https://mycustomdomain.com/oauth/token
... // other parameters 
...
audience:https://defaulttenant.eu.auth0.com/api/v2/

Your Access Token request should be something similar to

GET https://mycustomdomain.com/api/v2/clients

Headers:
Authorization: Bearer <access_token>
  1. Lastly, if you use Auth0 with a custom domain to issue Access Tokens for your APIs, you must validate the JWT issuer(s) against your custom domain.

I hope this helps.

3

Hi Ale, we appreciate your reply and support.

We are not using direct HTTP calls to the Management API, of the nature:

rather, from the Laravel Management Document

So we use the Laravel/PHP Auth0 Facade, and our calls look like this

Presumably the domain being used for the call is being determined by the SDK , perhaps from configuration settings.

Perhaps there is something more need here, for example:

        use Auth0\Laravel\Facade\Auth0;
        $endpoint = Auth0::management('some-overrides-here?')->users();
        $profile = $endpoint->get($user['sub']);
        $profile = Auth0::json($profile);

but I haven’t been able to locate any documentation relating to this.

As for the actual configuration settings (I think the most likely cause of the issue) we refer to the Configuration document and in particular:

We use auth0.api.json and auth0.app.json for the configuration, as exported by the CLI.

However, we note that .env variables can also be used, and in the list given:

we note the AUTH0_AUDIENCE and AUTH0_CUSTOM_DOMAIN variables

However, in auth0.api.json the contents look like this:

And in auth0.app.json:

As can be seen, each configuration method has it’s own naming conventions, for example “identifier”: “https://test.foobar.app/api” matches with AUTH0_AUDIENCE=https://test.foobar.app/api

We see nothing in these .json files relating explicitly to domain, except perhaps the subject in the signing keys and so assume either that is being used, or perhaps from the token received from the FE request.

So we are unsure if or how, to incorporate AUTH0_CUSTOM_DOMAIN into the configuration. We could add it to .env as an environment variable, but that seems to be going against the advice to use .json files exported from the Auth0 CLI. Also, the fact that they are exported from the CLI gives a strong hint that we shouldn’t need to edit them.

I hope I have given enough here so you can see where we might be going wrong, but please do ask for more specific info if needed. We are really keen to get this up and running correctly with Custom Domain, as I noted earlier, it is all working with the default domain.

Many thanks.

4

Hey @andy.miller , I am reaching out via support case.