What is OAuth 2.0?

Oauth 2.0 is a licensed open web standard

role

Resource Owner: indicates the Resource Owner and User. User Agent: Indicates the User Authorization Server. Authorization Server: indicates the Server that provides third-party login services

Client authorization mode type

  1. Authorization code mode
  2. Implicit authorization mode
  3. Password mode
  4. Client mode

Authorization code mode

+----------+ | 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 ---------' | | Client | & Redirection URI | | | | | |<---(E)----- Access Token -------------------'
 +---------+       (w/ Optional Refresh Token)

Copy the code

1. Authorization Request For example, if you want to log in with GitLab, you want to log in with three-party authorization, such as Google account, when you click the Google icon, an authorization request will be initiated first. An authorization request is sent to the authorization server with the following parameters:

Response_type: indicates the authorization type. Client_id: indicates the ID of the client, which is mandatory. Redirect_uri: indicates the redirection URI. Indicates the current state of the client. It can be any value. The authentication server returns this value unchangedCopy the code

Here’s an example:

GET /authorize? The payload = code&client _id = s6BhdRkqt3 & state = xyz & redirect_uri = HTTPS % 3 a % 2 f % 2 fclient % 2 eexample % 2 ecom % 2 FCB HTTP / 1.1 Host:  server.example.comCopy the code

The authorization server validates the request, ensures that all parameters are submitted and valid, and directs the user to the authorization page

2. When the user clicks “Confirm authorization”, the authorization server returns the authorization code and state parameters, and sends the request to the corresponding callback address (redirect_URI). At this point, the user’s active behavior is over. 3. The third-party application, namely our client, will directly request the access token from the authorization server after obtaining the authorization code, and the parameters are as follows:

Grant_type: authorization mode. This parameter is mandatory"authorization_code"Code: authorization code received from the authorization server redirect_URI: callback address client_id: ID of an application client_secret: key issued by the authorization serverCopy the code

The authorization server returns the following parameters after the authentication succeeds:

HTTP/1.1 200 OK Content-type: Application /json; charset=UTF-8 Cache-Control: no-store Pragma: no-cache {"access_token":"2YotnFZFEjr1zCsicMWpAA"."token_type":"example"."expires_in": 3600,"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"."example_parameter":"example_value"
}
Copy the code

At this point, the entire authorization code process ends.

A few issues to pay attention to

  • Redirect_uri URI The entire authorization process is the same

  • The authorization process is just authorization: for example, if you want to log in to Youku with “Alipay” authorization, the whole authorization process is just Alipay verifying user authorization, returning an openId and some user information that Alipay allows to Youku, optimizing the openId and directly uploading it to the server for registration, and the whole authorization process is ended. After youku associated with resource acquisition and authorization without any association. Youku will make a unique mapping between the openId and the account, so that next time you use Alipay to authorize login, the service end of Youku will not create a new account for the user, that is, one-click login without the user password.

  • Why does the entire authorization process not directly return the access_Token but go through an intermediate step to obtain the authorization code and then obtain the Access_Token again according to the authorization code? The most direct answer is security. Code has a short validity period, and an Access_token can only be exchanged once before it becomes invalid. The request to get the code is made by the user after the user actively authorizes it and that’s where the user’s active behavior ends. If the fetch parameter does not contain appSecret, the code that comes back immediately initiates a request again, this time with appSecret, which the authorization server validates and returns the Access_token

Implicit authorization mode

+----------+ | Resource | | Owner | | | +----------+ ^ | (B) +----|-----+ Client Identifier +---------------+ | -+----(A)-- & Redirection URI --->| | | User- | | Authorization | | Agent -|----(B)-- User authenticates -->| Server | |  | | | | |<---(C)--- Redirection URI ----<| | | | with Access Token +---------------+ | |in Fragment
 |          |                                +---------------+
 |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
 |          |          without Fragment      |     Client    |
 |          |                                |    Resource   |
 |     (F)  |<---(E)------- Script ---------<|               |
 |          |                                +---------------+
 +-|--------+
   |    |
  (A)  (G) Access Token
   |    |
   ^    v
 +---------+
 |         |
 |  Client |
 |         |
 +---------+
Copy the code

As with an authorization code request, you first initiate an authorization request, validating the parameters

  1. Authorization request:
Response_type: indicates the authorization type, which is fixed as token client_id: indicates the client id. Redirect_uri: indicates the redirection URI. Scope: indicates the access permission. Indicates the current state of the client. It can be any value. The authentication server returns the value unchangedCopy the code

