Oauth/token endpoint response is slow

Hi everyone,
We are experiencing a number of slow calls to the oauth/token endpoint and we are trying to understand what is causing them.

Our system uses short-lived (2 minutes) access token and we call getAccessTokenSilently (this is a react SPA) periodically to fetch a new token if we are approaching the end-life of the current one using a refresh token (with a higher lifetime)

However, we have noticed pretty slow responses, especially if the user hits the page after the previous token has already expired (so basically if they close the app and reopen if after 2 minutes). The requests can take up to 2s from time to time. I’ve attached a picture with the timing results from chrome as an example of it.

Is this something expected, a server side issue or something we are not doing properly on our end?

Hey there @luca1 ,

Thank you for sharing specifics of your problem and sorry for slight delay with the answer.

In my locally hosted sample SPA app, it takes exactly the same amount of time.

To have more visibility into it, I would like to propose to review the “Initiator” tab of your browser developer tools for the request you measure timing. Based on what I see and understand, there is more requests happening in this chain than only oauth/token → final authorization response, including contacting server hosting your app code and auth0 credentials or loading your app images and other resources into the end user browser. Thus, I would say the timing is also depended on the end user internet connection performance.

I remain available for any follow up questions on this topic!

Hi @marcelina.barycka, thanks for your reply.

According to chrome explanation the waiting for server response only measures the time for the client to get the first byte from the server. As such, this is in practice the time the server (Auth0 in this case) took to prepare the response. The time taken to load the website static files and fire up the page javascript are not included in this metric.

Hi @luca1 ,

By default, refresh token is stored in the window session storage object and closing a tab/window ends the session and clears objects in sessionStorage.

Thus, reopening your react SPA app makes it impossible for the refresh token rotation grant to happen and the silent authentication (cookies based) takes place. Silent authentication uses the legacy technique of using a hidden iframe and the authorization_code grant with prompt=none and based on my tests, it takes longer than when I simply refresh currently opened page utilising refresh token rotation grant. Do you observe the same behaviour?

I don’t think there is any issue with how you have configured your app with Auth0, and to me this is a matter of different mechanisms applied in the described scenario versus when you can make use of currently stored refresh token.

Please let know if that answers your questions!

Hi @marcelina.barycka

Our token is actually stored in local storage (we specified cacheLocation=“localstorage” in our app and I can see the entry in my local storage tab in the browser) and not in session storage, so it should not go through the hidden iframe workflow.

can I ask what is the expected server time for this request? Is there any guarantee on how long it can take at most?

Hi @luca1 ,

Thanks for sharing details on your setting!

Based on my further investigation, I would say there is no expected time to response as this is really quite multi-factor thing. It’s explained here.

When it comes to your use case, a factor to investigate might be the limit of active (valid) refresh tokens per user per application.

We have an article on performance best practices.

There is also option to perform load test and share it via support ticket (for customers with subscription allowing them to contact Auth0 support center) - this way, knowing the specific circumstances, Auth0 engineers can investigate it further. The proces is described here.

I can see you have opened a support ticket on this problem, and I belive it’s best to continue there as via a support ticket you can share information, that due to security considerations, can’t be shared here.

I remain available in case of follow up questions.

The key takeaways from the internal investigations were to -

  • migrate legacy Rules to Actions
  • use Actions built in methods where possible
  • upgrade npm modules used in Actions in case they are outdated

Ref - Performance Best Practices

Please feel free to respond in case of any additional conclusions or questions!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.