Secure API key mechanism for identification

Question

In my web application, when the user logs in, a pair of JWT(JSON web tokens),access token and refresh token is sent with some fixed time validity. Using access token client is authenticated and using refresh token, a new access token is generated which works fine. I am not storing tokens in the database.

Now, I want to provide an API package to the client where clients can use our APIs with their developer account.

I researched on the web and found out that API keys and secrets serve the purpose of authorization, not authentication.

I don't have any functions in the API for which client needs user consent. They are simple REST API calls which any user with a developer account can call. Therefore I don't need authorization but I need to authenticate the developer who is calling the API as there is a limit on how many calls a developer can make.

1. How can we generate some API key to uniquely identify the developer?

2. Can it be jwt access token without expiry?

3. Can anyone explain what should be the standard mechanism for this scenario?

   I don't want the developer to call login API to get the access token every time.

Answer 1

Most importantly: you can't use a JWT as an API token. There is a very important property that API tokens need that JWTs don't (and can't) have: revokability.

This is important for you. You mentioned that you will use the tokens to track usage and limit the number of calls the user can make. If a user has their API token stolen then the attacker can use up their quota. The simplest way for a user to fix such a situation is to regenerate the token and store it more securely. Unfortunately if it is a JWT then there is no way to revoke it. They could generate a new one, but the old one will still work.

Therefore, for an API token you will have to keep track of it in a database to make sure it hasn't expired. This is less convenient than a JWT, which doesn't need to be tracked in a database. However, it's a requirement in your case. Still, if you're also keeping track of a quota (which presumably also needs a couple database requests), adding a database requirement shouldn't be that big of a deal anyway. So we can answer your questions and add some more details:

1. Just generate a long random string made from a CSRNG. 64 alphanumeric characters would be fine (and probably overkill). Associate it with their user record and call it a day.
2. No, you cannot use a JWT at all because it cannot be revoked, which is a problem if it is stolen.
3. I'm not sure if there is a "standard", but what I have outlined above will work fine.

Answer 2

1. How can we generate some API key to uniquely identify the developer?

Include a custom claim in the JWT to identify the developer.

{
 "accountType" : "developer",
 "iat" : 1422779638
}

2. Can it be jwt access token without expiry?

If you are providing sensitive information through the endpoint, a token without expiry is not a good practice. If it s for a dev environment, you can have long living keys.

3. Can anyone explain what should be the standard mechanism for this scenario?

Easiest way this can be handled is as mentioned in the answer to first question. Ideally if the access each user need to have on the API endpoint is different both from operation and data access perspective, strong authorization need to be in place rather than blanket all developer/all user authorization.