OpenID Connect grant flows
These pages describe supported OpenID Connect (OIDC) flows and how to implement them.
Decide which flow is best based on the relying party (RP):
| RP | Grant | Description |
|---|---|---|
The RP is a web application running on a server. |
The OpenID provider (OP) uses the user-agent to transport the authorization code the RP exchanges for tokens. Use the same grant with Proof Key for Code Exchange (PKCE) when possible. |
|
The RP is a native application or a single-page application (SPA); for example, a desktop or mobile application, or a JavaScript application. |
The RP cannot communicate securely with the OP, so the authorization code can be intercepted by malicious users. The PKCE standard mitigates against interception attacks. |
|
The RP knows the end user’s identifier and gains consent through a separate authentication device, such as a mobile phone with an authenticator application. |
The RP does not interact directly with the end user; instead it initiates a backchannel request to the end user’s authentication device to gather consent for the operation. For example, a smart speaker gets consent from its registered end user after receiving a voice request to transfer money to a third party. |
|
The RP is an SPA. |
The OpenID provider (OP) uses the user-agent to transport tokens, exposing them to the end user and other parties. When possible, use the authorization code grant with PKCE instead. |
|
The RP gets an ID token immediately and later gets an access token. |
The OpenID provider (OP) uses the user-agent to transport the authorization code and initial tokens. Use PKCE with this flow when possible. |