Access token exhaustion

[josh-monreal]

Hi, I am working on a .NET REST API project which can be accessed via the client credentials flow. Every time a client application invokes our API, it has to request for an access token first. 

My concern with this is that if there are thousands of API requests there will be thousands of access tokens as well. What is the best practice for this? Should the client application store an access token in a cache and only request for a new one once it has expired? Or is there a more practical solution?

[#2]

Hi, if you consider the client credentials flow, then I assume that your client application is a machine without user interaction, is that correct?

In this case I would use the access token as long as it is valid and then renew it. Your access token should have a lifetime that is sent to the client when it is issued. Something like this as stated here.

Alternatively, the client can renew the access token if it was rejected by the server with the appropriate response code.

{
  "access_token":"eyJz93a...k4laUWw",
  "token_type":"Bearer",
  "expirese":86400
}

As a general rule, you should avoid issuing unnecessary access tokens with long lifetimes or even without lifetime, which have no further use. The more access tokens there are, the higher the probability that an attacker can compromise a valid access token.

The same also applies to the lifetime: the longer the lifetime, the longer an attacker has to obtain it.

You need to find a balance between lifetime, number of access tokens, and requests for a new access token.

[#3]

@neptr 

Hi, if you consider the client credentials flow, then I assume that your client application is a machine without user interaction, is that correct? - That is correct. It is a server-to-server communication.

In this case I would use the access token as long as it is valid and then renew it. Your access token should have a lifetime that is sent to the client when it is issued. - What would be the responsibility then of the client application to ensure that it uses the token until it expires? I am asking this because sessions in API calls are short. Let's say a client application invokes an API. It gets an access token, invokes the API, and gets a successful response. If it needs to access the same API it will have to get a new access token which is not a good idea since its first access token is not yet expired. 

Basically, the point of my question is this: If I am the developer of the client application, what is the best practice in ensuring that it uses an access token until it expires and only request a new one once that happens? I am asking this because currently, client applications invoking our APIs are requesting for an access token every time they make an HTTP request. So if they access our API for, say, 1,000 times today, that means they requested 1,000 access tokens from the identity server. 

For me, this is not a good practice, and as you have said, it increases the security risk. 

[#4 · Accepted solution]

@josh-monreal 

Basically, the point of my question is this: If I am the developer of the client application, what is the best practice in ensuring that it uses an access token until it expires and only request a new one once that happens? - Josef Ottosson describes a good starting point for that in this article.

If the client application was an ASP.NET application, then I would build a service through which all requests are made to the api. This service would hold the access token across all requests. Before each request, this service would check if the access token is still valid.

The service could check the validity of the access token based on the liftetime and the time when this token was received. If the token expired, the service would request a new access token and hold it again.

Holding the access token across multiple requests can be achieved by adding the service as services.AddSingleton<ICompanyRestService, CompanyRestService>(); Even better would be to add a separate service TokenStoreService or something like that, which is then used by the CompanyRestService.

It would also be possible to make requests to the api until it eventually returns 401 or so and then update the token and repeat the request.

This should be a good starting point

[#5]

@neptr 

Thank you! I will check that out.