1. Understanding OAuth2.0
OAuth2 is an open authorization standard that allows third-party applications to access protected resources in a secure and controlled manner without requiring users to share username and password information with third-party applications. OAuth2 is widely used in modern web and mobile application development to simplify the authorization process between applications and resource servers and improve application security.
The basic working principle of OAuth2 is as follows:
Case interpretation:
User authorizes third-party applications to access their social media accounts
- The user clicks the "Login" or "Authorize" button in the third-party application.
- Third-party applications redirect users to the social media platform’s authorization page.
- Users enter their social media account username and password (or scan the QR code) on the authorization page and click "Authorize."
- The social media platform will display the authorization details to the user, such as the application name, permission scope, etc., and ask the user to confirm the authorization.
- After the user clicks "Confirm Authorization", the social media platform will issue an access token (Access Token) to the third-party application.
- The third-party application stores the access token and uses it to access protected resources on the social media platform, such as user profile information, social shares, friends lists, etc.
In this case, the third-party application is the OAuth2 client application, the social media platform is the OAuth2 resource server, and the user is the OAuth2 resource owner. OAuth2 servers are services provided by social media platforms and are responsible for issuing access tokens.
The workflow of OAuth2 can be summarized into the following steps:
- The client application requests user authorization.
- After the user is authorized, the client application requests an access token from the OAuth2 server.
- The OAuth2 server issues access tokens to client applications.
- Client applications use access tokens to access protected resources on the resource server.
OAuth2 improves application security by isolating user password information from third-party applications. At the same time, OAuth2 is an open standard that is compatible with different applications, platforms and devices, is easy to understand and use, and can be quickly integrated into applications.
2. OAuth2.0 authorization method
OAuth2.0 A simple understanding of authorization is actually tokenthe process of obtaining a token ( ). OAuth The protocol defines four authorization methods for obtaining a token ( authorization grant ) as follows:
- Authorization code(
authorization-code) - hidden(
implicit) - Password type (
password): - Client Credentials (
client credentials)
But it is worth noting that no matter which authorization method we use, before a third-party application applies for a token, it must apply for a unique identity in the system: client ID ( ) client IDand client key ( client secret). Doing so ensures that token it is not used maliciously. Authorization code mode and password mode are more commonly used.
2.1 Authorization code mode
The authorization code method means that the third-party application first applies for an authorization code and then uses the code to obtain the token.
OAuth2.0Among the four types of authorization, the authorization code method is the most complicated, but it is also the most secure and the most commonly used method. This method is suitable forWebprojects with both front and back ends, because some projects have only back ends or only front ends, and the authorization code mode is not applicable.
Example of using qq login to scan QR code for authorization:
Request example:
(A) Step: Client applies for authentication URI
https://graph.qq.com/oauth2.0/show?which=Login
&display=pc
&scope=get_idollist%2Cget_fans……
&response_type=code
&redirect_uri=https%3A%2F%2Fpassport.iqiyi.com%2……
&client_id=xxxx
&state=ZOvw70n5zJtY1H%2……
Parameter Description:
| Parameter Type | illustrate |
|---|---|
| response_type | Authorization type, required, the value here is fixed to "code" |
| client_id | Client ID, required |
| redirect_uri | Redirect URI, the transfer connection after the authentication server accepts the request. The generated authorization code can be returned based on this connection. Required. |
| scope | Code is sent to the resource server to apply for the permission range, optional |
| state | Any value, the authentication server will return it unchanged to resist CSRF (cross-site request forgery) attacks. |
(B) Step: User Confirm Authorization
(C) Step: The server responds to the client’s URI
https://graph.qq.com//client.example.com/cb?code=SplxlOBeZQQ&state=xxx
Parameter Description:
| Parameter Type | illustrate |
|---|---|
| code | Authorization code, required. The authorization code validity period is usually set to 10 minutes and can be used once. This code has a one-to-one correspondence with the client ID, redirect URI, and user. |
| state | Return the value of the parameter passed by the client as it is |
(D) Step: The client applies for a token from the authentication server
Parameter Description:
| Parameter Type | illustrate |
|---|---|
| client_id | Represents the client ID, required |
| client_secret | Indicates security parameters, which can only be requested on the backend. |
| grant_type | Indicates the authorization mode used, required. The value here is fixed to "authorization_code" |
| code | Indicates the authorization code obtained in the previous step, required |
| redirect_uri | Indicates the redirect URI, which is required and must be consistent with the parameter value in step A. |
(E) Step: Data in response to (D) step
{
"access_token": access token,
"token_type": "bearer",
"expires_in": expiration time,
"refresh_token": "REFRESH_TOKEN",
"scope": "read",
"uid": user ID,
"info" :{...}
}
Parameter Description:
| Parameter Type | illustrate |
|---|---|
| access_token | Access token, required |
| token_type | Token type, this value is not case sensitive, required |
| expires_in | Expiration time, unit is seconds. If this parameter is omitted, the expiration time must be set in other ways |
| refresh_token | Update token, used to obtain the next access token, optional |
| scope | Permission scope, if it is consistent with the scope applied by the client, this item can be omitted |
2.2 Password mode
If you highly trust an application, RFC 6749 also allows users to directly tell the application their username and password. The application uses your password to apply for a token. This method is called "password".
In this mode, the user must give his or her password to the client, but the client must not store the password. This is usually used when the user has a high level of trust in the client, such as if the client is part of the operating system or is produced by a well-known company. The authorization server can only consider using this mode when other authorization modes cannot be implemented.
Applicable scenario: Authorization server built by the company
(A) The user provides the client with a username and password.
(B) The client sends the username and password to the authentication server and requests a token from the latter.
(C) After the authentication server confirms that it is correct, it provides the access token to the client.
2.3 Client mode
Client mode (Client Credentials Grant) means that the client authorizes the "service provider" in its own name, not in the name of the user.
Suitable for command line applications without a front end, that is, requesting tokens from the command line. Generally used to provide server-side services that we fully trust.
(A) The client authenticates to the authentication server and requests an access token.
(B) After the authentication server confirms that it is correct, it provides the access token to the client.
Some specific usage scenarios for client credentials include:
- IoT devices: IoT devices usually need to be connected to a cloud platform to send data and receive instructions. You can use client credentials mode to obtain an access token without requiring the user to log in.
- Smart home devices: Smart home devices usually need to be connected to a cloud platform to receive instructions and control other smart home devices. You can use client credentials mode to obtain an access token without requiring the user to log in.
- Wearable devices: Wearable devices often need to be connected to a cloud platform to synchronize data and receive instructions. You can use client credentials mode to obtain an access token without requiring the user to log in.
- Background data processing tasks: Background data processing tasks usually require access to an API to obtain data or process data. You can use client credentials mode to obtain an access token without requiring the user to log in.
- Service Integration: Integration is required between two services and client credential mode can be used to obtain access tokens without requiring user login.
2.4 Hidden
Some web applications are pure front-end applications without back-end. The token must be stored on the frontend. RFC 6749 stipulates the second method, which allows tokens to be issued directly to the front end. This method does not have the intermediate step of authorization code, so it is called (authorization code) "implicit". Skip the authorization code and redirect to the specified page after the qqredirect_uri authorization is passed .
https://graph.qq.com/oauth2.0/authorize?
response_type=token&
client_id=CLIENT_ID&
redirect_uri=http://juejin.im/callback&
scope=readThe hidden method applies for a token directly from the authorization server in the browser without going through the server of the third-party application, skipping the "authorization code" step. All steps are completed in the browser, and the token is visible to the visitor. And the client does not require authentication.
It is very unsafe to pass the token directly to the front end in this way. Therefore, it can only be used in some scenarios with low security requirements, and the validity period of the token must be very short. It is usually valid during the session. If the browser is closed, the token will become invalid.