You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@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.
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.
Activity
githorse commentedon Mar 24, 2025
... Bueller?
ChristopherWirtOfficial commentedon Mar 31, 2025
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 commentedon Mar 31, 2025
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 commentedon Apr 1, 2025
@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 commentedon Jun 19, 2025
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:
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!