Skip to content
DevelopmentJavaScript
About
Getting StartedContributing
Usage
AccountsAPI TokensAuthBusinessesBusiness InvitesEventsGraphQLGroupsMailboxesProductsInstancesStagesTemplatesTransitionsTranslationsUsersNetwork Connections
Architecture
AuthenticationSingletonsHTTP RequestsGraphQL
Development
API ClassesConfigurationEventsLoggingModelsUtilities
Documentation
Getting StartedContributingTechnical ComponentsStructureFirst Party ComponentsRecipe - Adding a PageRecipe - Adding Links
Tooling
BuildCoverageDebuggingLintingTesting
GitHub

Authentication

Table of contents
Table of contents

Background

Rationale

Security is of paramount importance. Customers trust XEDI with sensitive business data, and legislation such as the Data Protection Act 2018 obligate XEDI to ensure the maximum possible security of data and best practices for access. For more information on these obligations, read this guide from the Information Commissioners Office.

As part of these obligations, we've not only looked at current best practices, but also industry futures. Many names within the authentication tech-space are moving to using JWT tokens as part of the Open Authentication 2.0 standard. As such we have chosen JWT tokens as our defacto authentication mechanism.

Tokens

When you authenticate with an API Gateway, you will be provisioned two JWT tokens. These are known as short-life tokens and are considered to be more secure than traditional OAuth tokens.

The first token, the Access Token is the token which should be sent in the Authenticate header using the Bearer scheme.

The second, and most important is the Refresh Token. This should be kept safe and only used when prompted. As the name suggests it is used to securely generate new access tokens when your current one expires. To ensure this not subject to "replay attacks", refresh tokens are single use. Once it is used, it is revoked and a new one issued.

For extra security, our tokens are also encrypted. This means that the signature part of the token is encrypted using 4096-bit encryption. The signature hashes the payload and headers of the token, which prevents the token from being manipulated by a third-party.

Token Lifecycle

  • One authenticated successfully, access and refresh tokens will be issued to the user.
  • The user should use the access token in the Authenticate header for every request.
  • When the access token expires, any request it is used with will respond with a 401 Not Authorized error.
    • Within the responses headers will be the WWW-Authenticate header providing detail of the error.
      • If the token is expired, the refresh token should be sent to 1/api/auth/token using the POST verb.
      • If the token is invalid, the refresh token should be sent to 1/api/auth/token using the POST verb.
      • New tokens will be issued to the user if the refresh token is valid.
  • If the refresh token itself is invalid, expired or revoked, the user should re-authenticate.
Edit this page on GitHub
1 contributorSmudge3806
Last edited by Smudge3806 on June 4, 2020