OAuth 2.0 protocol parsing, oauth2.0 Parsing

OAuth 2.0 protocol parsing, oauth2.0 Parsing

OAPI-DESIGN-002 No.
Author: Liu Hailong
Weibo: [http://weibo.com/liuhailong2008]
Blog: [http://blog.csdn.net/stationxp]

Agreement Overview 4 Subjects

The complete oAuth 2.0 protocol flow consists of four subjects and six steps.
The four subjects are:
-Resource owner: A person is responsible for authorization. For Open APIs, that is, the producer. The caller approves the caller's application. After the application is approved, the authorization is completed, which is reflected in the records in the database.
-Client: generally a third-party application. For Open APIs, This is the caller.
-Authorization server: responsible for issuing and verifying the authorization credential.
-Resource server: provides resources or services.

6 steps

The client must initiate a call and communicate with the other three roles in sequence. Each role must go one by one and take six steps in total.

The process is as follows. First, the client communicates with the resource owner:

When the client submits the application, it submits the invoker uri. The authorization server can initiate the following request and return the grant code.

http://invoker_uri?grant_code=xxxxxxxx

The invoker uri must be consistent throughout the interaction process, and the resource must also be called from this uri.

The next step is the interaction process between the client and the authorization server.

After obtaining the token, the client does not need to directly deal with the authorization server.
Through token, the client can access resources happily until the token expires or expires.

Next, the client communicates with the resource server to enjoy the service.

The sequence diagram is displayed in the MD reader that supports sequence Syntax:

Created with Rapha rjl 2.1.2 Client Client Resource owner Resource owner Authorization Server Authorization Server Resource Server Resource Server 1. I want to access the XX Interface 2. This is "Authorization". 3. I want to access the X interface. This is "Authorization". 4. OK. This is the token. . I have completed the procedures. I want to access your XX1 interface. 6. 1. Okay . I have completed the procedures. I want to access your XX2 interface. . Okay

In the above process, the client directly interacts with the resource owner. oAuth 2.0 recommends that the authorized server be an intermediary, and the client and the resource owner do not directly communicate.

The preceding figure shows the big picture of oAuth 2.0.

Authorization server plan

OAuth 2.0 defines four authorization modes. The following uses the authorization code mode as an example. The following assumes that the reader is familiar with the authorization code mode process.

Function Design

The key to the Protocol is the implementation of the authorization server.
Do not consider any specific business when planning the authorization server function.
Authorize the server to complete the following tasks:
-Issue Token
-Update the Token.
-Verify the token.

Issuing tokens for External Interfaces

The Token issuance process is as follows:
First, the client initiates an application as follows:

http://auth_server/authorize?response_type=code&client_id=xxx&state=ddd&redirect_uri=httpxxxx

The address for sending the application must be the same as the value of the redirect_uri parameter.
If the request succeeds, auth_code is returned and the status code 302 is returned.

location: httpxxxx?auth_code=ssss&state=ddd

The returned auth_code is valid for 10 minutes and can only be used once.
Next, the client initiates a request to apply for a token.

http://auth_server/authorize?grant_type=authorization_code&auth_code=ddd&&redirect_uri=httpxxxx

Authorization server return:
Access_token, token_type, expires_in, refresh_token, scope

Resend Token

http://auth_server/authorize?grant_type=refresh_token&refresh_token=xxxxx

Verify Token

http://auth_server/authenticate?access_token=ddd&invoker_uri=xxx&scope=ss

Program Design

Interface AuthorizationServer {/** send token, update token */Response authorize (Request request);/** verify token */Response authenticate (Request request );} interface GrantHandler {/** authorize */Response grant (Request request);/** verify */Response authenticate (Request request );} interface AuthorizationCodeGrantHandler extends GrantHandler {/** return auth code */Response authCode (Request request );}

To implement the preceding functions, the authorization server should also implement user registration, Authorization application, authorization approval, resource definition, Resource Group Management (scope), and authorization code management (grant code) and Token management.