---
sidebar_position: 9
sidebar_label: Validating access tokens
---

# Authentication with custom APIs

Future Ordering can be extended in many different ways. Some of these approaches mean that Future Ordering would make a call to a custom API or a custom frontend plugin calls your API on behalf of the current user. This article describes how to handle authentication in such cases

:::note
This article does not include approaches to validate other types of calls from Future Ordering, e.g. webhook calls which are validated using HMAC keys. 
:::

## Authentication via signed token

Each [JWT token](https://jwt.io/introduction) (pronounced "jot") contains the user identity and authorization information. These are then cryptographically signed, and the signature is included in the JWT token itself, to guarantee that the token is created by Future Ordering.

Future Ordering follows the [Open ID Connect](https://www.microsoft.com/en-us/security/business/security-101/what-is-openid-connect-oidc) (OIDC) and [OAuth 2.0](https://www.microsoft.com/en-us/security/business/security-101/what-is-oauth) standards. These standards ensure discovery of public keys and process for validating tokens is easy.

Validation of signing keys will require configuration of a trusted issuer. The trusted issuer will be different depending on which environment your application is running in. Most likely, the issuer is:

* mytenantid.login-test.futureordering.com - in the test environment
* mytenantid.login.futureordering.com - in the production environment

It is highly recommended to use an existing library for validating tokens. A list of some libraries that can be used can be found on [jwt.io/libraries](https://jwt.io/libraries). Refer to the documentation of the specific library selected for more details on JWT tokens, security considerations and how to validate the token.

The library used for validating the token will validate the signature, expiration and other security related parts of the token.

The token will contain the user's UserId in the "sub" claim. If there is no "sub" claim, the token is for a client not for a user. 

## Authorization

If granular authorization (more detailed than "has permission to get an access token") is desired, the token can contain additional information about specific user access rights. When using granular authorization the token validation should include validating the "Audience" (refer to documentation on OAuth 2.0 and OIDC for more details on audience) of the token. 

The audience name is created in collaboration with Future Ordering, as part of a request to set up a custom API resource with specific user permissions. To support more granular custom authorization and custom Audiences, please contact [support@futureordering.com](mailto:support@futureordering.com) and provide the list of custom user access rights you want to be able to validate.