Create User-Scoped API Keys for CLI Applications

[samuelmanzer]

I am building an application that interfaces with many standard CI/CD SaaS offerings (Travis, Jenkins, etc.). Users interact with it as follows:

1. During a CI build, a script sends a POST to one of my API endpoints, telling it to run some tests
2. My API returns a URL that the script polls to receive the results of the test, once it is completed.
3. If the test fails, the parent CI build fails.

The API access in steps (1) and (2) need to be protected by authentication. Ideally, users would store a long-lived API key as a secure environment variable in their CI system, and access this environment variable in their script before calling our API during the CI build. We would then send this key to Auth0, get a token back, and send the token back to the end user. They would then use this token for all subsequent API calls during that session.

This seems like it is almost like the Client Credentials Grant, but that method does not seem intended to have 100,000 different client credentials (one per user of my Saas). Please advise if
my perception here is correct.

Is there any way to generate multiple user-scoped API keys, the way that github allows?
I saw this thread from 7 months ago on this topic, has anything improved since then?

Generate API keys for users to authenticate with?

The thread you mentioned was more about dealing with one of the most common scenarios for which API keys are used, the one where your API is pretty much sold as a service. In particular, the API is a generic one and has pretty much no notion of individual end-users, that is, you would provide the API keys to an organization/individual that is your customer and you would not really care if they shared it or not because the API itself does not work against individual end-user data and the key is p…

TL;DR two questions:

1. Should I use client credentials grant for this, and generate one client credential per user of my application (potentially thousands)?
2. If not, is there another way to do this?

[jmangelo]

You mention the notion of end-user which in general conflicts with the notion of client credentials as this is a grant where there’s no end-user involved. As you mentioned you seem to be looking for personal access tokens like GitHub provides and client credentials is not an equivalent for that.

I’m also afraid that nothing has significantly in this area changed since I wrote the reply you linked and at this time the possibility I mentioned in that post is still unavailable. With all this in mind my take on your closing questions would be that client credentials is likely not suitable for what you describe and there’s not yet any built-in functionality in the Auth0 service that directly maps to the notion of personal access tokens.

[samuelmanzer]

Understood, thank you for clarifying.

I note that you said:

there’s not yet any built-in functionality in the Auth0 service that directly maps to the notion of personal access tokens.

Would it be a bad idea to hack this a bit and use a long-expiration-time JWT as a “personal access token” that can be stored as an env variable in travis/jenkins so that those systems can access my API in an automated fashion? The only downside I am aware of is that JWTs access tokens are usually considered irrevocable and thus get issued with short expiration times, but I can probably set up a revocation process/blacklist in-house.