Best practices for storing and using authentication tokens

The majority of APIs Cronofy provides make use of two different authorization models: “Application level”, and “User level”. Both require you to store and make use of a secret value that you will need to securely store.

Application level auth

Endpoints such as the Availability Query endpoint are acting as your application over several users. These use your client_secret to identify your application, and then resolve which accounts are in scope and authorized to your application.

For these, you need to securely store you client_secret value. Never put this value into a front-end or mobile app, as this will allow attackers to easily grab the value.

User level auth

Cronofy uses OAuth2 as a model for most authorizations. Our authorization flows return Access Tokens and Refresh Tokens to authorize your application to most of our APIs where these perform operations for a specific user.

You must store the account sub, access_token and refresh_token values to identify a user. When you wish to make an API call to Cronofy you can then perform a lookup of the access_token value which will be required to make the API call.

Access tokens are used for the vast majority of interactions. They have an expiry time, helping to limit the impact if one should be leaked. Refresh tokens are used to refresh your access token - getting a new one for a user when their current one is close to expiring.

An access token can be refreshed using the refresh token API. The refreshing of access tokens can be done in one of two ways:

• Proactively, by parsing the expires_in value and enqueuing a job to request a new authorization at that point.
• Reactively, by responding to an unauthorized response by triggering a new authorization request.

You can read more about the various authorization mechanisms Cronofy supports on both the Individual Connect and Enterprise Connect pages.