Access Token Issuance
Supported scenarios for access token issuance
Last updated
Supported scenarios for access token issuance
Last updated
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 |
|---|---|---|---|---|
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.
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.
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") { ... } }
✔️
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.