Token Claims
Transact access and refresh tokens use the JSON Web Token (JWT) industry standard. Unlike typical opaque API keys, JWTs contain encoded information (claims) that can be easily decoded and read.
Your application could read these claims to disambiguate access tokens for different users, provide different behaviour for different user types, or provide useful diagnostics in case of error.
JWT structure
JWTs consist of three parts separated by dots (.) - the header, payload, and signature.
The header and signature are used to verify that the token has not been tampered with, while the payload is a
Base64Url encoded JSON document containing the token's claims.
For more information on JWTs, see RFC 7519.
Transact private claims
The payload of a Transact access token contains the following private claims:
| Claim | Description |
|---|---|
client_id | The Client ID of the authorised Client (Application) |
scope | Scopes authorised for this token, space-delimited. |
resource_owner_name | The Resource Owner's name. |
resource_owner_role | The Resource Owner's role. |
resource_owner_id | The Resource Owner's Transact number. |
authorizing_id | The authorising super user's Transact number. |
refresh_token_id | Opaque internal ID for the refresh token. |
The jti, iss, aud, iat, and exp registered claims are also included. For information on these claims,
see RFC 7519.
Token structure changes
The structure of new access tokens follows the same breaking change assurances as the rest of the API. Claims may be:
- added at any time without notice
- altered or removed after a communicated deprecation period.
Note that adding a new possible value to an existing claim is not considered a breaking change.