Personal Access Tokens or API Keys

Feedback
1

Feature: Personal Access Tokens or API Keys

Description: Often, one wants to grant users access to the API without requiring a typical log in flow. This is either because users want to grant trusted third parties or themselves access in a programmatic setting where a typical login flow would not make sense.

For example, GitHub generates personal access tokens which can be used to access the API, and can be revoked.

Use-case: This is a use case useful for not pushing the burden of logging in to a developer application. For example, in a CLI or a python library, it would be very cumbersome to implement a authentication flow with social, that requires popping up a browser and capturing the access token.

Instead, users could generate a Personal Access Token in order to make API calls programmatically. This is different from M2M use cases, because we want API calls to be restricted the user specific information.

Currently, there is no support for this, which would require use to either implement a cumbersome login in process for programmatic users, implement API keys on our own, or extend the expiration of access tokens to a very large number which is less safe.

2

Hey there!

Thanks for creating this feedback card! Let’s see who else will vote for that!

3

This sound so interesting and usefull !

2 Likes
4

Thanks for adding your +1!

1 Like
5

@konrad.sopala, any update on this feature, if its going to be supported soon. Seems like a basic feature for supporting API based access.

2 Likes
6

It would be great to get this feature !

2 Likes
7

vote for this one too. my use case is that we need to develop a WooCommerce plugin for merchants. So these merchants will set up the appid and secrets in our WooCommerce plugin. so the plugin will communicate to our backend. I was thinking to create one application per merchants, however it seems having limited on the applications we can create. do you have any suggestions?

Thanks,
Dean

2 Likes
8

It would be super great if we can have this feature.

2 Likes
9

Hey everyone, I think this would be a great addition to Auth0, too, and since we don’t know if they will build it…

I’d like to build it myself. :grinning: I think an integration to the Auth0 marketplace or something of that like would be great! If you’re interested, do you mind dropping your email on my landing page? I need to see how many people are interested myself. Thanks!

Landing page: https://www.keysync.io/

1 Like
10

Yes, this feature would be greatly appreciated for the following reasons:

  1. You can connect the traffic of the API key user with his Webapp user. This is relevant if you charge per traffic consumption.

  2. It’s a cleaner system design. Right now, say you only had 2 applications (a Mobile app and a Webapp), and you create M2M applications for all of your thousands of users, the real 2 applications would be burried through the thousands of superflus applications. They are NOT applications, they are just a different way to login into the system.

1 Like
11

I found this official blog article from 2014 that evokes the idea of using JWT as API keys. I think this is a good starting point for a solution, but has the following challenges:

Using access token isn’t a good fit for API keys as access tokens cannot be revoked.

Refresh tokens can be revoked and can have a duration up to 1 year, which is reasonable.

This solution would be satisfying if these two things are possible:

  1. Is it possible validate the reresh tokens the same way you validate access tokens ?

  2. Can you inject the permissions or other data in the refresh token ?

12

I will be very happy to see a feature like this.
Sounds logical that auth0, as an IAM will have an extra feature for personal access tokens, with different time limitation options + revoke option.

It’s in the roadmap?

1 Like
13

+1 to the feature request.

14

This feature would be very appreciated. We have a SAAS API offering that we will be securing with Auth0 and even with an enterprise plan we are limited to 5000 M2M tokens which need to be shared between our internal apps using Auth0 and these external customers accessing our API. An API key would be our preferred solution as it’s easy to manage and does not consume M2M tokens.

15

+1 for this feature request

16

Can this be implemented please. We have a scenario where this will be useful. Otherwise too much information need to be shared with 3rd parties to work around this problem.

17

As this is now one of the highest voted feature requests, what’s the possibility of the Auth0 team acknowledging that this is something the customer base really wants?

3 Likes
18

+1 on this. It seems like an obvious use case that Auth0 would want to support somehow.

1 Like
19

I’ve been following this post for some time now, hoping that this feature request would be implemented. It doesn’t seem to be getting any traction, so I’d like to add my perspective on why this feature is important for my company:

Importance:

  1. Direct Association with Users/Organizations: In our platform, we use Auth0 for authentication but utilize another system for fine-grained access (FGA) controls. This means we do not utilize scopes in our JWTs nor do we use roles/permissions that are typical in Auth0. Therefore, it is crucial that the API keys are directly tied to either users or organizations, reflecting the actual entities that require access to our resources.

  2. Avoiding Client Credentials Flow: Using the client_credentials flow is not suitable for us, as the sub claim would not match a user or an organization, but rather a machine that has no access to any resources in our system. This disconnect poses significant challenges in integrating with our existing access control mechanisms.

Benefits:

  1. Ease of Use: Users can generate an API key through the Auth0 dashboard or an API endpoint, reducing the complexity of integrating with our API.
  2. Security: API keys would be securely managed within Auth0, leveraging existing security measures and infrastructure.
  3. Flexibility: API keys tied to user accounts would allow for more granular access control and easier tracking of API usage by individual users or organizations.
  4. Compatibility: This feature would complement existing OAuth-based authentication, providing a more versatile solution for different use cases.

This feature would address a significant gap in Auth0’s capabilities and align with the needs of many modern SaaS applications that require programmatic access tied to user or organizational accounts.

Thanks for reading and hope this gets the focus it needs to move forward!

5 Likes
20

Big +1 here, this is very similar to our use case as well.

2 Likes