We would like to protect our APIs with Auth0. However we do not control the client programs the customers write. As I understand there is no built in way to rate-limit individual clients or cache their tokens for the token lifetime.
It is left up to the client programmer to implement caching and handling of expiration correctly. As we know developers are lazy and sometimes just produce flawed code. We know many clients request tokens way more often than necessary (worst case a fresh token for each API request). That will basically cause a potentially very costly denial of service attack to our authentication service because Auth0 provides no way to limit or cache the token requests.
IMHO this is huge design flaw in the Auth0 product and pricing scheme.
I’ve seen there exists some custom hook script that can use redis database to do some caching / rate limiting. We’re not willing to maintain our own highly available infrastructure to get such basic feature.
Please provide timeline for making M2M authentication actually usable feature of the product by implementing rate limiting and token caching as built-in functionality.
If that is not feasible pricing model should be reworked to not be based on number of token requests.
Thank you a lot for sharing your feedback here regarding that. To bring it to the attention of our managers’ crew can you share it through our product feedback form? It is located here:
Once you do that within 10 business days you will be contacted by one of our product managers to shed some light on it. Thank you1
I’m operating a production service authenticated with M2M Auth0 tokens and we’re constantly dealing with issues of rate limits / quotas on M2M tokens that originate with our clients (whose code we did not write/do not directly control). It’s a huge waste of time/effort on our part to police our third party integrators and their usage of m2m tokens. Built in caching would be tremendously helpful
Submitted feedback on this as well. We have made the decision not to use Auth0 M2M for customer API authentication due to these concerns and limitations.