How to implement API keys using Auth0?

Help
, ,
1

We are trying to generate API keys to our services using Auth0 and we are wondering what the best approach is. What we want to give out to our customers is an app_id and an app_secret which they can include in their calls to our APIs in order to get access.

Our current Auth0 solution for this would be:

  1. Create a Non Interactive Client for the customer
  2. Authorize this client access to the APIs needed
  3. Give out the ClientID/ClientSecret as app_id and app_secret to the customer

On requests containing the app_id and app_secret we would then do a Client Credential Grant request to Auth0 to validate the credentials on the server side. We would like to this on the server in order to eliminate the need for our customers to write logic for obtaining access tokens.

The questions we are having are the following:

  • Is it ok to use ClientId/ClientSecret as API keys and give them to customers?
  • Is it ok to do a Client Credential Grant on the server with the app_id/app_secret?
  • Is this the correct way of doing API keys with Auth0, or is there a better way to this?

I’m sorry if this question was already answered somewhere but I wasn’t able to find a satisfying answer so far.

1 Like
2

Is it ok to use ClientId/ClientSecret as api keys and give them to customers?

Yes, client credentials and API keys are very much equivalent. In general, both need to be used only by client applications that are able to securely store them and maintain their confidentiality. Additionally, both put the responsibility of ensuring they don’t leak to whoever they are issued to.

The only real difference is that API keys are validated after being received by the API itself, while client credentials are validated by an independent actor (authorization server) that then issues a temporary assertion that will be included in the request to the API; the assertion (token) can usually be validated by the API without additional requests.

Is it ok to do a Client Credential Grant on the server with the app_id/app_secret?

Yes (with some considerations), you’re mostly just shifting some responsibility from the client application to the server-side. More specifically, the exchange of client credentials for an assertion/token will now be done on the server instead of the client application. However, while reducing the effort required to implement a client application this significantly increases the cost of implementing, maintaining and scaling the server-side.

For example, caching the returned assertion/token in the client application requires some work, but it’s way easier then try to implementing token caching on a server-side component that needs to be aware of multiple client credentials. Also have in mind that there are limits on the frequency of calls to the token endpoint so depending on your volume of calls you may need to implement such caching strategy in order to reuse tokens.

Having said that, you mention that you’re doing this because the client applications are from your customers so the added cost of doing it server-side may not be relevant given it will probably get you either more customers or more satisfied customers. In conclusion, it’s a decision for you to make.

Is this the correct way of doing API keys with Auth0, or is there a better way to this?

Use of client credentials grant is the recommended way to achieve the sort of functionality associated with traditional API keys that are used as the basis to identify that the API call is coming from a registered customer and at the same time to identify the particular customer so that you know to whom address the API usage bill.

1 Like
3

Thanks for your quick and extensive answer! Its good to know that we are on the right track.

Regarding your points on doing all the heavy lifting on the server side.
In the long run we want to provide SDKs for all our apis which take care of maintaining access tokens, so we don’t want to leave it as this.
But as a start we will do it as described then.

4

@jmangelo An Auth0 employee mentions here that you guys are working on “a mechanism to create formal “API Keys” that can be tracked and revoked and which never expire.” Has there been any progress on this? My company is in the same situation as @karsten.klompmaker and are looking for a solution. I don’t particularly like the solution described above as it has some pretty significant trade-offs. Stormpath has this functionality but now that they are being shut down, they are not an option.

1 Like
5

Thanks for your quick and extensive answer! Its good to know that we are on the right track.

Regarding your points on doing all the heavy lifting on the server side.
In the long run we want to provide SDKs for all our apis which take care of maintaining access tokens, so we don’t want to leave it as this.
But as a start we will do it as described then.

6

To be honest, I always assumed the post you probably refer to were about having API Keys as an alternative method of accessing the Management API and not something general for custom API’s.

What are the trade-offs associated with client credentials that you are mostly concerned about?

7

No that’s not what I am after. We are working on an API that will be made publicly available to our customers. That API also needs to be secured. We really don’t want to push the burden of requesting access tokens onto the customer (client credentials grant). Long-running API keys are really the only solution for us. For example, GitHub gives you the ability to generate personal access tokens that do not expire and are also able to be reset and deleted.

3 Likes
8

Here is the link I was referring to. It didn’t get attached to my earlier comment for some reason. https://auth0.com/forum/t/api-key-management-is-this-possible-with-auth0/5820

9

Oops, wrong link :slight_smile: Actually this one: https://auth0.com/forum/t/ungodly-confusing-process-to-create-a-management-token/5120/18

10

I view personal access tokens as a bit different than the client credentials/API keys situation. With these tokens there’s an end-user involved and they want to grant access to their data to a specific application that would be then accessing the API on behalf of the user.

In general API Keys (as client credentials) are employed for service to service scenarios where there’s not a notion of end-users.

Right now, the general API Keys scenario is addressed by client credentials. I’m not saying that we won’t have other possibilities in the future, but that what’s available now.

11

Right. I was addressing the service-to-service scenario. Client credentials does not work well for our application due to the aforementioned reasons. I was hoping there was some progress made on a typical/formal API key implementation.

2 Likes