The 2.0

In October 2012, OAuth 2.0 was officially released as RFC 6749. At present, most open platforms such as Baidu Open Platform and Tencent Open Platform are supported by OAuth 2.0 protocol.

An overview of the

OAuth is an open standard that allows users to authorize third-party applications to access their information stored on another service provider without having to provide user names and passwords to third-party mobile applications or share all the content of their data.

The authentication and authorization process in OAuth 2.0 mainly includes the following role definitions:

  • Resource owner: The owner of the Resource (usually the user or platform providing the Resource service)
  • Resource Server: Resource server (a server that hosts protected resources)
  • -Leonard: The Client (browser, APP)
  • Authorization Server: Authorization server (issue access token, validate token, refresh token)

The interaction process

OAuth sets up an authorization layer between “clients” and “service providers.” Clients “cannot log directly into the” service provider, “but only into the authorization layer to separate users from clients.” The token used by the client to log into the authorization layer is different from the password used by the user. The user can specify the permission scope and validity period of the authorization layer token when logging in. After the client logs on to the authorization layer, the service provider opens the data stored by the user to the client based on the scope and validity of the token.

The following is the QQ authorization page, using the authorization code mode

Client authorization mode

  • Implicit: simplified mode, (insecure, suitable for purely static page applications)
  • Authorization Code: authorization code mode (an authorization mode with the most complete functions and most rigorous procedures, usually used in open platforms of the public network)
  • Resource owner password Credentials: Password mode (generally used in internal systems, the caller is the user.)
  • Client Credentials: Client mode (GENERALLY API calls between internal systems. Call between two platforms. Callers are platform based.)

Simplify the model

Simplified mode is suitable for purely static page applications. In this mode, the Access_token is easily leaked and cannot be refreshed

  1. The user requests a web site, such as www.tangyuewei.com
  2. Redirect to an authorization page
  3. User consent authorization
  4. Redirect to the website and bring itaccess_tokenSuch as: www.tangyuewei.com?access_token=123
  5. The resource of the resource server is obtained

Authorization code mode

For applications that have their own servers, it is a one-time temporary credential that can be exchanged for access_token and refresh_token. Once the exchange is successful, the code is immediately invalid and cannot be used again.

  1. The user requests a web site, such as www.tangyuewei.com
  2. Redirect to an authorization page
  3. User consent authorization
  4. Redirected to the application of a callback address, such as: www.tangyuewei.com/recieve_token?code=123
  5. withcodeIn return foraccess_tokenandrefresh_token

Password mode

Users provide their user name and password to the client in exchange for an Access_token from the service provider.

Client mode

Client mode can be used if a third party or the caller is a back-end module without a user interface. The authentication server directly authenticates the client and returns the token after the authentication succeeds.

Access the company’s internal systems

  • Background management system
  • Front desk business system

Background management system

Resources between background systems can access each other, such as log module, email module, SMS module, etc. (platform resources).

Systems that need to reference related modules can be authorized in client-side mode

Front desk business system

Resource access between foreground systems, such as user information, modules and so on (user resources).

Systems that need to reference related modules can use password mode authorization

Comprehensive advice

Based on the above mode and certification process, I think the following scenarios can be considered to introduce Oauth 2.0 authentication:

  1. System sensitive resource services perform security authentication and resource protection
  2. Unified login of multiple services protected resource requests between authentication centers and internal systems
  3. Authorize protected user resources to trusted third-party users
  4. Later to do development platform similar to Baidu open platform, Tencent open platform