Thoroughly understand OAuth 2

In this paper, OAuth 2.0 design ideas and operation process, do a concise and popular explanation, the main reference material for RFC 6749.

I. application scenarios

To understand the application of OAuth, let me give you a hypothetical example.

There is a cloud printing website that can store users in Google photos and print them out. In order to use this service, users must read “cloud printing” to read photos stored on Google.

The problem is that only with the authorization of users can Google agree to “cloud printing” to read these photos. So how does cloud processing get the user’s authorization?

Traditionally, users tell their Google username and password to “cloud print,” which allows them to read their photos. Such practice has the following serious shortcomings.

（1）”Cloud printing “for subsequent services, will save the user’s password, this is very unsafe.

（2）GoogleWe have to deploy the password to login, and we know that simple password login is not safe.

（3）”Cloud Printing “has the right to access all the information stored in Google by the user, and the user can not limit the scope and validity of the authorization of Cloud Printing”.

（4）Only by modifying the password can users reclaim the power of “cloud printing”. But doing so will invalidate all other third party applications authorized by the user.

（5）As long as a third-party application is cracked, it will lead to user password leakage, as well as all password-protected data leakage.

OAuthTo solve these problems.

Two. Definition of nouns

Before explaining OAuth 2 in detail, we need to know several nouns. They are very important for reading the following explanations, especially for several maps.

（1） Third-party application：Third-party applications, also known as “client” in this article, are “cloud printing” in the example in the previous section.

（2）HTTP service：HTTPThe service provider is referred to as the “service provider” in this article, that is, the Google in the previous section.

（3）Resource Owner：The resource owner is also called “user” in this article.

（4）User Agent：User agents, in this article, refer to browsers.

（5）Authorization server：The authentication server, which is the service provider dedicated to processing the authentication server.

（6）Resource server：A resource server, that is, a server that stores user generated resources. It can be the same server as the authentication server, or it can be a different server.

Knowing these terms, it’s easy to understand that OAuth’s role is to allow “clients” to securely and controllably obtain authorization from “users” and interact with “service providers”.

Three, OAuth’s train of thought

OAuthA authorization layer is set up between the client and the service provider. Client can’t login directly to Service Provider, but can login to Authorization Layer to distinguish user from client. The client login authority layer is used.The token (token) is different from the user’s password. The user can specify the scope and validity period of the token layer token when he logs in.

“After the client “logs in to the authorization layer,” the service provider “opens the data stored by the user to the client” according to the scope and expiration of the token.

Four, operation process

OAuth 2.0The running process is as follows: RFC 6749.

（D）The client receives the authorization code, attaching the earlier “redirection URI”, and applies the token to the authentication server. This step is done on the client’s backstage server, not visible to users.

（E）Authentication server checks the authorization code and redirection URI, then sends the access token and refresh token to the client.

The following are the parameters needed for the above steps.

AIn the step, the client authenticated URI contains the following parameters:

response_type：Represents the authorization type, the option, and the value here is fixed to “code”.
client_id：Represents the ID of the client.
redirect_uri：Indicates redirection URI, optional
scope：Indicates the scope of application, optional.
state：Represents the current state of the client and can specify any value that the authentication server will return intact.

Here is an example.


GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

CIn the step, the server responds to the client’s URI, which contains the following parameters:

code：Indicates the authorization code. The validity of the code should be very short, usually set to 10 minutes, the client can only use the code once, otherwise it will be denied by the authorized server. This code is one-to-one correspondence with client ID and redirection URI.
state：If the client’s request contains this parameter, the authentication server’s response must also contain this parameter exactly as it does.

Here is an example.


HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
          &state=xyz

DIn the step, the client applies the token HTTP request to the authentication server, which contains the following parameters:

grant_type：Represents the authorization mode used, the option, where the value is fixed to “authorization_code”.
code：Represents the authorization code obtained last step.
redirect_uri：Indicates that the redirection URI must be an option and must be consistent with the value of the parameter in the A step.
client_id：The client ID must be selected.

Here is an example.


POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

EIn the step, the HTTP reply sent by the authentication server contains the following parameters:

access_token：The access token is required.
token_type：Indicates token type. This value is not sensitive to case. It must be bearer or Mac.
expires_in：Represents expiry time, in seconds. If you omit this parameter, you must set the expiration time in other ways.
refresh_token：Represents an update token, which is used to get the next access token.
scope：Indicates the scope of permission. If it is consistent with the scope of client application, this can be omitted.

