About
The abstract OAuth 2.0 flow describes the interaction between the four roles.
Type
For each type of grant, you got a flow:
| Type / Flow | Description | Client Type (Public / Private) | Direction Type |
|---|---|---|---|
| authorization_code | Redirection to an authorization server | confidential (private, server) | redirection |
| password_credentials | Password Credential of the user via a login form | confidential (private, server) | direct |
| client_credentials | Credential given by the client (app) | confidential (private, server) | direct |
| implicit | Redirection to an authorization server | public client (in browser app without web server) | redirection |
There is also the Device Authorization Grant for apps that don't have access to a web browser. ie used for headless apps, such as CLI tools.
Authorization Code
The Authorization Code grant type is optimized for confidential client (server app).
It's a a redirection-based flow used to obtain both:
- and refresh tokens
Password Credentials
In the Resource Owner Password Credentials / Password Credentials Flow, the owner (user) gives its password credentials to the client (app).
Therefore, the resource owner (user) should have a trust relationship with the client (the app), such as the device operating system or a highly privileged application.
This flow is used generally to migrate existing clients:
- from direct authentication schemes such as HTTP Basic or Digest authentication
- to OAuth by converting the stored credentials to an access token.
Characteristics:
- This grant type is suitable for clients (apps) capable of obtaining the resource owner’s credentials (username and password, typically using an interactive form).
- This is a fallback flow and should be used only when other flows are not viable.
- It's a direct based flow.
Client Credentials
In a Client Credentials flow, the client can request an access token using only its client credentials (or other supported means of authentication) when the client is requesting access to the protected resources under its control, or those of another resource owner that have been previously arranged with the authorization server (the method of which is beyond the scope of this specification).
The client credentials grant type MUST only be used by confidential clients.
Implicit
Implicit for Javascript Browser App (such as React, Vue, …)
Prerequisites
Before initiating the protocol (flow), the client must register with the authorization server
Steps
The authorization request can be made:
Direct
Flow when the client requests authorization from the resource owner directly.
This is mostly the password credentials flow.
Indirect
A indirect flow is preferable and asks authorization to the authorization endpoint (ie authorization server) as an intermediary (between the client and the resource owner).
An indirect flow is a redirection based flow.
List:
| Name | Client Type (App Type) |
|---|---|
| Authorization code flow | confidential, private server |
| implicit | public client (App in the browser such as a React App) |
Redirection-based
A redirection-based flow means that in the flow, the client (app) and/or the authorization server endpoints send feedback and direct the resource owner's user-agent (the end-user browser) to another destination via http redirection
- Client prerequisites: The client must then be capable of:
- receiving incoming requests (via redirection) from the authorization server endpoints.
- Redirection Method: Any other method available via the user-agent than the HTTP 302 status code to accomplish this redirection is allowed and is considered to be an implementation detail.
All Redirection-based flows are indirect.