Abstract

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

Flow

     +----------+
     | Resource |
     |   Owner  |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |         -+----(A)-- & Redirection URI ---->|               |
     |  User-   |                                 | Authorization |
     |  Agent  -+----(B)-- User authenticates --->|     Server    |
     |          |                                 |               |
     |         -+----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------'      |
     |         |          & Redirection URI                  |
     |         |                                             |
     |         |<---(E)----- Access Token -------------------'
     |         |      (w/ Optional Refresh Token)
     |  Client |
     |         |
     |         |                                   +---------------+
     |         |--(F)------ Access Token ------->  |    Resource   |
     |         |                                   |     Server    |
     |         |<-(G)---- Protected Resource ----  |               |
     +---------+                                   +---------------+

Terms:

• Client: example.com, the service server
• Resource Owner: user (Me)
• Authorization Server: Github authorization server
• Resource Server: Github resource server
• Authorization Grant: use code here
• UserAgent：the browser

The flow illustrated includes the following steps:

• (A) The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied).
• (B) The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request.
• (C) Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier (in the request or during client registration). The redirection URI includes an authorization code and any local state provided by the client earlier.
• (D) The client requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server. The client includes the redirection URI used to obtain the authorization code for verification.
• (E) The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI received matches the URI used to redirect the client in step (C). If valid, the authorization server responds back with an access token and, optionally, a refresh token.
• (F) The client requests the protected resource from the resource server and authenticates by presenting the access token.
• (G) The resource server validates the access token, and if valid, serves the request.

Implementation

Authorization (A)

Send:

• response_type=code
• client_id - the client ID, receive from 3rd party site.
• redirect_uri - callback URL.
• scope - the resource you want to access.
• state - a random string for verifying.

Receive(From Callback):

• state - the string which you sent in step (A).
• code - authorization code

Access Token (D)

Request:

• grant_type=authorization_code
• code - received authorization code from step (C)
• redirect_uri - callback URL.
• client_id - the client ID.

Response:

• access_token

Protected Resource (F)

Request:

• access_token: JWT, embed in header.

Response:

• Protected Resource: json string.

Reference:

• RFC6749
• Youtube：OAuth 2.0 and OpenID Connect (in plain English)