Fetching and using Access Tokens
Last updated
Was this helpful?
Last updated
Was this helpful?
Access tokens are short lived JWT tokens that can identify either a user or an application. For an introduction to the JWT standard, see .
Because the tokens are short lived and since they can not be refreshed on their own, the verification of them are simpler than compared to ID-tokens. This means that they can be validated without the need for an IMSG reverse proxy.
This document describes how to fetch and use Naviga ID access tokens.
There are two ways to authenticate to retrieve an access token, either as a user or as an application.
POST
https://access-token.stage.imid.infomaker.io/v1/token
Choose ONE of the available ways to include the ID-token in the request.
imid_token
string
Value should be the ID token
Cookie
string
ID-token set as dev-imidToken
cookie. In client web applications, this is done by setting credentials: 'include'
Authorization
string
Bearer ${ID token}
Groups are only included in the access token if they have a "group to role"-mapping setup in Naviga ID Login.
POST
https://access-token.stage.imid.infomaker.io/v1/token
Choose ONE of the available ways to include the ID-token in the request.
imid_token
string
Value should be the ID token
Cookie
string
ID-token set as dev-imidToken
cookie. In client web applications, this is done by setting credentials: 'include'
Authorization
string
Bearer ${ID token}
scope*
string
Used to define requested scopes. Separate multiple scopes with spaces (" ")
grant_type*
string
Must be set to urn:ietf:params:oauth:grant-type:token-exchange
if scope is supplied
Groups are only included in the access token if they have a "group to role"-mapping setup in Naviga ID Login.
POST
https://access-token.stage.imid.infomaker.io/v1/token
Both JSON and form data are supported payload formats.
client_secret*
string
client_id*
string
grant_type*
string
should be client_credentials
scope
string
Used to define requested scopes. Separate multiple scopes with spaces (" ")
To use scopes, the application must have been configured with allowedScopes when created (and not using groups). If that is not the case, you can either modify the application by removing the groups and add allowedScopes, or simply create a new application.
When fetching a token, in the scope
field, specify the scopes that you wish to include in the token. If you specify more inclusive scopes than what is definied in the allowedScopes for your application, the req will fail. If you specify invalid scopes, such as with unit, service, role or pemission that does not exists in Naviga ID, the req will fail.
All scopes have the following format
["permission"|"role"]:[unitName|"*"]:[serviceName]:[entityName]
Below is a list of examples of scopes
permission:gl-news:opencontent:view
If allowed, the token will get the opencontent:view
permission only in the gl-news unit
permission:*:opencontent:view
If allowed, the token will get the opencontent:view
permission in all units in the org
role:gl-news:opencontent:readOnly
If allowed, the token will get all permissions in the opencontet:readOnly
role only in the gl-news unit.
role:*:opencontent:readOnly
If allowed, the token will get all permissions in the opencontet:readOnly
role in all units in the org
Note that group-based applications are our legacy way of configuring authorization. It is still supported, by we highly recommend to transition to scope-based applications.
CURL example. Start by storing client_id
and client_secret
in environment variable CLIENT_ID
and CLIENT_SECRET
respectively.
CURL example that stores token in environment variable NAVIGA_ACCESS_TOKEN
.
Includes all requested permissions in the org array. Only one instance of the scope should exist.
Includes all requested permissions in the specified unit array. Multiple instances of the scope can exist as long as the unit name is unique.
Error if unitName does not exist or if sub does not have access to that unit
Only send Access Tokens over HTTPS
Simply include the Access Token in the Authorization header whenever you perform a request to a Naviga ID enabled service API, such as CCA and OC.
CURL example. Environment variable NAVIGA_ACCESS_TOKEN
and NAVIGA_ORG
needs to be set.
See for an example on how to use scopes.
If you haven't yet created an application in Naviga ID, se the page and follow the instructions there.