What is the correct method to protect client-facing API?

We have already implemented Auth0 logins for our client-facing application using the Laravel and PHP libraries. We now want to give certain selected clients access to an API.

I understand how OAuth2 works, and flows such as Client Credentials flow and Authorization Flow.

Each access token needs to be identified to company, so we can ensure a company cannot access another company’s data.

But I don’t yet understand the best way to use Auth0 to provide authenticated access to certain client.
Should each company/client get it’s own Machine-to-Machine Application within Auth0? Should there be a single Machine-to-Machine Application that can programmatically issues a token to each client? Or within my application, should I use the Management API to provide a token which they can use to access my API?

You probably do not want a situation where multiple customers all share a single client id+secret pair.
I think I would assign each customer their own M2M application in Auth0, and add a metadata flag on each one that signifies which customer it belongs to.

Then I would add an Action that programmatically pulls that metadata and places it into the access token in a custom claim. This will allow your API to pull from the Access token what customer is calling; allowing you to know that the request actually came from the correct customer.

You probably do not want a situation where multiple customers all share a single client id+secret pair.

100% correct. Each needs their own segregated data, so the API would need to be able to identify each customer, or each company.

(Within our API, if we can identify a customer, we can identify which company(s) they have access to.)

I think I would assign each customer their own M2M application in Auth0

This seems manageable now where we might have ten clients who want API access. If that number grows to a hundred+ though, that’s unmanageable, unless we build tooling around the management API to automate that whole process.

The way you make a client id and secret pair is by making a M2M application. If you want separate credentials for each of your customers, you need 1 M2M application for each of your N customers.

The applications and APIs in Auth0 are just a model for your system. It doesn’t actually need to fully represent the code that is running. In this case, it may be easier to think of them as “clients” instead of as “applications”. The Management API and Terraform Provider both refer to them as clients.

Baseless idea for an implementation if you still want to only have 1 M2M client for all of your customers:
You could build an facade service in front of Auth0 that checks the customer credentials in your own database, and then calls Auth0 for the real token with a shared credential and the customer name.

1 Like

Hi.

I know this question is old, but I want to insist in this idea a bit.

Imagine a web dashboard with certain features, already integrated with Auh0 as an SPA/Web app. Now, my company wants to offer the exact same set of features, but instead of a web page, we want to offer it as an API (probably the same as the dashboard uses or a very similar one), so the customers can create their own software to automate some use cases. What is the best approach: we want to offer a self-served mechanism, so the user gets credentials from the dashboard for their automation processes (client_id and client secret?) and use them with the Client Credentials Flow (OAuth 2.0 RFC 6749, section 4.4). Do we really need to create a new application in Auth0 for each one of them? Or is there a different and better approach to handle this?

Thanks!

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