What is OAuth 2.0

Simply put, OAuth 2.0 is a licensing framework. It defines how third-party applications can access users’ restricted resources through user authorization.

For example, personal websites should support wechat account login, and the authorized login of wechat open platform uses OAuth 2.0.

The key participants involved in OAuth 2.0 are:

  1. Resource Owner: indicates the Resource Owner. This refers to wechat users.
  2. Third-party application: a third-party application. This refers to personal websites.
  3. Authorization Server: indicates the Authorization server. This refers to the authorized services of wechat open platform.
  4. Resource Server: a Resource server used to store and obtain user resources. This refers to the servers on wechat’s open platform.

Ii. Basic flow of OAuth 2.0

OAuth 2.0 consists of two key steps:

  1. A third-party application obtains user authorization.
  2. Third-party applications access user resources.

Among them, “obtaining user authorization” is the focus of the process, and the authorization certificate finally obtained is called Access Token. As shown below:

As shown in the figure above, the access token is obtained in two steps:

  1. Get the authorization code, which is the temporary authorization certificate: steps A, B, C, D.
  2. Exchange access tokens through code, which is the official authorization certificate: Steps E, F.

The details of obtaining access tokens are the focus of this article and will be covered in the next section.

How to obtain access Token

There are various ways to obtain access tokens. The Authorization Code Grant is the most common.

The authorization code mode flow is as follows:

Skip the details and look at what each step does:

  1. Steps A and B: The third-party application obtains user authorization.
  2. Step C: The third-party application obtains the authorization Code.
  3. Step D: A third-party application requests an Access Token.
  4. Step E: The third-party application obtains an Access Token.

User-agent: Front-end development students should be familiar with, most of the time refers to the browser.

Let’s go through the steps in a bit more detail:

1. Request user authorization

A third-party application that directs the resource owner to a specific address with the following information:

  • Response_type: Mandatory, request type. This is fixed to “code”.
  • Client_id: specifies the ID of a third-party application. This parameter is mandatory. Many places also use apppID instead.
  • Redirect_uri: optional. Redirection address after authorization. When a user is authorized, the authorization service redirects to the address with the authorization code.
  • Scope: Indicates the scope of resources requested by the third party. For example, they want to obtain basic information, sensitive information, etc.
  • State: Recommended for state retention. It can be any string. The authorized service returns intact.

Redirect_uri is optional, which may be confusing. In practice, redirect_URI is usually filled in and validated in the background of the application, so it can be optional.

2. User authorization returns

If the owner of a resource agrees to authorize a third-party application to access a restricted resource, the request is returned to the address specified by redirect_URI.

The address contained the following information:

  • Code: Specifies the authorization code. In the following steps, the access token is used to exchange.
  • State: Mandatory (if state is included in the authorization request), which is returned unchanged.

Request access token

A third-party application requests an Access token from the authorization service. Request parameters include:

  • Grant_type: Specifies the permission type, which is authorization_code for this parameter. This parameter is mandatory.
  • Code: Specifies the authorization code. In the user authorization step, the authorization service returns.
  • Redirect_uri: Mandatory. If redirect_URI was included in the authorization request step, it must be included here, and the value must be the same.
  • Client_id: specifies the ID of a third-party application. This parameter is mandatory.

4. Return access Token

If the request is valid and the authorization is successful, the authorization service returns the Access Token to the third-party application.

Key return fields:

  • Access Token: Mandatory. It is a certificate used by third-party applications to access user resources.
  • Expires_in: Recommended validity period of the access token.
  • Refresh Token: (Optional) Updates the credentials of the Access token. When an Access token expires, you can refresh the token as a certificate to obtain a new Access token.

Examples 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

Iv. Take wechat authorization as an example

Take unified login on wechat open platform as an example. For more details, please refer to the official documents.

The following figure shows the sequence diagram of wechat unified login:

The steps are broken down as follows:

1. Request user authorization: Steps 2, 3, and 4

Appid, redirect_URI, response_type, scope, state. Among them:

  • Appid: indicates the application ID, which is client_id mentioned earlier.
  • Redirect_uri: address of the authorization callback, which is filled in the wechat management background.
  • Response_type: response type, fixed to “code”.
  • Scope: license scope, snsapi_login for this parameter.
  • State: Indicates that the authorization service is sent back.

2. Return to User authorization: Step 5

The user agrees to authorize, redirects to redirect_URI, and returns the temporary ticket code. As follows:

redirect_uri? code=CODE&state=STATECopy the code

Request access token

After the application gets the temporary ticket, it uses the temporary ticket to exchange for the real ticket Access Token. Required parameters are as follows:

  • Appid: specifies the application ID. This parameter is mandatory.
  • Secret: Mandatory. Use the secret key and generate it in the background of wechat.
  • Code: specifies the authorization code obtained earlier. This parameter is mandatory.
  • Grant_type: Mandatory. The value is “authorization_code”.

4. Return access Token

The wechat background verifies that the request is valid and then returns the Access token to the third-party application.

An example is returned as follows:

{ 
    "access_token":"ACCESS_TOKEN", 
    "expires_in":7200, 
    "refresh_token":"REFRESH_TOKEN",
    "openid":"OPENID", 
    "scope":"SCOPE",
    "unionid": "o6_bmasdasdsad6_2sgVt7hMZOPfL"
}
Copy the code

In addition to the access_token, refresh_token and expires_in mentioned above, openID and UnionID are also returned here. These two are user information which are unique to wechat system and are not expanded.

Why not return access_token directly

In authorization code mode, the authorization service first returns the authorization code to the third-party application, and the third-party application uses the authorization code to exchange access Token.

Why not just return the Access Token?

Mainly for safety reasons.

Assume that third-party applications and authorized services do not communicate directly, and a layer of agents is separated between them. At the same time, third-party applications use HTTP protocol, so malicious agents can steal access tokens.

This is known as a man-in-the-middle attack.

Therefore, the access token exchange through code is adopted to increase security. In addition, the access token cannot be directly given to the user.

Compared with the complexity of the user-side network, the network environment of the application server is more controllable. But that doesn’t mean it’s totally safe.

If the interface of wechat open platform is based on HTTP, not only access token, but also Secret may be intercepted.

Vi. Related links

The 2.0 specification at https://tools.ietf.org/html/rfc6749

Why authorization_code https://stackoverflow.com/questions/13387698/why-is-there-an-authorization-code-flow-in-oauth2-when-implicit-flow-works- s

WeChat authorized https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421140842 web pages

About the author: Program Monkey Xiaoka, former Senior engineer of Tencent, is now the former head of haiyunhan Fintech front-end technology. Focus on technology architecture, technology sharing, project management.