Fetching and using Access Tokens

Introduction

Access tokens are short lived JWT tokens that can identify either a user or an application. For an introduction to the JWT standard, see https://jwt.io/introduction.

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.

Fetch access tokens

There are two ways to authenticate to retrieve an access token, either as a user or as an application.

Fetch access-token as logged in user

As a logged in user, using ID-token

POST https://access-token.stage.imid.infomaker.io/v1/token

Choose ONE of the available ways to include the ID-token in the request.

Query Parameters

Headers

{ 
  "access_token" : "eyJhbGciOiJIUzI1NiIsInR…", 
  "token_type": "Bearer", 
  "expires_in": 600 
}

Fetch a scoped access-token as logged in user

As a logged in user, using ID-token

POST https://access-token.stage.imid.infomaker.io/v1/token

Choose ONE of the available ways to include the ID-token in the request.

Query Parameters

Headers

Request Body

{ 
  "access_token" : "eyJhbGciOiJIUzI1NiIsInR…", 
  "token_type": "Bearer", 
  "expires_in": 600 
}

See below for an example on how to use scopes.

Fetch access-token as application (using client credentials)

If you haven't yet created an application in Naviga ID, se the Managing Applications page and follow the instructions there.

As an application, using client credentials

POST https://access-token.stage.imid.infomaker.io/v1/token

Both JSON and form data are supported payload formats.

Request Body

{
  "access_token" : "eyJhbGciOiJIUzI1NiIsInR…", 
  "token_type": "Bearer",
  "expires_in": 600
}

{
    // Response
}

{
    // Response
}

{
    // Response
}

{
    // Response
}

Fetching access-tokens as application configured using scopes

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

Fetching access-token as application configured using groups

CURL example. Start by storing client_id and client_secret in environment variable CLIENT_ID and CLIENT_SECRET respectively.

curl --data "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET" https://access-token.stage.imid.infomaker.io/v1/token

CURL example that stores token in environment variable NAVIGA_ACCESS_TOKEN.

export NAVIGA_ACCESS_TOKEN=$(curl --silent --data "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET" https://access-token.stage.imid.infomaker.io/v1/token | jq -r '.access_token')

Filtering access token permissions using scopes

permission-filter-include-org

Includes all requested permissions in the org array. Only one instance of the scope should exist.

permission-filter-include-unit:{unitName}

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

Examples

## Original permissions
```
{
    permissions: {
        org: [
            perm-1
            perm-2
        ],
        units: {
            barometern: [
                perm-3
            ],
            smp: [
                perm-4
            ]
        }
    }
}
```
## permission-filter-include-org permission-filter-include-unit:smp
```
{
    permissions: {
        org: [
            perm-1
            perm-2
        ],
        units: {
            smp: [
                perm-4
            ]
        }
    }
}
```
## permission-filter-include-org
```
{
    permissions: {
        org: [
            perm-1
            perm-2
        ],
        units: {}
    }
}
```
## permission-filter-include-unit:smp
```
{
    permissions: {
        org: [],
        units: {
            smp: [
                perm-4
            ]
        }
    }
}
```

Authenticate using an Access Token

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.

Authorization : "Bearer $NAVIGA_ACCESS_TOKEN"

CURL example. Environment variable NAVIGA_ACCESS_TOKEN and NAVIGA_ORG needs to be set.

curl -H "Authorization: Bearer $NAVIGA_ACCESS_TOKEN" https://demo.stage.imid.infomaker.io/v1/org/$NAVIGA_ORG/test