Safety Series II: OAUTH2.0 protocol

This paper extracts the main contents of the OAUTH2.0 specification RFC6749, some of which are copied from the document, and tell us about the story behind the third party's authorization.

First of all, to give an example of QQ login authorization, and then speak four kinds of authorization, two tokens, followed by a look at the protocol flow, analysis of the QQ login authorization Request Response message Interpretation OAuth2.0 protocol, and finally simply look at QQ to provide third-party authorized API to deepen understanding.

First, a preventive needle, in the explanation of four kinds of authorization, two kinds of tokens when you may be a little confused, but with the agreement process to understand.

If you feel that the layout is not good, you can visit my blog. TAT

Blog.bensonlin.me

If you feel well written, welcome to recommend, follow me and follow my GitHub (my homepage).

What is OAuth

Open authorization's abbreviation, namely the opening license agreement

OAuth's authorization allows the application not to involve the account information of the other party (such as user name and password), only the information that can be applied by the other party by authorization is ensured, and the user name password is not disclosed.

And what the whole process is going to do to keep it safe, the protocol defines the rules.

More definitions to view OAuth's Wikipedia on its own

Give me a chestnut.

The first step: Of course, you know the official website login, click QQ Avatar as QQ login

Figure 1

The second step: Login QQ and authorized, you can see the right is the QQ authorized to the content, access to our nickname, Avatar and gender information. Enter your username and password to sign in, you can see that the button shows login and authorization, that is, after the click has been stated that we agree to let us know the personal information obtained.

Figure 2

Because I have logged in, so directly above the QQ head (avatar is more than a dream) directly authorized.

Figure 3

The third step: Login authorization is successful, you can see your information on the front page (also need to supplement the personal information to register as a new user)

Figure 4

Note: Some site licensing, is first logged in, go to another page and then click Authorize.

PS: Remember the number of the figure, the analysis used in the back

Here's the point, first of all the roles involved, then the protocol process, etc.

Several characters

Premise: Know to use QQ login, use QQ's Avatar and nickname:

• Resource owner (Resource owner): An entity that can license access to protected resources. That is to have QQ resources (Avatar/nickname) of the person , that is, we.
• Resource Server (Resourceserver): A server that hosts protected resources that can receive and respond to requests to a protected resource using an access token. It is a QQ server that puts the avatar information
• Client:An application that uses the resource owner's authorization to initiate a request for a protected resource on behalf of the resource owner. That is the knowledge that is being used.
• Authorization Server (Authorizationserver): A server that issues an access token to a client after successfully validating the resource owner and obtaining authorization. Can be the same server as the resource server, or it can be a separate entity. Here is the assumption that the QQ server itself.

Another role is the user agent of the resource owner,usually our Web browser , we need the browser as a proxy to be able to operate

Four modes of authorization

This specification defines four license types-authorization codes, implicit licenses, resource owner password credentials, and client credentials-and the extensibility mechanisms used to define other types. Where the authorization code is our most commonly used, so separate licensing code, other types of details can download RFC6749 document view, here, search for the documents you want, and then right-click Save As Download

