Too many requests in oAuth2 flow

Help
1

Hi all , we currently started working with Auth0 and having some issues with 429 too many requests.
Basically our current flow is as follows:
We have a single page web application that send an idToken to our backend service , which is validated using GoogleIdTokenVerifier (Authentication)

We wanted to use Auth0 as an Authorization framework so our flow that we wanted to implement was to add after the user is really authenticated , get the user , get his roles and save it in our Principal object.

So basically there are multiple API calls here (ListUsersByEmail to get the userId , getUserRoles to get the roles of the user)

But because the authentication is being called in every API call we are in a state when we hammer Auth0 management API service and getting the 429 error.

So , first of all , maybe our flow is incorrect and there is a better way to implement this?

If not, how do you suggest to overcome this problem?

I thought to implement a custom service that will keep all the users and their roles in memory and will update it every X time, but I’m not sure this is the correct approach.

Thank you

3

Hi @levyshachar2,

Thanks for joining us in the Auth0 Community!

First of all, take a look at our rate limit policy. Just to get an idea of what the limits are. Our users typically don’t run into issues with the limits unless something is not working as intended.

Next, I have some questions/suggestions about your flow:

  • Are you receiving the ID token from Auth0? If so, the sub claim contains the user_id and you should not need to use ListUsersByEmail.
  • You can replace the GetUserRoles call by adding the user’s roles to the token in a rule as a custom claim. Keep in mind this may not reflect the current state of roles if they are updated after the token has been issued, and you should refresh the token after you update roles to solve this issue. (refresh tokens and short expirations can alleviate this).
  • You could also store a copy of user and roles in a local DB, as many Auth0 customers do, as user data not specific to the authentication process is often too big or irrelevant and should be stored elsewhere anyways. This will require you to keep two data stores up to date concurrently, food for thought.

Let me know if you have further questions, or if I missed something.

Thanks,
Dan

4

Hi @dan.woda
thank you for your reply.
Regarding your first point , we only have idToken from google (we currently don’t use Auth0 for authentication , only for authorization)
So I need to use ListUsersByEmail as I don’t have the id of the user.

Regarding the second point, I understood from the documentation that each rule request is also part of the API rate limit, so is changing that to a rule will actually help?

For now We managed to reduce a certain amount of requests by using DropWizard caching authenticator.

We also thought about using redis / custom DB for keeping the users and roles , but I think this is kinda countering Auth0 purpose, we wanted to use Auth0 as it looked easy to implement and integrate for our scenario of handling users and roles.

It seems weird for me that when using oAuth2 authentication which in every request you need to authenticate , there are rate limitations for the Auth0 management API.

Again , thank you very much for your assistance

5

Sorry, I misunderstood your first post.

Are you using G Suite as your IDP? You could integrate with Auth0 if that is the case.

6

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