Support getAccessTokenSilently for multiple audiences in parallel

[amccarthy1]

Checklist

• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the documentation and API documentation, and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

It's impossible in the current implementation to get an access token for multiple different audiences in parallel, as the client acquires a global lock prior to fetching a token. We have the following code snippet:

const [internalToken, customerToken] = await Promise.all([
  getAccessTokenSilently({
    authorizationParams: { audience: workspace.pod.internalApiAudience },
  }),
  getAccessTokenSilently({
    authorizationParams: { audience: workspace.pod.customerApiAudience },
  }),
]);

But in practice, all of the networking is sequential. Since the page cannot fully load until both tokens are available, this adds delays that are impossible to reduce with the current implementation.

Describe the ideal solution

If I call getAccessTokenSilently in parallel with two different audiences, I would like the resulting network request to fire in parallel.

Alternatives and current workarounds

Using localStorage caching is an alternative we've considered, but does not solve the initial login flow when the tokens are not cached, and has obvious security implications.

I've seen recommendations for changing the structure to use scopes instead of audiences, and relying on a single token, but I'd like to keep separate tokens for each of the APIs.

Additional context

Here's a screenshot of the chrome profiler, you can see a lot of time being spent waiting for some of these token calls to come back (the authorize and token network calls are all auth0)

We're working on improvements to the load times of our dashboard, and this is the biggest contributor to latency. The 3 consecutive authentication iframe flows take a combined 2-3 seconds, which adds noticeable delay.

It seems like the lock was implemented to avoid multiple processes fetching the same token, but it seems logical that we could fetch tokens for different audiences in parallel, reducing the impact of these expensive network calls.

[frederikprijck]

Thanks for opening this.

I want to mention that the recommendation is to use one logical API, as per https://auth0.com/docs/get-started/apis/set-logical-api. You can still use mutliple APIs, and have proper permission management between the different APIs (even for customer/internal etc). But the benefit is that the authorization flow is simplified by using a single logical API and would avoid the issue you are having here.

When using multiple APIs, the behavior you are seeing is expected and we encourage you to look into adopting the pattern mentioned in the URL above.

It seems like the lock was implemented to avoid multiple processes fetching the same token, but it seems logical that we could fetch tokens for different audiences in parallel, reducing the impact of these expensive network calls.

The lock was mainly implemented to avoid simultaneously contacting auth0's oauth/token endpoint, regardless of the parameters. Audience is one among alot of properties that can result in a different token, being subject to the same behavior you are seeing.