Understand the OAuth2

[TOC]

What is Oatuh2 used for

There is a scenario where a user (let’s say QQ) wants to let a third-party application (such as a forum) get some information about himself (unique user id, such as QQ number, user personal information, such as some basic information, nickname and profile picture, etc.). But you can’t provide authentication information such as a user name and password while obtaining this information. For example, it is impossible for a user to give his or her username and password to a third party to go to a user center or something like that. There must be many ways to achieve this result. Oatuh2 is a specification to achieve the above goals, or a specific realization of the guidance program.

Oauth2 specific practices

First, let’s get to know several names of Oatuh2 for the convenience of the following elaboration.

  1. Third-party application: a third-party application
  2. Resource Owner: Indicates the Owner of the Resource
  3. Authorization Server: indicates the Authorization server
  4. Resource Server: A Resource server that stores specific resources. The authentication server is a different logical node from the authentication server, but physically, the two can be together
  5. User Agent: The User Agent, usually refers to the browser
  6. Http Service: The Service provider that holds the Resource Server. Can be understood as similar to QQ, or wechat so have user information service.

The function of Oauth2 is to enable third-party applications to pass the authentication of the authentication server under the authorization of the user (resource holder), so that the process guidance of the corresponding user resources can be safely obtained on the resource server.

Oauth2 process

Oauth2, according to the RFC6749 document, the general process is shown in the figure below

client

  1. A third-party application requests resources from the resource owner
  2. Resource holder authorization grants a license to a third-party application
  3. The third-party application gives the license to the authentication server for authentication. If the authentication succeeds, an Access Token is returned
  4. The third-party application uses the Access token to obtain the resources corresponding to the Access token from the resource server (that is, the resources of the resource holder in the first step).

In the above process, the second step, how the resource holder authorizes a license to the third party application, is the most critical part. RFC6749 provides four ways for a third party to obtain a license.

  1. Authorization code mode
  2. Simplify the model
  3. Password mode
  4. Client mode

Authorization code mode is one of the most detailed and rigorous procedures. Most third-party Oauth2 implementations on the network are based on the authorization code pattern. This paper also mainly explains the related process issues in the authorization code pattern. For the other three modes, you can refer to the RFC6749 documentation.

Authorization code mode

The following figure shows the flow of the authorization code mode

The third-party user is directed to the authorization page of the authentication server

The following parameters are required to boot a jump

  1. Response_type: authorization type. In authorization code mode, it is fixed to code
  2. App_id: indicates the ID of a third-party application.
  3. Redirect_uri: The redirection URI, which is the address that the authentication server redirects the user after successful authorization. In general, this is the original address requested by the current user in the third-party application
  4. Scope: indicates the authorization scope. Optional content that can be customized according to the requirements of third-party applications and implementers.
  5. State: transparent authentication parameter. RFC6749 recommends that the authentication server return this parameter in a different way when redirecting. Note that this parameter should strictly be a required parameter. Used to prevent CSRF attacks. This means that the URI used by a third-party server to authenticate redirects back is indeed the behavior of the authentication server and not a forgery by another attacker. Generally, the authorization page of the authentication server goes through HTTPS, but the authentication server may go through HTTP when it redirects to the callback address. In this case, the code may be leaked and the URL may be forged. The third-party application must then have a way to verify that the callback was actually initiated by the authentication server and was actually the result of its own previous authorization request. In fact, it is not very complicated, just store a random value in the session as the state parameter. The authentication server carries the state parameter when it calls back, and the third-party application verifies that the parameter is consistent with the state parameter value in its own session. If the authenticated authorization page is not HTTPS encrypted, the authentication state parameter can be stolen when the request is made. So there’s another way to do this. That is, the third-party application sends the encrypted state parameter, while the authentication server redirects with the decrypted state parameter. Third-party applications can also prevent attacks by checking whether the decrypted value is the same as that of the session. In this way, the authorization page can walk in plain HTTP.

The user chooses whether to grant authorization

This step is a user action. At present, the basic approach is to ask the user to enter a username and password on the authorization page. To ensure security, the page needs to be secured with HTTPS. Of course, if there is some other way to ensure that the username and password, as well as the authentication state parameters, are not disclosed, that is fine. If a user enters a correct user name and password, it is generally acknowledged that the user is authorized.

The authentication server generates the code and redirects the user to the specified URL

If the user grants authorization, the authentication server needs to generate a unique authorization code. The timeliness of this code should be relatively short, within 5 minutes is appropriate. And this code can only be used once, the next time will be invalid. In addition, this code has a one-to-one relationship with the client ID and redirect-URI parameters. The authentication server should now redirect the user to the redirect_URI specified initially. Carry state and code parameters

Third-party applications use code to exchange tokens for Access tokens at the authentication server

After verifying the correctness of the state parameter, the third-party application can then use code to exchange for the token at the authentication server. For this step, the third party application needs to carry on the parameters are

  1. Code: indicates the code parameter given by the authentication server
  2. Appid: unique identifier of the client
  3. Redirect_uri: The redirection parameter in the first request. Because code actually corresponds to appID and redirect_URI one by one. So when you trade code for a token, you also need to carry these two parameters
  4. Grant_type: authorization mode, which is fixed as “authorization_code”
  5. Appkey: Authenticates the identity of the application. Appid and AppKey can be understood as the user name and password of the application.

Oauth2 servers themselves are going HTTPS. So it can be transmitted in plain text without any security concerns. If it is not HTTP, you can directly set the login mode to user name and password, that is, md5 calculation for appKey. The question about why not pass accesstoken directly is based on security concerns. Because the authentication server is BASED on Https, third-party applications can be HTTP. If you bring accesstoken directly to the callback, you have a leak problem.

The authentication server returns Accesstoken

After verifying the validity of the parameter, the authentication server generates a globally unique token and returns the token to the third-party application. The returned content is represented in JSON. The returned parameters are as follows

  1. Access_token: token used to obtain the corresponding resource
  2. Expires_time: indicates the validity period of the token
  3. Reflesh_token: The user obtains the new accesstoekn token. Due to the short validity period of Accesstoken, once it fails, the user needs to go through the process again is quite tedious. To improve the user experience, use reflesh_token to get the new Accesstoken. However, different implementers have removed this return parameter. Because essentially reflesh_token means accesstoekn is forever. That’s no direct difference from extending Accesstoken.

Lin Bin said Java, reprint please indicate the source, thank you.

Welcome to scan code attention