Trying to design basic authentication/authorisation system for API

I figured it out without the help of the sales people, the pre-sales engineer, the documentation, and the web ui, all were dead end useless time sinks.

So in M2M, “applications” (i.e. non-human users, tenants, entities, consumers, etc.) receive a fixed unfriendly id (aka client id), and a secret (aka client secret). Applications hold the authentication credentials.

You can then allow applications to be authorised by one or more of your APIs. Therefore a consumer can use multiple distinct APIs and authenticate with the same credentials.

For API GW, I think you can use custom authorisers that will accept client credentials, forward it to auth0, which will respond with a JWT, which can be returned to the consumer for subsequent use with your API endpoints that require authorisation.

Lastly, you can apply “scopes” for granular authorisation per application.

Hope that clarifies things for anyone looking for an API key/secrets management for multiple consumers that you want to authenticate/authorise to your API. It is called the “client credentials” flow which documentation talks about but doesn’t provide decent examples and glosses over the whole multiple consumer management using “applications.” I had to brute force the system to figure this out.

1 Like