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.

[CharlesEkkel]

Sorry for commenting months later @frederikprijck, but does this mean this is not a feature that is likely to be implemented? We are hoping to run at least 2 calls to getTokenSilently for different client ids on the same webpage, but are running into the mentioned issue where the lock causes multi-second gaps between each call. We have two client ids, because one is for a part of the webpage that is shared with a different application (so it can't use the same client id as the host page).

I can appreciate the idea of having a single logical API, but I'm not sure if it helps in our case, unless we just abandon the idea of having multiple client ids. Please let me know if I'm mistaken, I'm relatively new to auth0, but otherwise it still seems like it is worth changing something about the lock in getTokenSilently.

[frederikprijck]

We have two client ids, because one is for a part of the webpage that is shared with a different application (so it can't use the same client id as the host page).

I am not sure i see why it cant use the same client id.

That said, i believe two different client ids is different than two audiences, and i can see it could make sense to have a lock be bound to the client id, but i believe it makes less sense in your use case, but more when we consider two tabs with two different application. Also a logical API solves multiple audiences, not multiple client IDs. But I would recommend reconsidering if u can use a single client id.

Even though it would help for your usecase, i don't believe this to be something that can be prioritized on the short term.

That said, maybe a PR may be accepted for this if u have a strong need, but i redirect that to @gyaneshgouraw-okta and @nandan-bhat .

[CharlesEkkel]

Absolutely. Thanks very much for the prompt and helpful reply.

To try to explain, our use case is that we would prefer to use different client ids to maintain separation of concerns between each host page and this shared embedded application, so that it's more portable (e.g. it does not need each client it's hosted with to be configured with the required claims).

Hopefully there is a possible solution I or someone else can make a PR for, but in the meantime, we'll look into alternatives.

Edit: after reading through the code for the Auth0Client it seems like even if we were using the same client id, we'd still have this issue anyway, since it uses the in-memory cache which does not appear to share the cached tokens between instances of the class (and our host page & shared app have separate instances of Auth0Client).

[wuunwkn]

https://sso.redhat.com/auth/realms/redhat-external/account/

[CharlesEkkel]

Sorry @wuunwkn, but I'm not sure what that link is meant to indicate. Does redhat have a similar problem?