The client initiates an HTTP request as follows:

GET /authorize? The payload = token&client _id = s6BhdRkqt3 & state = xyz&redirect _uri = HTTPS % 3 a % 2 f % 2 fclient % 2 eexample % 2 ecom % 2 FCB HTTP / 1.1 Host:  server.example.comCopy the code

2. The authorization server validates the request to ensure that all parameters are submitted and valid. The authorization server verifies that the URI in the request parameters is the same as the URI for the redirect submitted by the client. If the request is valid, authorization server authentication authenticates the resource owner and presents the authorization page to the user. When a user agrees to an authorization request, the authorization server returns the following parameters:

Token_type: token type expires_in: expiration time scope: indicates the scope of the authorization permission. State: indicates the current status of the client. The value can be anyCopy the code

These parameters are concatenated to the end of the redirect URI address

3. A third-party application makes a request to the resource server that does not contain the access_token obtained in the previous step. The resource server returns a web page (usually an HTML document with an embedded script) that extracts the token. The browser sends the access_token to the client and the whole simple authorization mode ends.

The difference between implicit authorization and authorization code authorization is that the access_token is obtained directly without the code step. However, the obtained Access_token requires the resource server’s script to be extracted from a third-party proxy (i.e. browser) and sent to the client.

Password mode

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      v
      |    Resource Owner
     (A) Password Credentials
      |
      v
 +---------+                                  +---------------+
 |         |>--(B)---- Resource Owner ------->|               |
 |         |         Password Credentials     | Authorization |
 | Client  |                                  |     Server    |
 |         |<--(C)---- Access Token ---------<|               |
 |         |    (w/ Optional Refresh Token)   |               |
 +---------+                                  +---------------+
Copy the code

In this mode, the user must give the “username” and “password” to the client, and the client cannot store the password. This is usually used when there is a high degree of trust in the user reading client.

  1. The resource owner provides his user name and password to the client
  2. The client authenticates to the authorization server when initiating the request
  3. The authorization server authenticates the client, validates the resource owner’s credentials, and issues access tokens if valid.

Access token request parameters:

Grant_type: The value must be"password"Username: indicates the username of the resource owner. Password: indicates the password of the resource owner. Scope: indicates the client authorization request scopeCopy the code

Such as:

POST/token HTTP / 1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW content-type: application/x-www-form-urlencoded grant_type=password&username=johndoe&password=A3ddj3wCopy the code

The authorization server verifies the authorization request. The parameters are as follows:

HTTP/1.1 200 OK Content-type: Application /json; charset=UTF-8 Cache-Control: no-store Pragma: no-cache {"access_token":"2YotnFZFEjr1zCsicMWpAA"."token_type":"example"."expires_in": 3600,"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"."example_parameter":"example_value"
}
Copy the code

Client mode

 +---------+                                  +---------------+
 |         |                                  |               |
 |         |>--(A)- Client Authentication --->| Authorization |
 | Client  |                                  |     Server    |
 |         |<--(B)---- Access Token ---------<|               |
 |         |                                  |               |
 +---------+                                  +---------------+
Copy the code

In fact, this mode is not an authorization mode. It is the behavior of the client, not the user. 2. The authorization server authenticates the client and issues an access token if the authentication is valid

Access token request:

Grant_type: indicates the authorization type. The value must be"client_credentials"Scope: the client asks for authorization requestCopy the code

As follows, request:

POST/token HTTP / 1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW content-type: application/x-www-form-urlencoded grant_type=client_credentialsCopy the code

The authorization server validates the request and returns if it is valid, with the token:

HTTP/1.1 200 OK Content-type: Application /json; charset=UTF-8 Cache-Control: no-store Pragma: no-cache {"access_token":"2YotnFZFEjr1zCsicMWpAA"."token_type":"example"."expires_in": 3600,"example_parameter":"example_value"
}
Copy the code

Refresh the access token

If the authorization server issues a refresh_token, the client can initiate a refresh of the access_token. Generally, the refresh_token validity period is greater than the validity period of the access_token request parameters are as follows:

Grant_type: authorization type, which must be"refresh_token"Refresh_token: indicates the refresh token issued to the client. Scope: indicates the access permission rangeCopy the code

The following HTTP request

POST/token HTTP / 1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW content-type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIACopy the code