Access Token Issuance

Supported scenarios for access token issuance

The most appropriate mechanism for issuing access tokens will depend on your application architecture.

The most commonly used mechanisms are outlined below:

Issuance mechanism	Application server required?	User creation method	Issued token validity	Scope of issued token
Auth Link	✔️	Implicitly by Auth Link	1 hour. Can be refreshed if offline access is granted.	read:accounts and download:documents.
Application issued JWT (SSO)	✔️	Implicitly by application server	Specified by application in JWT exp and nbf values.	Specified by application in JWT custom scope value.
Public master token via addUserAndAccessToken	✖️	Explicitly by application client	Per tenant setting within Ideavate.	Must be delegation of scope attached to master token.
Private master token via addUserAndAccessToken or addAccessToken	✔️	Explicitly by application server	Per tenant setting within Ideavate.	Must be delegation of scope attached to master token.

Application issued JWT

This may also be referred to as Single Sign On or SSO.

Typical use cases:

• An application which uses it's own or a third party identity service

With this mechanism your application issues a verifiable JWT token that Ideavate trusts. The subject (sub field) is used to identify the user and at the point of a new subject being first presented, the Ideavate platform will automatically create a user entity for you.

The following tenant settings need to be set in the Ideavate platform:

• Allowed algorithm(s)

• Allowed issuer and audience of the token

• Maximum allowed scope

• Public key or shared secret

If you are issuing tokens from multiple places then multiple profiles of the above settings can be configured.

Public master token

Typical use cases:

• SPA (Single Page Application) web application using Ideavate for identity

• Native mobile application using Ideavate for identity

A public (i.e. can be distributed in an application) global token is used to provision each user using the addUserAndAccessToken() GraphQL mutation.

Private master token

Typical use cases:

• SSR (Server Side Rendered) web application using Ideavate for identity

In this scenario the application server can use a single master token which is capable of accessing all of the application to either:

• access all application users directly using the master token. e.g. query { getUser(id: "specific.user.id") { ... } }

• or, use the master token to create a user scoped access token to be used. e.g. mutation { addAccessToken(user: "specific.user.id") { ... } }

---