Grant types
A grant type indicates the authorization mechanism that the client uses to retrieve the ID token and access token from Verify. You can choose from authorization code, implicit, authorization code and implicit, device flow, resource owner credentials, JWT, Context-based authorization, refresh token, and token exchange.
Characteristics | Authorization code | Implicit | Authorization code and Implicit |
---|---|---|---|
Description |
The authorization endpoint Client authentication is required by using a client ID and secret to retrieve the ID token or
access token from the token endpoint It is the most commonly used flow. |
The authorization endpoint It does not use an authorization code or a token endpoint |
It allows the client front-end and back-end to receive tokens independently of each other. The client obtains an authorization code and tokens from the authorization endpoint
|
Use case |
Use for clients that can securely maintain a client secret such as web applications, and native mobile applications. It is intended to authenticate the user, and the client. |
Use for clients that cannot keep a client secret such as the browser or JavaScript based applications. It is intended to authenticate the user. |
Use for clients that:
|
Response type value |
|
|
|
All tokens are returned from the authorization endpoint. | No | Yes | No |
All tokens are returned from the token endpoint. | Yes | No | No |
Tokens are not revealed to the user agent. | Yes | No | No |
Client application can be authenticated. | Yes | No | Yes |
Generate refresh tokens. | Yes | No | Yes |
Communication in one round trip | No | Yes | No |
Most communication server-to-server | Yes | No | varies |
Login hint (login_hint) | Yes This value could be the user name as a string, for example,
john@ibm.com , or a JSON , for example,
. When using a JSON value, the realm represents the identity
source realm. |
Yes This value could be the user name as a string, for example,
john@ibm.com , or a JSON , for example,
. When using a JSON value, the realm represents the identity
source realm. |
Yes This value could be the user name as a string, for example,
john@ibm.com , or a JSON , for example,
. When using a JSON value, the realm represents the identity
source realm. |
Maximum authentication age (max_age) | This value is the allowable elapsed time in seconds since the last time the user was actively authenticated. This attribute applies to Cloud Directory login sessions only. | This value is the allowable elapsed time in seconds since the last time the user was actively authenticated. This attribute applies to Cloud Directory login sessions only. | This value is the allowable elapsed time in seconds since the last time the user was actively authenticated. This attribute applies to Cloud Directory login sessions only. |
Workflow |
|
|
|
Characteristics | Device Flow | Resource Owner Password Credentials | JWT |
---|---|---|---|
Description | It allows the client to be authorized by using a QR code or a user code that is sent to a URL. | Client and user authentication is required by using a client ID, a client secret, a user name, and a password to retrieve the access token and ID token from the token endpoint /token. The username and password is validated against Cloud Directory. | Defined in RFC7523. Allows a client to present a signed, or encrypted, or a signed and encrypted JWT in exchange for a grant. The JWT is validated by the authorization server and the identity within the JWT is used as the subject of the grant. |
Use case |
Use for clients that:
|
This grant type can be enabled, but use it only if no other flows are available. It can be
used for:
|
There is an established trust relationship between the authorization server (Verify) and an entity, which issues JWTs. The client obtains a JWT from the JWT issuing entity and presents it to the authorization server in exchange for a grant. The JWT issuing entity might have its own requirements, which must be fulfilled before a JWT is issued (such as alternative authentication and authorization checks). |
Response type value | Not applicable | Not applicable | Not applicable |
All tokens are returned from the authorization endpoint. | No | No | No |
All tokens are returned from the token endpoint. | Yes | Yes | Yes |
Tokens are not revealed to the user agent. | Yes | Yes | Yes |
Client application can be authenticated. | Yes | Yes | Yes |
Generate refresh tokens. | Yes | Yes | Yes |
Communication in one round trip | |||
Most communication server-to-server | |||
Login hint (login_hint) | No | No | No |
Maximum authentication age (max_age) | Not applicable | ||
Workflow |
|
|
|
Characteristics | Context-based authorization | Refresh Token | Token Exchange |
---|---|---|---|
Description | An API driven flow where additional authentication and authorization checks are performed. Before a grant is issued to the client, multi-factor authentication might be required. | Client and user authentication is required by using a client ID, a client secret, and a refresh token to retrieve a new set of access token, ID token, and refresh token from the token endpoint /token. The refresh token must belong to the same client ID. Attribute values associated with the token are not refreshed during this flow. | Defined in RFC8693. Allows a client to present a token to be exchanged for another token. |
Use case |
|
Use this grant type to get a fresh set of access token, with renewed token lifetime. This allows the access token lifetime to be kept short but will not require the user to login again to get a new access token. |
|
Response type value | Not applicable | Not applicable | Not applicable |
All tokens are returned from the authorization endpoint. | No | No | No |
All tokens are returned from the token endpoint. | Yes | Yes | Yes |
Tokens are not revealed to the user agent. | Yes | Yes | Yes |
Client application can be authenticated. | Yes | Yes | Yes |
Generate refresh tokens. | Yes | Yes | Yes |
Communication in one round trip | Yes | ||
Most communication server-to-server | Yes | ||
Login hint (login_hint) | No | No | No |
Maximum authentication age (max_age) | Not applicable | No | |
Workflow |
Note:
|
|
|