The idea of OAuth:
(A) After the user opens the client, the client asks the user for authorization.
(B) User agrees to grant Client authorization.
(C) The client uses the authorization obtained in the previous step to request a token from the authentication server.
(D) After the authentication server authenticates the client, it confirms that it is correct and agrees to issue the token.
(E) The client uses the token to apply to the resource server to obtain the resource.
(F) The resource server confirms that the token is correct and agrees to open the resource to the client.
OAuth authentication
OAuth authentication is to enable third-party applications to authorize users to access the open platform (mainly access the resource server Resource Server in the platform) without obtaining sensitive user information (such as account password, user PIN, etc.). ) in the resource interface.
The main process is:
* 1. The user must first remain logged in, that is, the state of being authenticated
* 2. The third-party application requests user authorization (I understand that a displayed operation interface pops up for the user to confirm the authorization to the third-party)
* 3. After successful authorization, the user will request an "authorization code" (referring to the authorization_code instead of the final access_token) from the Authorization Server (authentication server), and the request will also carry redirect_uri (a link to a third-party application)
* 4. After obtaining the "authorization code", the browser page where the user is located will jump to redirect_uri (that is, a third-party application)
* 5. The third-party application carries the "authorization code" and application authentication information (client_id & client_secret) to the Authorization Server in exchange for access_token
* 6. Third-party applications can bring access_token when accessing the open platform
First pop up the authorization interface, enter the user name and password, send a request to the user and return an authorization code (Code), and then the third-party application obtains the token from the server through the authorization code. After obtaining the token, the third-party application can pass the token.
Request resource data from the server
Client authorization mode:
The client must be authorized by the user (authorization grant) in order to obtain the token (access token). OAuth 2.0 defines four authorization methods.
Authorization code mode (authorization code) The authorization mode with the most complete functions and the most rigorous process, such as WeChat's authorization mode, is similar to this
Simplified mode (implicit)
Password mode (resource owner password credentials)
Client mode (client credentials)
===================================Reprint ================= =============================
OAuth is an open network standard for authorization and is widely used around the world. The current version is version 2.0.
This article gives a concise and popular explanation of the design idea and operation process of OAuth 2.0. The main reference material is RFC 6749 .
1. Application scenarios
To understand where OAuth is applicable, let me take a hypothetical example.
There is a "cloud printing" website, which can print photos of users stored in Google. In order to use the service, users must let "cloud printing" read their photos stored on Google.
The problem is that Google will only allow "cloud printing" to read these photos with the user's authorization. Then, how does "Cloud Printing" obtain the authorization of users?
The traditional method is that users tell "cloud printing" their Google username and password, and the latter can read the user's photo. This approach has the following serious disadvantages.
(1) "Cloud Printing" will save the user's password for subsequent services, which is very insecure.
(2) Google had to deploy password login, and we know that simple password login is not secure.
(3) "Cloud Printing" has the right to obtain all the data stored by the user in Google, and the user cannot limit the scope and validity period of the authorization obtained by "Cloud Printing".
(4) Only by changing the password, the user can withdraw the right to "Cloud Printing". However, doing so will invalidate all other third-party applications authorized by the user.
(5) As long as one third-party application is cracked, it will lead to leakage of user passwords, as well as leakage of all password-protected data.
OAuth was born to solve these problems.
2. Definition of nouns
Before explaining OAuth 2.0 in detail, it is necessary to understand a few specific terms. They are crucial to reading the explanations that follow, especially the pictures.
(1) Third-party application : a third-party application, also known as "client" in this article, that is, "cloud printing" in the example in the previous section.
(2) HTTP service : HTTP service provider, referred to as "service provider" in this article, that is, Google in the example in the previous section.
(3) Resource Owner : The resource owner, also known as "user" in this article.
(4) User Agent : User agent, which in this article refers to the browser.
(5) Authorization server : The authentication server, that is, the server specially used by the service provider to process the authentication.
(6) Resource server : Resource server, that is, the server where the service provider stores the resources generated by the user. It and the authentication server can be the same server or a different server.
Knowing the above terms, it is not difficult to understand that the role of OAuth is to allow the "client" to obtain the authorization of the "user" in a safe and controllable manner and interact with the "service provider".
3. The idea of OAuth
OAuth sets up an authorization layer between the "client" and the "service provider". The "client" cannot log into the "service provider" directly, only the authorization layer, which distinguishes the user from the client. The token used by the "client" to log in to the authorization layer, which is different from the user's password. The user can specify the permission scope and validity period of the authorization layer token when logging in.
After the "client" logs in to the authorization layer, the "service provider" opens the user's stored data to the "client" according to the permission scope and validity period of the token.
Fourth, the operation process
The operation flow of OAuth 2.0 is as shown below, which is taken from RFC 6749.
(A) After the user opens the client, the client asks the user for authorization.
(B) User agrees to grant Client authorization.
(C) The client uses the authorization obtained in the previous step to request a token from the authentication server.
(D) After the authentication server authenticates the client, it confirms that it is correct and agrees to issue the token.
(E) The client uses the token to apply to the resource server to obtain the resource.
(F) The resource server confirms that the token is correct and agrees to open the resource to the client.
It is not difficult to see that among the above six steps, B is the key, that is, how can the user authorize the client. With this authorization, the client can obtain the token, and then use the token to obtain resources.
The following explains the four modes of client authorization.
Five, the authorization mode of the client
The client must be authorized by the user (authorization grant) in order to obtain the token (access token). OAuth 2.0 defines four authorization methods.
- Authorization code
- Simplified mode (implicit)
- Password mode (resource owner password credentials)
- Client mode (client credentials)
6. Authorization code mode
The authorization code mode (authorization code) is the authorization mode with the most complete functions and the strictest process. Its characteristic is to interact with the authentication server of the "service provider" through the client's background server.
Its steps are as follows:
(A) The user accesses the client, which directs the former to the authentication server.
(B) The user chooses whether to authorize the client.
(C) Assuming that the user grants authorization, the authentication server directs the user to the "redirection URI" (redirection URI) specified in advance by the client, along with an authorization code.
(D) The client receives the authorization code, attaches the earlier "redirect URI", and requests a token from the authentication server. This step is done on the server in the background of the client and is not visible to the user.
(E) The authentication server checks the authorization code and redirection URI, and after confirming that they are correct, sends an access token and a refresh token to the client.
Below are the parameters required for the above steps.
In step A, the URI for the client to apply for authentication includes the following parameters:
- response_type: indicates the authorization type, required, the value here is fixed to "code"
- client_id: indicates the ID of the client, required
- redirect_uri: Indicates redirect URI, optional
- Scope: Indicates the scope of permission to apply, optional
- state: Indicates the current state of the client, any value can be specified, and the authentication server will return this value intact.
Below 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
In step C, the server responds to the client's URI with the following parameters:
- code: Indicates the authorization code, which is required. The validity period of the code should be very short, usually set to 10 minutes, and the client can only use the code once, otherwise it will be rejected by the authorization server. There is a one-to-one correspondence between this code and the 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.
Below is an example.
HTTP/1.1 302 Found Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz
In step D, the client makes an HTTP request for a token from the authentication server, including the following parameters:
- grant_type: Indicates the authorization mode used, a required option. The value here is fixed to "authorization_code".
- code: indicates the authorization code obtained in the previous step, required.
- redirect_uri: Indicates the redirection URI, which is required and must be the same as the parameter value in step A.
- client_id: Indicates the client ID, required.
Below 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
In step E, the HTTP reply sent by the authentication server contains the following parameters:
- access_token: Indicates the access token, required.
- token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。
- expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
- refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
- scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。
下面是一个例子。
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" }
从上面代码可以看到，相关参数使用JSON格式发送（Content-Type: application/json）。此外，HTTP头信息中明确指定不得缓存。
七、简化模式
简化模式（implicit grant type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。
它的步骤如下：
（A）客户端将用户导向认证服务器。
（B）用户决定是否给于客户端授权。
（C）假设用户给予授权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。
（D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。
（E）资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。
（F）浏览器执行上一步获得的脚本，提取出令牌。
（G）浏览器将令牌发给客户端。
下面是上面这些步骤所需要的参数。
A步骤中，客户端发出的HTTP请求，包含以下参数：
- response_type：表示授权类型，此处的值固定为"token"，必选项。
- client_id：表示客户端的ID，必选项。
- redirect_uri：表示重定向的URI，可选项。
- scope：表示权限范围，可选项。
- state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。
下面是一个例子。
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
C步骤中，认证服务器回应客户端的URI，包含以下参数：
- access_token：表示访问令牌，必选项。
- token_type：表示令牌类型，该值大小写不敏感，必选项。
- expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
- scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。
- state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。
下面是一个例子。
HTTP/1.1 302 Found Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA &state=xyz&token_type=example&expires_in=3600
在上面的例子中，认证服务器用HTTP头信息的Location栏，指定浏览器重定向的网址。注意，在这个网址的Hash部分包含了令牌。
根据上面的D步骤，下一步浏览器会访问Location指定的网址，但是Hash部分不会发送。接下来的E步骤，服务提供商的资源服务器发送过来的代码，会提取出Hash中的令牌。
八、密码模式
密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。
在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。
它的步骤如下：
（A）用户向客户端提供用户名和密码。
（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。
（C）认证服务器确认无误后，向客户端提供访问令牌。
B步骤中，客户端发出的HTTP请求，包含以下参数：
- grant_type：表示授权类型，此处的值固定为"password"，必选项。
- username：表示用户名，必选项。
- password：表示用户的密码，必选项。
- scope：表示权限范围，可选项。
下面是一个例子。
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
C步骤中，认证服务器向客户端发送访问令牌，下面是一个例子。
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" }
上面代码中，各个参数的含义参见《授权码模式》一节。
整个过程中，客户端不得保存用户的密码。
九、客户端模式
Client mode (Client Credentials Grant) means that the client authenticates to the "service provider" in its own name, not in the name of the user. Strictly speaking, the client mode is not part of the problem that the OAuth framework is designed to solve. In this mode, the user registers directly with the client, and the client requests the "service provider" to provide services in its own name. In fact, there is no authorization problem.
Its steps are as follows:
(A) The client authenticates to the authentication server and asks for an access token.
(B) After the authentication server confirms that it is correct, it provides the access token to the client.
In step A, the HTTP request sent by the client contains the following parameters:
- grant type: Indicates the authorization type. The value here is fixed to "client credentials", which is required.
- scope: Indicates the permission scope, 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 verify the client's identity in some way.
In step B, the authentication server sends an access token to the client, the following 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, please refer to the section "Authorization Code Mode" for the meaning of each parameter.
10. Renewal Token
If the client's "access token" has expired when the user accesses, you need to use the "update token" to apply for a new access token.
The client issues an HTTP request to update the token with the following parameters:
- grant type: Indicates the authorization mode used. The value here is fixed to "refresh token", which is required.
- refresh_token: Indicates the update token received earlier, required.
- scope: Indicates the authorization scope of the application, which cannot exceed the scope of the previous application. If this parameter is omitted, it means that it is the same as the previous application.
Below 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
(over)