We currently use Auth0 to secure out B2B SaaS platform. One of our needs is the ability to provide our customers with API key authentication to allow other system to ingest the APIs we provide.
We referenced a few other threads in this community and our flow is something similar to:
- A user requests a new API key to be generated.
- System generated an Auth0 Machine to Machine application which is stored internally.
- When a user authenticates via an API key, the system exchanges the API key for a token generated by the Machine to Machine client & secret.
- Remainder of services are authenticated via the JWT that is generated in step 3.
This system works very well, except for one limitation. In the self service plans, Auth0 has a limit of 100 applications and since we utilize machine to machine applications for each of the API Keys, we are running into a limit of the number of API keys that we are able to provision.
Are we solving the API Key problem in the correct way?
Is there something we can be doing to avoid having to upgrade to an enterprise plan?
Thank you in advanced for your advice. We have tried to reach out to Auth0 support for reference architectures or examples, but simply haven’t received much help.
Welcome to Auth0 Community !!!
Is there a sequence diagram or some flow diagram you can show us? I am not able to get a clear picture of this system flows.
Thanks for the warm welcome! I have put together a basic flow diagram. Let me know if there are any questions.
Thanks for sharing the flow diagram. My couple of observations/questions:
- Security risk: You are storing client IDs and secrets for all of your clients in your database which can be grab all for anyone breaching your systems.
- Risk of hitting Rate limits if for every call you need to exchange tokens.
- Are these apps background processes apps that do not require user contexts?
- What is the purpose of creating M2M application in Auth0 if you are identifying apps via API Keys?
- what the Service is going to do with your M2M tokens? Is this your service or 3rd party ?
Following on to @jeff0 's thoughts:
Your API key is functionally the same as a client secret. You can simplify your architecture by having one M2M app for each of your clients, and giving them the client secret.
I don’t see the purpose of the added layer of complexity (exchanging the API key for a client secret then a token).
@jeff0 - Thanks for the response. I truly appreciate the observations.
- I am certainly aware of the security implications of this
- One item that we have in the storage mechanism is actually a cache of tokens, in order to avoid rate limiting. We will only generate a new token when the token is expired.
- Yes. Most of these apps are background process apps that do not require user contexts. Either that or the user contexts are for different organizations that don’t utilize the same authorization mechanisms.
- The purpose is to create a system that still provides OAuth tokens in order to authenticate with other internal services in the system.
- The service is an internal service that is not aware of the the M2M token, but rather uses OAuth tokens to authenticate.
Thank you for the response. That is actually a great point. The original idea was to create a system that allows for a single call to authenticate API requests. I suppose that is a double edge sword.