Expiration DateTime for Machine to Machine Applications (Client Credentials flow)

Product Feedback
, , , , , , , ,
1

Feature: Machine to Machine Application Expiration

Use-case: We build and sell APIs. To grant customers access to our APIs, we create Machine to Machine (M2M) Applications for each customer and provide them with their Client ID and Secret. We have setup a mechanism for creating temporary trial credentials with an expiration date and time, adapted from Managing Trial Periods with Auth0 Actions , where we set an expires_at value in the M2M application metadata and we have an Action for the M2M token request trigger that calls api.access.deny(…) when the current date is after the expires_at value. This all works great.

The problem we are running into is enforcing the expires_at value for access tokens with a token expiration (exp claim) that is after the expires_at value. For example, if we have our Auth0 API setup with an Access Token Expiration set to 24h (default), and then if a customer requests an access token one hour before their expires_at time, they will get an access token (JWT) with the exp claim set to 23h after their expires_at time giving them an extra 23h of trial access to our APIs.

Suggested feature: What would be nice is if there was a way to set the exp claim to min((now() + api.access_token_expiration), expires_at)(pseudo). I.E. If the application expiration date / time is within the access token expiration window, the exp claim should be shortened to the application expiration date / time.

Two ways we think this could be supported by Auth0:

  1. Auth0 could add a new expiration property to M2M applications and update the access token request API (/oauth/token) to correctly set the exp claim and to deny token requests after the expiration date / time.
  2. Auth0 could add support for setting the exp claim for access tokens from Actions. For example, the credentials exchange API object could be be updated with a new function like api.accessToken.setExpiration(date: Date), and then we would setup our Action to call that function when appropriate based on our expires_at application metadata.

Alternatives considered: We have considered adding our expires_at value as a custom claim in the access token JWTs and then updating our APIs to check that custom claim. This should be possible, but since we have many APIs maintained by several different engineering teams written in various programming languages, we expect that the change could be error-prone due to different implementations of the custom claim check and could lead to inconsistency over time as new APIs are developed. It would be preferrable if the standard exp claim could be used for this use-case since validation of the exp claim is a standard part of JWT / OAuth 2.0 libraries so it wouldn’t require any custom validation or code changes in our APIs.

Related Requests: