Trying to design basic authentication/authorisation system for API

I’m writing a new API. The API is fronted by AWS API Gateway.

I want to onboard users such that they can use the API with a shared API secret, that is a managed secret that is enrolled in Auth0 to authenticate a consumer of the API.

The consumer will use their API secret (which will be given to the user manually/out-of-band for now), to call an API endpoint like /get_jwt_auth, which will fetch a JWT provided by Auth0.

I want the ability to disable/blacklist/refuse a consumer based on API secret at any time, and maybe issue a new one (manually) in case there is a breach or compromise on the consumer.

What specific workflow/system do I need to use to make this happen with Auth0?

Do I want to use “client credentials grant” or “OAuth2 authentication code”? How do I do this with API Gateway using custom authorisers?

Anyone, anyone? No one?

I don’t have an answer but I want to do something similar so I’m eager to hear what the community & Auth0 team have to offer. I fear that this is beyond the scope of Auth0’s design and we’ll be required to build our own authentication to gain this kind of control… but let’s wait and see.

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

Thank you a lot for that feedback! Glad you grasped it!

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