fetch multiple access tokens simultaneously

[githorse]

Checklist

• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the 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

My SPA uses many different access tokens. Because fetching these tokens can take several seconds, I wrote code to pre-load them all at app startup, rather than waiting until the user clicks on a specific widget to load the token for that particular API. Since getAccessTokenSilently() returns a promise, I thought I was fetching these tokens in parallel. I can verify that the calls to getAccessTokenSilently() all occur synchronously, within a few milliseconds (in other words, they're behaving as I expect). But a closer inspection of the Network tab reveals that the actual requests to {my-app}.auth0.com/oauth/token are queued up and executed one at a time, meaning that the tokens are fetched sequentially, over the course of 5-10 seconds, instead of simultaneously. I'm not sure where or why this queueing is happening.

Describe the ideal solution

Ideally, these requests would just happen in parallel (up to some reasonable number of connections, perhaps).

Alternatives and current workarounds

An alternative might be a getAccessTokensSliently() (plural) method that handles batch requests.

Additional context

No response

[githorse]

... Bueller?

[ChristopherWirtOfficial]

Is there any update on this? We have the same issue where tokens seem to fetch one at a time. Maybe something with the iframe?

[frederikprijck]

Apologies for the radio silence here.

Calls are deliberately queued up, can you elaborate on why you need multiple access tokens?

Please know that we recommend using a logical API to simplify this.

[githorse]

@frederikprijck - my app uses a number of different services, each of which needs its own token. When the user goes to a new page in the app, I have to first fetch the token, then hit the API(s) for that specific page to get the data. But the token fetch itself can be quite slow, in my experience -- often 1+ seconds, so the page feels noticeably slower to load. For that reason, I figure out in advance (at app startup) all the tokens I might possibly need, and pre-fetch them. That way the token round trip is eliminated when the user navigates to a new page.

If the tokens were all fetched in parallel (what I thought would happen), this would work as intended. But as it stands I have to be careful to load the tokens for the current page first, then go pre-fetch the others, as otherwise I might delay the current page load while fetching some other page's tokens.

The logical API idea looks like it could possibly do what I want, but that would be too invasive a change across our front-end and Auth0 infrastructure to be justified by this performance optimization.

Maybe you could help me understand why the token fetches need to be deliberately queued up? Offhand it's not clear why these logically independent calls can't happen in parallel.

[gyaneshgouraw-okta]

Hey @githorse, @ChristopherWirtOfficial, and everyone else following this thread,

Thanks for bringing this up and for the thoughtful discussion. I can definitely see how parallel token fetching would be useful for apps that need to hit multiple APIs - the performance benefits you're describing make a lot of sense.

Unfortunately, we can't take this on right now given our current priorities, but I think this deserves more visibility and discussion from the community. I'm going to convert this to a Discussion so we can get a better sense of how many folks are running into similar performance issues and what their specific use cases look like.

Moving it to Discussions will give us a chance to:

• See how common this problem really is
• Hear about different approaches people have tried
• Talk through potential solutions and any gotchas
• Figure out if this should bubble up in our planning

If this is something that would help your projects, please jump into the discussion once I move it over. The more real-world examples and community input we get, the better we can understand whether this should be on our roadmap.

Appreciate your patience on this one!