1. Background
Recently, the company is preparing to launch an identity authentication platform (IAM), which mainly includes two parts, one is single sign-on and the other is account life cycle management. It involves several commonly used single sign-on standard authentication protocols, including SMAL, LOAP, CAS, OIDC, and Oauth2.0. This article explains the Oauth2.0 authentication protocol.
2. Oauth development history
The development history of OAuth can be divided into the following stages: In
December 2007 , OAuth version 1.0 was released and quickly became an industry standard.
In June 2008 , OAuth 1.0 Revision A was released, which was a slightly modified version that mainly fixed a security vulnerability.
In April 2010 , OAuth 1.0 was released in IETF, protocol number RFC 5849.
In 2010 , OAuth 2.0 was released, the next version of the OAuth protocol, which was incompatible with OAuth 1.0.
OAuth was originally born to solve the authorization problem in the web browser scenario. For example, there is a website A that supports QQ account registration when new users register. If website A can get the QQ nickname and avatar as the basic information for user registration of website A, the process for new registered users will be much simpler, and a lot of information will be available. There is no need for users to fill it in themselves, just apply the information of QQ number directly. This kind of registration model is very user-friendly, and naturally it is easy to increase users' enthusiasm for registration.
3. Definition of Oauth2.0
The "Auth" in the word OAuth 2.0 means "Authorization", and the letter "O" means "Open". Together they mean "Open Authorization". This is why we use OAuth scenarios, which usually occur in open platform environments. First, you need to distinguish between authentication and authorization:
- Authentication: Used to verify whether a user has permission to access the system. If the authentication is passed, the user can access the system to create, modify, delete, and query resources supported by the platform. The authentication method is to log in, such as account password login, mobile phone verification code login, etc.
- Authorization: Used to verify whether a user has the permission to access a certain resource. If the authorization is passed, the user can add, delete, modify, and check the resource.
Simply put, authentication is to prove the visitor's identity and determine whether he can enter the system; authorization is to determine what the visitor can do. Generally speaking, authentication is performed first and then authorization is checked.
4. Common roles of Oauth2.0
OAuth 2.0 has four main types of roles:
resource owner: The resource owner refers to the "user" of the terminal (that is, the owner of the data information in the authorized login).
resource server: Resource server , that is, the service provider stores protected resources. To access these resources, you need to obtain an access token.
client: The client represents a third-party application that makes resource requests to protected resources.
Authorization server: Authorization server , after verifying the resource owner and obtaining authorization successfully, will issue an access token to the client.
5. Common modes of Oauth2.0
OAuth2.0 provides four authorization (token acquisition) methods. Each of the four methods uses different execution processes, allowing us to adapt to different scenarios.
- Authorization-code
- implicit
- Password:
- client credentials
5.1. Authorization code (authorization-code) - the most widespread
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. This method is the most commonly used process and has the highest security. It is suitable for web applications with backends. The authorization code is sent through the front end, the token is stored in the back end, and all communication with the resource server is done in the back end. Such separation of front-end and back-end can avoid token leakage.
Important step instructions :
In the first step, website A provides a link. After the user clicks, it will jump to website B and authorize the user's data to be used by website A. Below is a schematic link from website A to website B.
https://b.com/oauth/authorize?
response_type=code&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=readIn the above URL, the response_type parameter indicates the request to return the authorization code (code), the client_id parameter lets B know who is making the request, the redirect_uri parameter is the jump URL after B accepts or rejects the request, and the scope parameter indicates the required authorization scope (here is only read).
In the second step, after the user jumps, website B will ask the user to log in, and then ask whether they agree to authorize website A. The user agrees, and website B will jump back to redirect_urithe URL specified by the parameter. When jumping, an authorization code will be returned, as shown below. In the URL below, codethe parameter is the authorization code.
https://a.com/callback?code=AUTHORIZATION_CODEIn the third step, after website A obtains the authorization code, it can request a token from website B on the backend.
https://b.com/oauth/token?
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
grant_type=authorization_code&
code=AUTHORIZATION_CODE&
redirect_uri=CALLBACK_URLIn the above URL, client_idparameters and client_secretparameters are used to allow B to confirm the identity of A ( client_secretthe parameters are confidential, so requests can only be made at the backend). grant_typeThe value of the parameter is AUTHORIZATION_CODE, indicating that the authorization method used is authorization code, and codethe parameter is obtained in the previous step. The authorization code is obtained, and redirect_urithe parameter is the callback URL after the token is issued.
In the fourth step, after website B receives the request, it will issue a token. The specific method is to redirect_urisend a piece of JSON data to the specified URL.
{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101,
"info":{...}
}In the above JSON data, access_tokenthe field is the token, and website A got it on the backend.
5.2. Implicit
Some web applications are pure front-end applications without back-end. At this time, the above method cannot be used, and the token must be stored on the front end. RFC 6749 specifies the second method, allowing 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". 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.
In the first step, website A provides a link, requiring users to jump to website B and authorize user data to be used by website A. In the URL below, response_typethe parameter is token, indicating that the token is required to be returned directly.
https://b.com/oauth/authorize?
response_type=token&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read In the second step, the user jumps to website B and agrees to authorize website A after logging in. At this time, website B will jump back to redirect_urithe jump URL specified by the parameter, and pass the token as a URL parameter to website A. In the URL below, tokenthe parameter is the token, so website A gets the token directly on the front end.
https://a.com/callback#token=ACCESS_TOKEN5.3. Password (password)
If a third-party application is highly trusted, 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". This method requires users to give their username/password, which is obviously very risky, so it is only suitable for situations where other authorization methods cannot be used, and it must be an application that users highly trust.
In the first step, website A requires the user to provide the username and password of website B. After getting it, A directly requests the token from B. In the URL below, grant_typethe parameter is the authorization method, where password"password" means "password", usernameand passwordare B's username and password.
https://oauth.b.com/token?
grant_type=password&
username=USERNAME&
password=PASSWORD&
client_id=CLIENT_IDIn the second step, after website B passes the identity verification, it will directly give out the token. Note that there is no need to jump at this time, but the token is placed in the JSON data as an HTTP response, so A gets the token.
5.4. Client credentials
Client credentials are generally suitable for command line applications without a front end. For example, the interface interaction authentication between systems is suitable for the scenario where system A requests the backend of system B and requires authentication. The token given in this way is for the third-party application, not for the user.
In the first step, application A sends a request to application B on the command line. In the following URL, grant_typethe parameters equal to client_credentialsindicate the use of credentials, client_idand client_secretare used to allow B to confirm A's identity.
https://oauth.b.com/token?
grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRETIn the second step, after website B passes the verification, the token will be returned directly.
{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101,
"info":{...}
}6. Oauth2.0 best practices (authorization code mode)
Let’s take a look at how the industry’s benchmark WeChat open platform implements open authorization. Website application WeChat login is a WeChat OAuth2.0 authorized login system built based on the OAuth2.0 protocol standard. WeChat OAuth2.0 authorized login currently supports the authorization_code mode.
Process steps :
- Website A needs to register on the WeChat open platform, fill in the callback address, and obtain the corresponding AppID and AppSecret.
- The user logged in to website A and obtained the login status of website A. JWT is used to maintain the login status.
- At this time, website A needs to access the user's WeChat-related resources, and it needs to obtain the user's WeChat authorization. Website A pops up a page directing users to go to the WeChat open platform website for authorization.
- The user clicks [Deauthorize], and the browser jumps to the WeChat QR code interface.
- At this time, the WeChat user has not yet logged in on the web side, so the WeChat user needs to [scan the QR code to log in]. After successful login, the browser will use the AppID to request the WeChat open platform and request authorization to website A.
- After agreeing, the WeChat Open Platform will return to the page for WeChat users to confirm: Website A will obtain the following permissions: 1. ... 2. ..., whether to agree to the authorization.
- Click [Agree Authorization], and the user's browser will request the authorization server of the WeChat open platform with the two parameters AppID and redirect URI. The redirect URI is the address of website A.
- The authorization server of the WeChat open platform receives the request and knows through the AppID that the WeChat user needs to authorize website A, so an authorization code CODE is generated and returned to the WeChat user in the form of a redirect. The redirect address is filled in Step 7: Request the URI brought up and bring this CODE as a parameter.
- After receiving the redirect reply, the WeChat user takes out the redirect URI and CODE, redirects to this URI, and brings this CODE as a parameter. Because the redirected URL is the domain name address of website A, and the user has already logged in to the website, this request will carry the login JWT.
- After website A receives the WeChat user CODE, it parses the uid of the source user of the request from the JWT, so that the website user uid is bound to the CODE. Then take out your AppID and AppSecret, and request the WeChat open platform authorization server together with CODE.
- After receiving the three parameters AppID + AppSecre + CODE, the WeChat open platform authorization server generates access_token and refresh_token, and returns these tokens to website A.
- After website A gets the access_token, it stores it, and there is a mapping relationship of uid->access_token. Later, with this access_token, you can access the designated resources of the WeChat user without having to log in and authorize the WeChat user every time.
7. Oauth2.0 token usage and update
7.1. Token usage
After website A gets the token, it can request data from website B's API. Every request made to the API must be accompanied by a token. The specific method is to add a field to the header information of the request, Authorizationand the token is placed in this field. In the following command, ACCESS_TOKENit is the token obtained.
curl -H "Authorization: Bearer ACCESS_TOKEN"
"https://api.b.com"
7.2. Update token
The validity period of the token has expired. If the user is asked to go through the above process again and apply for a new token, the experience is likely to be bad, and it is unnecessary. OAuth 2.0 allows users to automatically renew tokens. The specific method is that when website B issues a token, it issues two tokens at once, one for obtaining data and the other for obtaining a new token (refresh token field). Before the token expires, the user uses refresh token to send a request to renew the token.
https://b.com/oauth/token?
grant_type=refresh_token&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
refresh_token=REFRESH_TOKENIn the above URL, grant_typethe parameter refresh_tokenindicates that the token is required to be updated. client_idThe parameters and client_secretparameters are used to confirm the identity. refresh_tokenThe parameter is the token used to update the token. After website B is verified, a new token will be issued.
refresh_token has a long validity period (30 days). When refresh_token expires, the user needs to re-authorize it. Because access_token needs to be frequently transmitted on the network, the risk of being stolen is high, and the validity time of the access_token is set to be short; refresh_token is only transmitted on the network when renewing the access_token, and the risk of being stolen is relatively small, so refresh_token has Longer validity period. This dual token mechanism, one long and one short, will be safer.
The dual-Token mechanism is more secure and can handle online and offline renewal issues well. You can refer to this answer to understand the dual-Token mechanism in depth. As shown below:
