Search code examples
securityoauth-2.0access-tokenauth0

When to request new access_token for non interactive clients in oauth2 flow?

I have questions related to non interactive clients like backend apps based on oauth2 flow.

https://auth0.com/docs/api-auth/grant/client-credentials

In accordance with oauth2 for non interactive clients, flow is :

  • The application authenticates with Auth0 using its Client Id and Client Secret.
  • Auth0 validates this information and returns an access_token.
  • The application can use the access_token to call the API on behalf of itself.

Base on this, my questions are :

  • Backend applications should store the access_token locally or request a new access_token for the same client each time the client uses the application?
  • If access_token is stored locally what happend with expiration time?
  • Access_token for non interactive clients should have the same expiration time compared with access_token for interactive users (login web) ?
Solution

  • Backend applications should store the access_token locally or request a new access_token for the same client each time the client uses the application?

    For client credentials grant flow, the decision whether to renew frequently, or "cache" a returned JWT Access token will depend upon your requirements - if scopes for example change frequently, it may make sense to fetch a new access token frequently to ensure those changes are reflected. Speaking from personal experience, this generally isn't the case, so caching the token for the duration of its expiration makes sense, and saves an extra call to Auth0 to fetch a new token with each request.

    If access_token is stored locally what happened with expiration time?

    You can choose to check the expiration before making a request each time, and fetch a new access token if expiration has elapsed, or else just attempt to use the access token without checking, and then try renewing only when you receive a failure when using the existing token.

    Access_token for non interactive clients should have the same expiration time compared with access_token for interactive users (login web) ?

    Similar question to the first one. Since using Client Credentials grant flow usually indicates confidential / trusted client (you are storing a client secret) - and frequently for machine to machine scenarios - it may make sense to use a greater expiration time. However, as already mentioned, if scopes may change etc, then a short expiration would result in configuration changes (scopes) being picked up faster.