Introduction to the

OAuth 2.0 is an industry standard protocol for licensing third-party applications to access user data. The protocol specification and its extensions are being developed within the IETF OAuth Working Group.

OAuth stands for open authorization, which securely opens an application’s private data to designated third-party applications.

The term

  • Resource Owner: The resource owner authorizes the application to access its accountThe user. An application’s access to a user account is limited to the Scope of authorization (for example, read or write access).
  • Client: Clients are applications that attempt to access user accounts. Before accessing the account, itThe user's permission is required. The client can display it to the userThe login pageorAuthorization page of the logged in accountFor accessing a specific resourceThe access tokenAccess token.
  • Authorization Server: Authorization serverAuthenticating user credentialsAnd the use ofAuthorization code(Authorization code) Redirects users back to the client. The client communicates with the authorization server toConfirm their identity.And swaps the code for access tokens.
  • Resource Server: Resource server is a server used to access protected resources. It handles authenticated requests from applications with access tokens.
  • Scope: Specifies the level of access requested by the application from the client.
  • Consent:"Agree"The screen tells your users who is requesting access to their data and what kind of data you want to access.

After understanding the terms above, we can further explore the types of authorization of OAuth. The ultimate purpose of each authorization is to obtain access tokens to obtain resources.

Five different authorization processes

  • Authorization Code Grant
  • Implicit Grant
  • Resource Owner Credentials Grant
  • The Client Credentials Grant
  • Refresh Token Grant

Authorization code

This is a more complete authorization approach, and is explained in RFC-6749 for obtaining both access tokens and refresh tokens. After the access token has expired, the access token is reacquired by refreshing the token.

The overall process of this mode:

  1. After the client initiates an authorization request, the user will pull up the client application or redirect to the client website with the authorization temporary ticket code (authorization code) parameter.
  2. Access_token is exchanged via API with code parameters plus client_ID and client_secret, etc.
  3. Through access_token, the interface is called to obtain basic data resources or help users to achieve basic operations.

His authorization process is as follows:

The Client here does not refer to the browser. It refers to the Web application based on the browser. Usually, a server (background) serves as the proxy and authorization server for authorization authentication.

Key parameters:

  • client_id 和 client_secretBy:Authorization serverGenerate, and need to be in advanceAuthorization serverDo the record. Once generated, the basic retention fixed value is used to confirm client qualification;
  • scope: Determine the scope of authorization;
  • state: Used to preserve the status of requests and callbacks, and then send the request back to the client as it is. This parameter can be usedPrevent CSRF attacks(Cross-site request forgery attack), it is recommended that the client (such as the browser) wear this parameter, which can be set to a simple random number plus session for verification.
  • code: Authorization code, which is used to obtain the temporary certificate of access_token. Just to be safe, there will beRelatively short failure periodandCan only be used onceThe aging time is usually set to a few minutes.

Client_id is defined as the Client Identifier, which is the unique Identifier issued by the authorization server to registered clients. It represents the identity information provided by the client without encryption; It is exposed to the resource owner and is not allowed to be used for client authorization alone.

Implicit authorization

Story: In this process, the client obtains tokens directly without performing additional authorization code exchange steps to access resources on the resource server.

His authorization process is as follows:

This approach eliminates the process of exchanging Access tokens through code.

Client certificate authorization

Story: A client application provides its client credentials (client identifier and client key) to an authorized server to request permission to access a protected resource (owned by the client application) on a resource server. The authorization server authenticates client credentials and issues tokens.

Its flow is as follows:

In this process, clients can obtain tokens using only their client credentials (or other supported authentication methods).

Resource owner certificate grant

This authorization requires a trust relationship between the resource owner and the client, so be careful to start this type and allow it only when other processes are not available.

The client will ask the user to provide his authorization credentials (usually a username and password) as follows:

Refresh token authorization

If the token expires, there is no need to go through the process again, OAuth allows you to refresh the token directly to get a valid token.

Its specific process is as follows:

OAuth 2.0 licensed applications

Among these authorization types, authorization code authorization is the most commonly used method, such as authorized login of Tencent Open platform, dengdeng no-login process, Github authorized login and so on.

Read more:

> oauth.net/2/

> tools.ietf.org/html/rfc674…

> docs.github.com/en/develope…

> www.loginradius.com/blog/async/…

> www.ruanyifeng.com/blog/2019/0…

> developers.weixin.qq.com/doc/oplatfo…