Here is an example.


     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"
     }

As you can see from the above code, the relevant parameters are sent in JSON format (Content-Type: application / json). In addition, HTTP header information specifies that no caching is allowed.

Seven, simplified mode

The implicit grant type applies directly to the authentication server in the browser without going through the server of a third-party application, skipping the “authorization code” step, hence the name. All steps are completed in the browser, and the token is visible to the visitor.The client does not need authentication.

（D）The browser sends a request to the resource server, which does not include the Hash value received in the previous step.

（E）The resource server returns a web page, which contains the code that gets the token in the Hash value.

（F）The browser executes the script obtained on the previous step and extracts the token.

（G）The browser sends the token to the client.

The following are the parameters needed for the above steps.

AIn the step, the HTTP request sent by the client contains the following parameters:

response_type：Represents the authorization type. The value here is fixed to “token”.
client_id：Represents the ID of the client.
redirect_uri：The URI that represents redirection is optional.
scope：Indicates permission range, optional.
state：Represents the current state of the client and can specify any value that the authentication server will return intact.

Here is an example.


    GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

CIn the step, the authentication server responds to the client’s URI, which contains the following parameters:

access_token：The access token is required.
token_type：Represents a token type, which is not sensitive to case.
expires_in：Represents expiry time, in seconds. If you omit this parameter, you must set the expiration time in other ways.
scope：Indicates the scope of permission. If it is consistent with the scope of client application, this can be omitted.
state：If the client’s request contains this parameter, the authentication server’s response must also contain this parameter exactly as it does.

Here is an example.


     HTTP/1.1 302 Found
     Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
               &state=xyz&token_type=example&expires_in=3600

In the above example, the authentication server uses the Location bar of the HTTP header information to specify the Web address that the browser redirects. Note that the Hash part of this web site contains tokens.

According to Step D above, the next browser accesses the URL specified by Location, but the Hash section does not send. Next step E, the code sent by the service provider’s resource server, extracts the token from the Hash.

Eight. Password mode

In Resource Owner Password Credentials Grant, a user provides his or her own username and password to the client. The client uses this information to request authorization from the “service provider”.

In this mode, the user must give his password to the client, but the client must not store the password. This is often used in situations where the user has a high degree of trust in the client, such as when the client is part of the operating system, or is produced by a well-known company. The authentication server can not be executed only in other authorization modes.Only in this case can we consider this mode.

username：Indicates the user name and the option.
password：Indicates the user’s password.
scope：Indicates permission range, optional.

Here is an example.


     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=password&username=johndoe&password=A3ddj3w

CIn the step, the authentication server sends the access token to the client. Here is an example.


     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"
     }

In the above code, the meaning of each parameter can be found in the section of authorization code mode.

In the whole process, the client must not save the user’s password.

Nine. Client mode

Client Credentials Grant means that a client authenticates to a “service provider” in its own name, not in the name of a user. Strictly speaking, client mode is not the problem to be solved in the OAuth framework. In this modeThe user registers directly with the client, and the client requests the “service provider” to provide the service in its own name. In fact, there is no authorization problem.

scope：Indicates permission range, optional.


     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=client_credentials

The authentication server must authenticate the client identity in some way.

BIn the step, the authentication server sends the access token to the client. Here is an example.


     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,
       "example_parameter":"example_value"
     }

In the above code, the meaning of each parameter can be found in the section of authorization code mode.

Ten. Update token.

If the client’s “access token” has expired by the time the user accesses, a new access token needs to be requested using the “update token”.

The client sends an update token HTTP request, which contains the following parameters:

granttype：Represents the authorization mode used. The value here is fixed to “refreshtoken”, and must be selected.
refresh_token：Indicates that the update token that was received earlier must be selected.
scope：Indicates the scope of authorization of the application, can not exceed the scope of the previous application, if omitted, it is consistent with the previous application.

Here is an example.


     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

（Finished)

I. application scenarios

Two. Definition of nouns

Three, OAuth’s train of thought

Four, operation process

Seven, simplified mode

Eight. Password mode

Nine. Client mode

Ten. Update token.

Leave a Reply Cancel reply