Already learned: one article is enough to understand OAuth 2.0
Know that OAuth2.0 is an authorization mechanism, mainly used to issue tokens (token)
Article Directory
One, RFC 6749
The standard for OAuth 2.0 is RFC 6749. This document first explains what OAuth is.
OAuth introduces an authorization layer to separate two different roles: client and resource owner. …After the resource owner agrees, the resource server can issue tokens to the client. The client requests data through the token.
The meaning of this passage is that the core of OAuth is to issue tokens to third-party applications. Then, RFC 6749 went on to write:
(Because there are many scenarios on the Internet,) this standard defines four authorization methods for obtaining tokens (authorization grant)
that is to say, OAuth 2.0 specifies four procedures for obtaining tokens. You can choose the one that suits you best and issue tokens to third-party applications. Here are the four authorization methods
Authorization code (authorization-code)
hidden (implicit)
password (password):
client credentials (client credentials)
Note that no matter what kind of authorization method, before a third-party application applies for a token, it must first go to the system for filing, explain its own identity, and then get two identification codes: client ID (client ID) and client secret Key (client secret). This is to prevent the token from being abused. Third-party applications that have not been filed will not get the token.
2. The first authorization method: authorization code
Authorization code (authorization code) means that a third-party application first applies for an authorization code, and then uses the code to obtain a 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 transmitted through the front end, the token is stored in the back end, and all communication with the resource server is completed in the back end. This separation of front and back ends can avoid token leakage.
In the first step, A website provides a link. After the user clicks it, he will be redirected to B website and authorize user data to be used by A website. The following is a schematic link from A website to B website.
https://b.com/oauth/authorize?
response_type=code&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read
In the above URL, the response_typeparameter indicates the request to return the authorization code ( code), the client_idparameter lets B know who is requesting, the redirect_uriparameter is the redirect URL after B accepts or rejects the request, and the scopeparameter indicates the requested authorization range (here is read-only)
In the second step, after the user is redirected, website B will ask the user to log in, and then ask whether he agrees to authorize website A. The user agrees, and the B website will jump back to redirect_urithe URL specified by the parameter. When redirecting, an authorization code will be returned, as shown below.
https://a.com/callback?code=AUTHORIZATION_CODE
In the above URL, the codeparameter is the authorization code.
In the third step, after website A gets the authorization code, it can request the 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_URL
In the above URL, the client_idparameters and client_secretparameters are used to allow B to confirm the identity of A (the client_secretparameters are confidential, so the request can only be sent in the backend), grant_typethe value of the parameter is AUTHORIZATION_CODE, indicating that the authorization method used is the authorization code, and the codeparameter is taken in the previous step The redirect_urireceived authorization code, the parameter is the callback URL after the token is issued.
In the fourth step, website B will issue a token after receiving the request. The specific method is to send a piece of JSON data to the URL specified by redirect_uri.
{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101,
"info":{
...}
}
In the above JSON data, the access_tokenfield is the token, and the A website got it on the backend.
3. The second authorization method: hidden
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 in 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"。
In the first step, website A provides a link that requires users to jump to website B and authorize user data to be used by website A.
https://b.com/oauth/authorize?
response_type=token&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read
In the above URL, the response_typeparameter is token, which means that the token is required to be returned directly.
In the second step, the user jumps to the B website and agrees to grant the A website authorization after logging in. At this time, website B will jump back to redirect_urithe redirect URL specified by the parameter, and pass the token to website A as a URL parameter.
https://a.com/callback#token=ACCESS_TOKEN
In the above URL, the tokenparameter is the token, so website A gets the token directly on the front end.
Note that the location of the token is the URL anchor (fragment), not the query string (querystring). This is because OAuth 2.0 allows the redirect URL to be the HTTP protocol, so there is a risk of "man-in-the-middle attack" and the browser redirects When the anchor point is not sent to the server, the risk of token leakage is reduced
It is very insecure 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, usually during the session (session) is valid, the browser is turned off, the token becomes invalid.
4. The third authorization method: password type
If you trust an application highly, 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 the first step, website A requires users to provide the username and password of website B. After getting it, A directly requests the token from B.
https://oauth.b.com/token?
grant_type=password&
username=USERNAME&
password=PASSWORD&
client_id=CLIENT_ID
In the above URL, the grant_typeparameter is the authorization method, here passwordmeans "password type", usernameand passwordis B's user name and password.
In the second step, the token will be given directly after the B website has passed the authentication. Note that there is no need to redirect at this time, but put the token in the JSON data as an HTTP response, so A gets the token.
This method requires users to give their own 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.
5. The fourth authorization method: certificate type
The last method is client credentials, which is suitable for command line applications without a front end, that is, request tokens on the command line.
In the first step, the A application sends a request to B on the command line.
https://oauth.b.com/token?
grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET
Above URL, the grant_typeparameter is equal to client_credentialsrepresent use voucher, client_idand client_secretto confirm the identity of A to B so.
In the second step, the token will be returned directly after the verification of website B is passed.
The tokens given in this way are for third-party applications, not for users, that is, multiple users may share the same token.
(1) Use of token
After website A gets the token, it can request data from the API of website B.
At this time, every request sent to the API must carry a token. The specific method is to add a Authorizationfield to the header of the request , and the token is placed in this field.
curl -H "Authorization: Bearer ACCESS_TOKEN" \
"https://api.b.com"
In the above command, it ACCESS_TOKENis the token obtained
(2) Renew the token
. The validity period of the token is up. 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 update tokens.
The specific method is that when website B issues tokens, two tokens are issued at a time, one is used to obtain data, and the other is used to obtain new tokens (refresh token field). Before the token expires, the user uses the refresh token to send a request to update the token.
https://b.com/oauth/token?
grant_type=refresh_token&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
refresh_token=REFRESH_TOKEN
In the above URL, the grant_typeparameter refresh_tokenindicates that the token is required to be updated, and the client_idparameters and client_secretparameters are used to confirm the identity, and the refresh_tokenparameter is the token used to update the token.
After the B website is verified, a new token will be issued.