• Authorization code: The Authorization code is obtained by using the authorization server as the intermediary between the client and the resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to the authorization server and directs the resource owner back to the client with the authorization code. The authorization server authenticates the resource owner and obtains its authorization before the boot resource owner carries the authorization code back to the client. Because the resource owner authenticates only with the authorization server, the credentials of the resource owner do not need to be shared with the client. The authorization Code provides some important security benefits, such as the ability to authenticate the client's identity, as well as the transmission of the direct access token to the client rather than passing it through the resource owner's user agent and potentially exposing it to others, including the resource owner.
• Implicit licensing: In the implicit licensing process, the client is no longer issued an authorization code, instead the client is directly issued an access token (as the authorization of the resource owner) and the authorization server does not authenticate the client. This type of license is implicit because no intermediate credentials (such as an authorization code) are issued (and then used to obtain an access token).
• Resource owner password Credential: The Resource owner password credential (that is, the user name and password), which can be used directly as an authorization to obtain an access token. This credential should only be used when there is a high level of trust between the resource owner and the client (for example, if the client is part of the device's operating system, or is a highly privileged application), and when other licensing types, such as authorization codes, are not available.
• Client credentials: Client credentials can be used as a license when the scope of authorization is limited to a protected resource under client control or a protected resource that is previously agreed with the authorization server. Typically, client credentials are used as an authorization when the client represents itself (the client is also the resource owner ) or access to the protected resource based on an authorization request that was previously agreed with the authorization server.

As you can see, the Authorization Code mode (authorization code) is the most complete and most process-intensive licensing mode.

Two tokens

• Access token: An access token is a credential used to access a protected resource (such as our nickname and Avatar, for example, to access a protected access token). An access token is a string of authorizations issued to the client on behalf of the authorization server. The string is usually opaque to the client. Tokens represent the specific scope and duration of access permissions that are licensed by the resource owner and implemented by the resource server and the authorization server. (opaque means know that the client (known to the server) can get access tokens, because it is based on this token to obtain QQ personal information. ）
• The refresh token is issued by the authorization server to the client to obtain a new access token when the current access token fails or expires, or to obtain an additional access token of equal or narrower scope (the access token may have a shorter life cycle and fewer permissions than the resource owner authorized). The issuance of a refresh token is optional and is determined by the authorization server. is also opaque to the client

(Authorization Code license) Agreement process

+----------+|   Resource | |          Owner | | |+----------+     ^     |(B)+----|-----+ Client Identifier +---------------+|               -+----(A)--& redirection URI----> |   ||                                  user-| |   Authorization | |     Agent-+----(B)--User Authenticates---> |          Server | |                                  |               |         ||               -+----(C)--Authorization Code---< |    |+-|----|---+                                  +---------------+  |                                          | ^V (A) (C)|   |   |                                          |      |   |      ^ V |      |+---------+                                       |         ||  |>---(D)--Authorization Code----------' | |          Client |         & Redirection URI | |                                              |         || |<---(E)-----Access Token--------------------'+---------+ (w/optional Refresh Token)

(A) The client begins the process by directing the user agent of the resource owner to the authorization endpoint. The client includes its client identity, the request scope, the local state, and the redirect Uri, and once the access is granted (or denied) the authorization server will route the user agent back to the URI.

(B) The authorization server verifies the identity of the resource owner (through the user agent) and determines whether the resource owners grant or deny client access requests.

(C) Assuming that the resource owner has permission to access, the authorization server redirects the user agent back to the client using the redirect URI provided earlier (at the time of the request or client registration). The redirect URI includes the authorization code and any local state that was previously provided by the client.

(D) The client requests an access token from the token endpoint of the authorization server by including the authorization code received in the previous step. When the request is initiated, the client authenticates with the authorization server. The client contains the redirect URI used to obtain the authorization code for authentication.

(E) Authorize the server to authenticate the client, validate the authorization code, and ensure that the received redirect URI matches the URI used in step (C) to redirect the client. If passed, the authorization server responds by returning an access token with an optional refresh token (if the original access token expires, and the authorization server is allowed to send a new token, it will carry the past)

Other protocol processes can view RFC documents

Explain the QQ authorization of knowing

Note the above protocol process to see the analysis:

1. First, users click on the QQ login, the server will help us redirect to QQ third-party license server on the page (Figure 3) Request authorization (you can see that the address of the browser is the address of QQ, that is, it will not reveal the password of QQ to know, it is important to note that this link requires the use of HTTPS protocol, Because of the password involved in the user's login), at the same time, follow a redirect URL to a server-aware address, we click on authorization (Figure 3), authorization succeeds, redirect to the specified URL and return the authorization code (can be seen at the URL)
2. Then the server sends the same redirect URL and authorization code request authorization server access token, finally if the QQ server check no problem, return the access token, finally know the server call QQ provided API, with access token to obtain the user's information

Why divide it into two points? Because the 1th we can easily fetch the request response message, and the process of acquiring the access token is transparent to the resource owner (our user), that is, we do not see the access token, only the server has access to the token, it is not visible and should not let the resource owner see, otherwise it is not safe, Because anyone can use an access token to access our information

So what is the details of the whole process? Let's start analyzing the request response package.

Request response Package and parameter analysis

Here the use of Fiddler grab Bag tool, to remove some of the head, pay attention to the above-mentioned content, in order to facilitate the reading of the text, the line to deal with it;

Focus on: Request address, response status value, location; request and response parameters in the next section of the analysis

First step: (Know the homepage click QQ Login)

Request message: Direct request to the QQ server, the information you want to get into the URL. The key parameters in the GET request are scope, state, Redirect_uri, client_id, Response_type

GET https://graph.qq.com/oauth2.0/authorize?    scope=get_user_info%2cget_info%2cadd_t%2cadd_pic_t%2cget_other_info%2cget_fanslist%2cget_idollist%2cadd_idol% 2cadd_share     &state=8821ffbf09c3ff9c401fe404aa7fcaf7    &redirect_uri=https%3a%2f%2fwww.zhihu.com%2foauth %2fcallback%2Fqqconn    &response_type=code    &client_id=100490701 http/1.1  Host:graph.qq.comReferer:https://www.zhihu.com/

Response message: Response 302 Redirect to the location of the URL, that is, figure 3 of the page, the second step of the authorization request is located here, when the authorization to say that users allow QQ to give some personal information to know, so know will really get these rights.

http/1.1 302 Moved Temporarilylocation:https://graph.qq.com/oauth/show?which=login    &display=pc    &scope=get_user_info%2cget_info%2cadd_t%2cadd_pic_t%2cget_other_info% 2cget_fanslist%2cget_idollist%2cadd_idol%2cadd_share    &state=  8821ffbf09c3ff9c401fe404aa7fcaf7    &redirect_uri=https%3a%2f%2fwww.zhihu.com%2foauth%2fcallback% 2Fqqconn     &response_type=code    &client_id=100490701

Step Two: Authorization Request and authorization response (click Agree to sign in and authorize)

Authorization request

Key parameters are scope, state, Redirect_uri, client_id, Response_type

Request message

POST https://graph.qq.com/oauth2.0/authorize http/1.1Host:graph.qq.comReferer:https: // Graph.qq.com/oauth/show?which=login    &display=pc    &scope=get_user_info%2cget_info%2cadd_t%2cadd_pic_t%2cget_other_info%2cget_ fanslist%2cget_idollist%2cadd_idol%2cadd_share    &state=8821ffbf09c3ff9c401fe404aa7fcaf7     &redirect_uri=https%3a%2f%2fwww.zhihu.com%2foauth%2fcallback%2Fqqconn    & Response_type=code    &client_id=100490701

• Response_type: Required, Fixed is "code"
• client_id: Required, is the authorization server issued to the registered client client identity, that is, the developer to the QQ application to express the hope through the QQ authorized access, QQ consent will give the knowledge (client) a unique logo, so that after the authorization to log in, QQ party (authorization server) to know which application is requesting access
• scope: Optional, indicating what permissions the user is expected to get from QQ. Why the first step redirection to be accompanied by scope, because in order to prevent us to click on the authorization, someone maliciously modified the URL, resulting in the content of the authorization changes, with the first step, QQ server can first know what permissions are required (parameter content is get_user_info and the like content, You can see that the option of the tick in Figure 2 is actually based on the scope obtained), stored in the QQ server, and if the click on the authorization, to the scope of the server content has changed, then it must be someone modified scope, authorization will fail, to ensure the security.
• Redirect_uri: Optional, know the URL that you want to jump, point to your site's location, the same, need and the first step in the same redirct_url, the same reason as scope
• State: The recommended (which should be considered required), the opaque value that the client uses to maintain the status between the request and the callback. The authorization server contains this value when redirecting the user agent back to the client. This parameter should be used to prevent forgery such as cross-site requests CSRF

Authorization response

Response message: Redirect to location (Redirect_url), that is, back to the known, the key parameter is code, state

http/1.1 302 Moved Temporarilylocation:https://www.zhihu.com/oauth/callback/qqconn?    code=d38858bd4fe6058a48e461663ecb3cc3    &state=8821ffbf09c3ff9c401fe404aa7fcaf7

• code: Required. Authorization code generated by the authorization server. The authorization code must expire soon after issuance to reduce the risk of exposure. The recommended maximum authorization code life cycle is 10 minutes. The client cannot use the authorization code more than once. If an authorization code is used more than once, the authorization server must reject the request and should revoke (if possible) all tokens previously issued based on that authorization code. The authorization code is bound to the client identity and redirect URI.
• State: Required if the "state" parameter is committed in the client authorization request. Returns the same value.

Step Three: Access token requests and responses (known to request a token within the program)

Request token, last access to the user's avatar, nickname and other information

This step is transparent to us, we can not see, in fact, the simple call API call get, the key parameters are Grant_type, client_id, Client_secret, code, Redirect_uri

Access token request

The next section has QQ API

• grant_type: Required. The value must be set to "Authorization_code".
• Code: The authorization code received from the authorization server.
• Redirect_uri: Required and must be the same as the Redirect_uri at the first step of the request.
• client_id: Required

The authorization server must:

• Requires a confidential client or any client that is issued with client credentials (or other authentication requirements) for client authentication.
• If you include client authentication, verify client Identity,
• Make sure that the authorization code is issued to the authenticated secret client, or if the client is public, make sure that the code is issued to "client_id" in the request.
• Verify that the authorization code is valid and
• Ensure that the "Redirect_uri" parameter is given, and if the "Redirect_uri" parameter is included in the initial authorization request as described in 4.1.1, and if it is included, ensure that their values are the same.

Access token response

Response: Key parameters are Access_token, Refresh_token

If the access token request is valid and authorized, the authorization server issues an access token and an optional refresh token. If the request client authentication fails or is not valid, the authorization server returns an error response.

QQ API Deepen Understanding

QQ Access API

The understanding of State

Attack mode

Suppose Alice visits the Web site (Client) Request QQ Login Authorization (Figure 1), know that the request QQ (authorization server) authorization to obtain Alice's information, and then redirected to the QQ server (Figure 2), at this time know the binding is currently Alice user to QQ login authorization (assuming C Ookie binding, can be forged), then Alice needs to enter the user name and password authentication third party;

But Alice did not do so, did not enter the user name and password, but to save the URL, but let Bob in some way to access the URL, at this time if Bob with his username password login to the QQ Authorization server authentication, at this time, QQ with his identity generated an authorization code, redirect to know, This is the equivalent of repeating a request to know, if the cookie is changed to Alice's own send back to know, then Alice in the client's account is certified successful, and authentication is Bob, to get Bob's information;

How to prevent

The client should generate a value in some way based on the user currently in need of authentication, ensure its uniqueness, save to the server, this unique value is sent by the client to the authorization servers, enter the user name password authorization, the authorization server will return this value intact to the client, The client compares the value returned by the authorization server with its own saved value and, if inconsistent with the original sent to the authorization server, rejects it and no longer acquires the Access_token

Now such as Alice saved this URL, let Bob to log in, at this time the client will produce two state, respectively, Statea,stateb, known as Alice's identity Statea sent to QQ, and Bob login authentication, the same statea was returned to know, Knowing that Bob's own STATEB and returned state are the same, this time the comparison will fail and the next action is denied

The uniqueness of state prevents forgery attacks

Safety Series II: OAUTH2.0 protocol