Diagrams And Movies Of All The OAuth 2.0 Flows

1. Authorization Code Flow

This is the flow defined in RFC 6749, 4.1. Authorization Code Grant. A client application (a) makes an authorization request to an authorization endpoint, (b) receives a short-lived authorization code, (c) makes a token request to a token endpoint with the authorization code, and (d) gets an access token.

1.1. Request To Authorization Endpoint

GET {Authorization Endpoint}
?response_type=code // - Required
&client_id={Client ID} // - Required
&redirect_uri={Redirect URI} // - Conditionally required
&scope={Scopes} // - Optional
&state={Arbitrary String} // - Recommended
&code_challenge={Challenge} // - Optional
&code_challenge_method={Method} // - Optional
HTTP/1.1
HOST: {Authorization Server}

1.2. Response From Authorization Endpoint

HTTP/1.1 302 Found
Location: {Redirect URI}
?code={Authorization Code} // - Always included
&state={Arbitrary String} // - Included if the authorization
// request included 'state'.

1.3. Request To Token Endpoint

POST {Token Endpoint} HTTP/1.1
Host: {Authorization Server}
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code // - Required
&code={Authorization Code} // - Required
&redirect_uri={Redirect URI} // - Required if the authorization
// request included 'redirect_uri'.
&code_verifier={Verifier} // - Required if the authorization
// request included
// 'code_challenge'.

1.4. Response From Token Endpoint

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "{Access Token}", // - Always included
"token_type": "{Token Type}", // - Always included
"expires_in": {Lifetime In Seconds}, // - Optional
"refresh_token": "{Refresh Token}", // - Optional
"scope": "{Scopes}" // - Mandatory if the granted
// scopes differ from the
// requested ones.
}

2. Implicit Flow

This is the flow defined in RFC 6749, 4.2. Implicit Grant. A client application (a) makes an authorization request to an authorization endpoint and (b) gets an access token directly from the authorization endpoint.

2.1. Request To Authorization Endpoint

GET {Authorization Endpoint}
?response_type=token // - Required
&client_id={Client ID} // - Required
&redirect_uri={Redirect URI} // - Conditionally required
&scope={Scopes} // - Optional
&state={Arbitrary String} // - Recommended
HTTP/1.1
HOST: {Authorization Server}

2.2. Response From Authorization Endpoint

HTTP/1.1 302 Found
Location: {Redirect URI}
#access_token={Access Token} // - Always included
&token_type={Token Type} // - Always included
&expires_in={Lifetime In Seconds} // - Optional
&state={Arbitrary String} // - Included if the request
// included 'state'.
&scope={Scopes} // - Mandatory if the granted
// scopes differ from the
// requested ones.

3. Resource Owner Password Credentials Flow

This is the flow defined in RFC 6749, 4.3. Resource Owner Password Credentials Grant. A client application (a) makes a token request to a token endpoint and (b) gets an access token. In this flow, a client application accepts a user's ID and password although the primary purpose of OAuth 2.0 is to give limited permissions to a client application WITHOUT revealing the user's credentials to the client application.

3.1. Request To Token Endpoint

POST {Token Endpoint} HTTP/1.1
Host: {Authorization Server}
Content-Type: application/x-www-form-urlecoded
grant_type=password // - Required
&username={User ID} // - Required
&password={Password} // - Required
&scope={Scopes} // - Optional

3.2. Response From Token Endpoint

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "{Access Token}", // - Always included
"token_type": "{Token Type}", // - Always included
"expires_in": {Lifetime In Seconds}, // - Optional
"refresh_token": "{Refresh Token}", // - Optional
"scope": "{Scopes}" // - Mandatory if the granted
// scopes differ from the
// requested ones.
}

4. Client Credentials Flow

This is the flow defined in RFC 6749, 4.4. Client Credentials Grant. A client application (a) makes a token request to a token endpoint and (b) gets an access token. In this flow, user authentication is not performed and client application authentication only is performed.

4.1. Request To Token Endpoint

POST {Token Endpoint} HTTP/1.1
Host: {Authorization Server}
Authorization: Basic {Client Credentials}
Content-Type: application/x-www-form-urlecoded
grant_type=client_credentials // - Required
&scope={Scopes} // - Optional

4.2. Response From Token Endpoint

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "{Access Token}", // - Always included
"token_type": "{Token Type}", // - Always included
"expires_in": {Lifetime In Seconds}, // - Optional
"scope": "{Scopes}" // - Mandatory if the granted
// scopes differ from the
// requested ones.
}

5. Refresh Token Flow

This is the flow defined in RFC 6749, 6. Refreshing an Access Token. A client application (a) presents a refresh token to a token endpoint and (b) gets a new access token.

5.1. Request To Token Endpoint

POST {Token Endpoint} HTTP/1.1
Host: {Authorization Server}
Content-Type: application/x-www-form-urlecoded
grant_type=refresh_token // - Required
&refresh_token={Refresh Token} // - Required
&scope={Scopes} // - Optional

5.2. Response From Token Endpoint

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "{Access Token}", // - Always included
"token_type": "{Token Type}", // - Always included
"expires_in": {Lifetime In Seconds}, // - Optional
"refresh_token": "{Refresh Token}", // - Optional
"scope": "{Scopes}" // - Mandatory if the granted
// scopes differ from the
// original ones.
}

Appendix

Semi-hosted service pattern” is a new architecture of OAuth 2.0 and OpenID Connect implementation. In the pattern, a frontend server (an authorization server and an OpenID provider) utilizes a backend service which provides APIs to help the frontend server implement OAuth 2.0 and OpenID Connect. Authlete is a real-world example of such backend services. The figure below illustrates the relationship between a frontend server and a backend service (Authlete).

Semi-Hosted Service Pattern
Authorization Code Flow + Authlete
Certified FAPI-CIBA OpenID Providers as of October 2019

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Takahiko Kawasaki

Takahiko Kawasaki

Co-founder and representative director of Authlete, Inc., working as a software engineer since 1997. https://www.authlete.com/