Access Tokens
Authentication
Access Tokens
The Oauth2 service generates access tokens for authenticated users, applications or companies. The token returned in the Oauth2 response can be used to access protected resources on Turium Enigma services.
The Oauth2 response can, depending on grant type contain these values:
expires_in
string
-
The lifetime in seconds of the access token
scope
string
-
The scope of the access token as granted to the client application
token_type
string
-
The type of token returned. Value will be Bearer
access_token
string
-
Token used to access protected resources of Turium Enigma services.
refresh_token
string
-
Refresh token required to request a new access token for a given user.
geolocation
string
-
The base URL for where the user profile lives.
id_token
string
-
The OIDC Token in the JSON Web Token (JWT) format that describes the user or company
Token Response
Obtaining a token
You can obtain a token for three different types of principals in the Turium Enigma universe.
User
Application
Company
Token Lifetime
An accessToken
has a one hour lifetime.
In order to obtain a token, the client application needs to call the Oauth2 endpoint using various grants depending on the authentication scenarios required.
Refreshing a token
The refresh grant is used to refresh an access_token that has expired. This grant can be used anytime a refresh_token is returned in the response of another grant request. No user interaction is required.
Token Lifetime
A refresh token has a six month lifetime. If the refresh token expires, the client application must reinitiate the authorization process. When a refresh token is used to request a new access token, both a new access token as well as a new refresh token are returned in the response. This token can change even if most of the time, this value is the same. Client applications should treat all returned refresh tokens as new tokens and overwrite the stored tokens with the new token from the response.
It is recommended that the client application use the refresh grant to request a new access token as the initial step of accessing protected resources of Turium Enigma services.
Refreshing the token
To request a new access token using a valid refresh token, use the Oauth2 /token endpoint. Use the application/x-www-form-urlencoded
content type.
Post Body
client_id
string
UUID
Required The client applications client_id supplied by App Management
client_secret
string
UUID
Required The client applications client_secret supplied by App Management
refresh_token
string
-
Required An existing valid refresh token to be used to request a new access token
scope
string
-
Optional The client applications list of scopes
grant_type
string
-
Required The grant type instructs the Oauth2 service how to process the request. For refresh token, the value must be refresh_token
Request
Response
When the token has been refreshed, store the geolocation and the refresh token as they may have changed. On subsequent calls, use the last received geolocation and refresh token.
Revoking a token
All refresh tokens associated to a user for an application can be revoked by calling the endpoint with a DELETE
action. You have to provide the User’s accessToken
in the Authorization Header as Authorization: Bearer <access_token>
.
Request
Response
Managing tokens
Refresh Tokens are strings that allow your application to obtain a fresh accessToken
on behalf of a user to access Turium Enigma APIs. The exact format of the string can change, but may look similar to the following:
or like this:
It is highly recommended that you store Refresh Tokens together with your user’s authorization metadata in your application every time you obtain a new refreshToken
as they might change depending on different scenarios.
FOR APP CENTER AND SUPPLIER PARTNERS supporting all geolocations, storing the authorization metadata, including the geolocation are REQUIRED.
Base URIs
When making API calls, the appropriate base URI should be used. There are three different scenarios:
Obtaining a token for a user.
Refreshing a token.
Calling other APIs.
The base URI for obtaining a token will leverage your application’s geolocation. The base URI for refreshing tokens and all other API calls will leverage the token’s geolocation.
Base URIs for Obtaining a Token
When your application is created, you will be provided with a client ID, secret and geolocation. When obtaining a token, your application should use the base URI for the geolocation in which your application exists.
There are two endpoints for each geolocation - one is the default (used for server-side calls) and the other should be used for client-side calls.
When obtaining the token, the token’s geolocation will be included in the response. The token’s geolocation should be stored along with the token. The Developer’s app will then be able to make subsequent calls using the token and the correct end points based on the token’s GEO location.
Base URIs for All Other Calls
When refreshing a token or when calling any other APIs, the token’s geolocation should be used as the base URI.
Note: Client-side calls should use the www- variant of the base URI.
Example
Consider an example where your application obtains a token and receives the response below:
When your application calls another API, such as the receipts API to post a receipt, the request should be made using the base URI specified in the geolocation value of the response. The geolocation value can be any of the supported base URIs. The application should store the specific geolocation it receives, and use it as the base URI for future API calls when using that token.
ID Token
Authentication service will return an OPENID compatible ID token with every token request. This id_token
is primarily used to describe information about a user or a company. You can obtain the userId from this token.
Verifying an id_token
The Authentication service exposes JWKs that can be used to validate the id_token in the form of a JWT. Validating a JWT is described in detail in RFC 7519 - sec 7.2
Authorization grant
The authorization grant is the regular 3-legged oauth2 grant and is defined in detail in RFC6749 sec-4.1. This grant requires the user to explicitly authenticate themselves and authorise the application initiating the grant.
The users must be able to authenticate themselves via a Turium Enigma username & password. Users will be challenged to login by an Oauth2 HTML page.
Who should use it
3rd party “partner” websites - or -
non-Turium Enigma Applications - & -
Applications that need explicit user authentication & authorization - & -
Applications that can securely store a code, access_token & refresh_token
Grant details
Note that the grant type must be accessed using the
www-
version of the API Gateway in order to avoid certificate issues with some browsers.
GET /oauth2/v0/authorize
client_id
string
UUID
Applications client_id supplied by App Management
redirect_uri
string
-
The redirect URI for your application to continue with the Oauth2 flow
scope
string
-
List of scopes that application is asking for
response_type
string
-
code
state
string
-
With this grant, the user has two authentication options:
Username and password
One-time link using a verified email address
With both options, once the user is successfully authenticated and the user authorizes your application, the user will be redirected to the redirect_URI specified in the initial /authorize call with a temporary token appended.
<redirect_uri>?geolocation=<token_geolocation>&code=<token>
If the user is not successfully authenticated or does not authorize the scopes for your application, an error code and description will be appended to the redirect URI.
Your application must then exchange the temporary token for a long-lived token using the below.
POST /oauth2/v0/token
client_id
string
UUID
Applications client_id supplied by App Management
client_secret
string
UUID
Applications client_secret supplied by App Management
redirect_uri
string
-
The redirect_uri that is registered for the application
code
string
UUID
The authorization code provided by Auth
grant_type
string
-
authorization_code
Password grant
The Password grant can be used when there is a trust relationship between the user and the application. There are two credential types allowed with Password Grant:
“Password”: with this credential type, the application either already has the user’s credentials or can obtain the user’s credentials by directly interacting with the user.
“AuthToken”: This credential type is used for connections.
Post Body
client_id
string
UUID
Applications client_id supplied by App Management
client_secret
string
UUID
Applications client_secret supplied by App Management
grant_type
string
-
Specify which grant type you expect the oauth2 service to process. for password grant, the value is password
username
string
-
specify the username or userId
password
string
-
specify the user’s password
credtype
string
-
The credtype signifies to oauth2 which credential set is being submitted in the request. There are two supported values: authtoken
and password
. For connections from the App Center, use authtoken
. if omitted, oauth2 will assume the type is password
.
Request
Response
example bad login
Client Credentials grant
Use the application/x-www-form-urlencoded
content type.
POST /oauth2/v0/token
Post Body
client_id
string
UUID
Required Applications client_id supplied by App Management
client_secret
string
UUID
Required Applications client_secret supplied by App Management
grant_type
string
-
Required Specify which grant type you expect the oauth2 service to process. For client_credentials grant, the value is client_credentials
Request
Response
One Time Password grant
The One-time Password grant type leverages email, phone (text messaging), instant messaging and similar systems to provide per user access tokens to client applications. This grant type requires the following steps:
The calling application calls the OAuth2 service specifying the otp grant type along with required parameters.
The OAuth2 service generates a one time token which it sends through the messaging mechanism chosen by the application.
The user retrieves the token and presents it to the application. The means of having this presented to the application is the responsibility of the application.
The application presents this one-time token to the OAuth2 service via the token endpoint.
Request a one-time token to be sent to the user
Use the application/x-www-form-urlencoded
content type.
POST /oauth2/v0/otp
Post Body
client_id
string
UUID
Required The client_id as defined in the Turium Enigma application management system.
client_secret
string
UUID
Required The client_secret as set by the client owner in the Turium Enigma application management system.
channel_handle
string
-
Required The location (email address, phone number) where the one time token should be sent. Currently, only email address
is valid.
channel_type
string
-
Required The type of messaging system to use. Currently only email
is valid
name
string
-
Optional The name of the user that appears in the email.
company
string
-
Optional The company or application name that appears in the email.
link
string
-
Optional The callback URL that appears in the email for users to click to complete the auth flow.
The calling application code can also append n-number of unique client defined parameters in the URI for the purpose of connecting the one time token to the application when received by the user. The names of these parameters cannot conflict with the API defined parameters.
The following are reserved words and cannot be used as client application defined parameters:
If the calling application chooses to send custom parameters, all of these exact same parameters must be included in subsequent API calls to acquire the access token. In other words, the URI signature, modulo the one time token parameter itself and token service specific parameters, must match the originating URI signature.
Request
Response
Request an access token
The One Time Password grant requires that all of the parameters, including client application defined parameters to be sent in the request body when requesting an access token. Use the application/x-www-form-urlencoded
content type.
POST oauth2/v0/token
Post Body
client_id
string
UUID
Required The client_id as defined in the Turium Enigma application management system.
client_secret
string
UUID
Required The client_secret as set by the client owner in the Turium Enigma application management system.
channel_handle
string
-
Required The location (email address, phone number) where the one time token should be sent.
channel_type
string
-
Required The type of messaging system to use. Currently only email
is valid
scope
string
-
The scope(s) requested by the client for the token.
grant_type
string
-
Required The grant type being used, specifically for this approach: otp
.
otp
string
-
Required The one-time token provided as a result of the Send a one time token to the user method.
Request
Response
Response Codes
HTTP Status returned by oauth2
200
OK - Successful call, response is in body.
400
Bad Request (error, error_description, code)
401
Unauthorized (error, error_description, code)
403
Forbidden (error, error_description, code)
404
Not Found (error, error_description, code)
500
Server Error, error message is in body.
503
Server Timed Out, error message is in body.
4xx class errors have a JSON response with the following fields
/authorize
If the authorization or authentication are unsuccessful, your application will receive an error code and description at the redirect_uri provided.
In all cases, the friendly error description should be displayed to the user.
/token
5
invalid_grant
Incorrect credentials. Please Retry
10
invalid_grant
Account is disabled. Please contact support
11
invalid_grant
Account is disabled. Please contact support
12
invalid_grant
Logon Denied. Please contact support
13
invalid_grant
Logon Denied. Please contact support
14
invalid_grant
Account Locked. Please contact support
16
invalid_request
user lives elsewhere
19
invalid_grant
Incorrect credentials. Please Retry
20
invalid_grant
Logon Denied. Please contact support (typically due to IP restriction)
51
invalid_request
username was not supplied
52
invalid_request
password was not supplied
53
invalid_client
company is not enabled for this client
54
invalid_scope
requested scope exceeds granted scope
55
invalid_request
we don’t know this email
56
invalid_request
otp
was not supplied
57
invalid_request
channel_type
missing
58
invalid_request
channel_handle
missing
59
access_denied
client disabled
60
invalid_grant
these are not the grants you are looking for
61
invalid_client
client not found
62
invalid_request
client_id
was not supplied
63
invalid_request
client_secret
was not supplied
64
invalid_client
Incorrect credentials. Please Retry
65
invalid_request
grant_type
was not supplied
80
invalid_request
invalid channel type
81
invalid_request
bad channel handle
83
invalid_request
otp not found
84
invalid_request
fact verification failed
85
invalid_request
otp verification failed
100
invalid_request
backend does not know about this username
101
invalid_request
code was not supplied
102
invalid_request
redirect_uri
was not supplied
103
invalid_request
code is bad or expired
104
invalid_grant
redirect_uri
does not match the previous grant
105
invalid_grant
this grant was not issued to you!
106
invalid_request
refresh_token
was not supplied
107
invalid_request
refresh disallowed for app
108
invalid_grant
bad or expired refresh token
109
invalid_request
loginid
was not supplied
115
invalid_request
unauthenticated client will not be issued token!
117
invalid_request
nonce is mandatory for this response_type
118
invalid_request
display is invalid
119
invalid_request
prompt is invalid
119
invalid_request
prompt must be set to consent for offline_access
120
invalid_request
credtype
is invalid
121
invalid_request
login_type
is invalid
122
invalid_request
proxies supplied are invalid
123
invalid_request
principal is disabled
134
invalid_request
Company undergoing scheduled maintenance.
/otp
16
invalid_request
user lives elsewhere
57
invalid_request
channel_type
was not supplied
58
invalid_request
channel_handle
was not supplied
60
invalid_grant
these are not the grants you are looking for
61
invalid_client
client_id
is not known to us
62
invalid_request
client_id
was not supplied
63
invalid_request
client_secret
was not supplied
80
invalid_request
invalid channel type
81
invalid_request
bad channel handle
82
invalid_request
the number of open otp requests has been exceeded
Troubleshooting
In order to assist with troubleshooting, Turium Enigma responds with a unique correlationId in the response header. The key to look for is correlationid
. This unique code can be used during troubleshooting as it identifies the API call in the log files. You should record this information in your own API call logs as well so that you can pass this information on to the Turium Enigma support team.
Example of the correlationid
in the response:
Last updated