Overview
As part of ongoing improvements, we are updating the way API keys are managed in the system. This change will see the provision of an API key to every user discontinued, with future keys being generated on demand using the new mechanism described below. As part of this change, the way in which the keys are provided to the API as a token header will change to use the Bearer Authentication method.
Who will this affect?
This change will affect all API users as any existing API key in use will be retired based on the timeline specified below, with the expectation for all users to transition to the new keys by that time.
Details
A new mechanism for API keys has been added and alongside it, a new series of endpoints. The current API key mechanism, where all users have an API key created alongside them is obsoleted and will be removed as part of Phase 2.
Ignoring the current mechanism, new users will not have API keys created by default, but instead, will be able to create them on demand up to a maximum of 100 keys per user per customer. The new API keys will also come with a label field (to provide some description), an enabled flag (if false the API key will not be valid for usage), and an optional expireAt datetime (if an API key is expired it cannot be edited nor used to authenticate, it can only be deleted).
An API key value (or token) will never be shown after the creation of the API key, so if an issued API is lost or forgotten then the user will need to generate a new one. The database only contains a one way hashed version of the key, just like for passwords, so it is not possible for anyone to impersonate the user using the key even if they have direct access to database.
The new endpoints are as follows:
GET api/api-key/{id} - Allows the caller to get the information of an API key by its ID
GET api/api-key - Allows the caller to list API keys by user and customer. Optionally it accepts a filter for the "label" field
PUT api/api-key/{id} - Allows the caller to edit an API key to change the label, enabled flag and expiration
POST api/api-key - Allows the caller to create an API key, this is the only endpoint that will return the actual value of an API key
DELETE api/api-key/{id} - Allows the caller to delete an API key
Important: The way you pass the API key is changing!
The new API keys will need to be passed according to the OAuth 2.0 Bearer token format (RFC 6750). That is a request header named "Authorization" will need to be included, which would look like this:
Authorization: Bearer APIKEYVALUEHERE
This change means that the API keys provided by the old and new mechanisms are not interchangeable and old keys will not be accepted via the Authorization header and new keys will need to be generated.
FAQ
Will API keys work across Alloy regions/environments?
No, each key is specific to a user and customer project. Customers with Live and Staging environments should consider these separately as there is no link between projects across environments.
Is there a default expiration date for each API key?
No, by default each API key will have no expiration date set and it will be the responsibility of the user to set this on creation or edit.
Will I be able to retrieve my API key at a later date following creation?
In line with best practice, the API key will only be given in the response model on creation. It will then be the creator's responsibility to safely store this key for later use. Only the associated data for the API keys (such as the label, enabled flag and expiration date) will be provided in the GET, PUT and DELETE responses.
Will I need an API key to generate an API key?
Once you've authenticated using your login credentials via the session endpoint and created a customer session, you'll be able to use the customer session token to generate and manage keys using the endpoints described above. So no, you won't be stuck in a infinite loop trying to get an API key 😜.
Expected Release Date
13th January 2022
Phase 2: Retirement of Existing Token Method
26th January 2023