Provisioning credentials per-client

Get Help
,
1

We’re looking at moving off of our own auth for our external API that’s accessible by a subset of our customers (machine to machine). Basically, we have several hundred customers for which we want to grant access, but with their own, distinct client ids and secrets to keep access tracked and limited. The general idea would be that our customer would make a request to Auth0 for a token, then submit that token to our API, which would validate it for authenticity and scope before serving any data.

From my reading, it sounds like Auth0 wants there to be an Application per customer if we want distinct ids and secrets, but it seems really cumbersome to provision a new application for each new customer we onboard.

So my question is: is there a way to implement this that I’m missing? If not, what’s the “Auth0” way to accomplish this?

3

Hi @octopushugs,

Welcome back to the Auth0 Community!

I understand that your use wants to support a machine-to-machine (M2M) API architecture where several hundred customers each require their own distinct client IDs and secrets. Auth0’s recommended best practice is indeed to provision one M2M Application (Non-Interactive Client) per customer.

While doing this manually in the Auth0 Dashboard is cumbersome, you do not need to do this manually. Instead, you should programmatically automate the entire onboarding workflow using the Auth0 Management API.

How the Automated Workflow Works

When a new customer joins your platform or requests API access via your portal, your backend application will programmatically handle provisioning in the background:

  1. Create the Customer’s M2M App: Your backend makes a call to the Auth0 Management API: Create a Client endpoint. You define the application as a non_interactive client (M2M) and specify the client_credentials grant type

  2. Authorize API Access (Scopes): Your backend then calls the Auth0 Management API: Create a Client Grant endpoint. This associates the customer’s new Client ID with your custom API (audience) and specifies the exact scopes (permissions) they are allowed to request

  3. Present Credentials Securely: Your backend receives the newly generated client_id and client_secret from Auth0 and displays them to your customer in your developer portal (similar to how Stripe or AWS displays API keys once upon creation)

This automated approach is far superior to sharing a single application or trying to build a custom multi-tenant wrapper for:

  • Security Boundaries & Rotation: If a customer compromises their credentials, you can programmatically rotate or revoke their specific client secret without disrupting any other customer on your platform.

  • Auditing and Tracking: When your API receives an access token, the JWT will contain an azp (Authorized Party) claim matching the customer’s unique client_id. This allows your API gateway to immediately identify, rate-limit, and audit that specific customer’s usage.

Additionally you could also check out this documentation pages for further insights:

I hope this helps and if you have further questions please let me know!
Best regards,
Remus

4

Got it, thanks very helpful! Is there a limit to the number of applications we can create?

5

HI @octopushugs,

I am glad that the proposed architecture for provisioning credentials for clients helps you use case.

When it comes to the number of applications limit per tenant, this depends on the subscription plan of choice. You can check out our Entity Limit Policy for further details.

Thank you!
Kind regards,
Remus