In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >
Share
Shulou(Shulou.com)06/01 Report--
This article introduces the knowledge of "what are the four ways of OAuth 2.0". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!
RFC 6749
The standard for OAuth 2.0 is RFC 6749 files. This file first explains what OAuth is.
OAuth introduces an authorization layer to separate two different roles: the client and the resource owner. . With the consent of the resource owner, the resource server can issue a token to the client. The client requests data through a token.
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 ways to obtain tokens (authorization grant).
In other words, OAuth 2.0 specifies four processes 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)
Cryptographic (password):
Client credential (client credentials)
Note that regardless of the authorization method, before a third-party application applies for a token, it must file with the system, state its identity, and then get two identification codes: the client ID (client ID) and the client key (client secret). This is to prevent tokens from being abused. Third-party applications that have not been documented will not get tokens.
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 it to obtain a token.
This approach is the most commonly used process and the most secure, and it is suitable for Web applications that have a back end. The authorization code is transmitted through the front end, the token is stored at the back end, and all communication with the resource server is done at the back end. This separation of the front and rear ends avoids token leakage.
In the first step, website A provides a link, and after clicking, the user will jump to site B and authorize the use of user data to site A. The following 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=read
In the above URL, the response_type parameter indicates that the authorization code (code) is required to be returned, the client_id parameter lets B know who is requesting the request, the redirect_uri parameter is the redirected URL after B accepts or rejects the request, and the scope parameter indicates the required authorization scope (read-only in this case).
In the second step, after the user jumps, site B will ask the user to log in and then ask if he agrees to grant authorization to site A. When the user agrees, site B will jump back to the URL specified by the redirect_uri parameter. When you jump, an authorization code is returned, like the following.
Https://a.com/callback?code=AUTHORIZATION_CODE
In the above URL, the code parameter is the authorization code.
Third, after website A gets the authorization code, it can request a token from website B at the back end.
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_id parameter and the client_secret parameter are used to make B confirm the identity of A (the client_secret parameter is confidential, so the request can only be sent at the backend). The value of the grant_type parameter is AUTHORIZATION_CODE, which means the authorization method is the authorization code, the code parameter is the authorization code obtained in the previous step, and the redirect_uri parameter is the callback URL after the token is issued.
Step 4, after receiving the request, website B will issue a token. This is done by sending 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_token field is the token, and website A gets it at the back end.
The second way: hidden
Some Web applications are pure front-end applications with no back-end. The above method cannot be used at this time, and the token must be stored at the front end. RFC 6749 defines the second method, which allows tokens to be issued directly to the front end. This approach does not have authorization codes as an intermediate step, so it is called "implicit".
In the first step, website A provides a link that requires the user to jump to site B and authorize the use of user data to site 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_type parameter is token, which means that the token is required to be returned directly.
In the second step, the user jumps to website B and agrees to grant authorization to site An after logging in. At this point, site B will jump back to the jump URL specified by the redirect_uri parameter and pass the token to site An as a URL parameter.
Https://a.com/callback#token=ACCESS_TOKEN
In the above URL, the token parameter is the token, so website A gets the token directly at the front end.
Note that the location of the token is the URL anchor (fragment), not the query string (querystring), because OAuth 2.0 allows redirect URLs to be HTTP protocol, so there is a risk of "man-in-the-middle attack", while when the browser jumps, the anchor point is not sent to the server, reducing the risk of token leakage.
It is not safe to pass the token directly to the front end in this way. Therefore, it can only be used in scenarios with low security requirements, and the token must be valid for a very short period of time, usually during the session (session). When the browser is turned off, the token becomes invalid.
The third way: password type
If you have a high degree of trust in an application, RFC 6749 also allows users to tell the application directly their username and password. The application uses your password to apply for a token, which is called "password".
In the first step, website A requires the user to provide the user name and password of site B. After getting it, An asks for a token directly from B.
Https://oauth.b.com/token? Grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID
In the above URL, the grant_type parameter is the authorization method, where password means "password", and username and password are the user name and password of B.
In the second step, after the identity verification of B website is passed, the token is given directly. Notice that there is no need to jump, but instead put the token in the JSON data in response to HTTP, and A gets the token.
This approach requires users to give their own username / password, which is obviously risky, so it is only suitable for situations where no other authorization methods can be used, and must be highly trusted applications.
The fourth way: certificate type
The last method is client credentials, which is suitable for command-line applications without a front end, that is, requesting tokens under the command line.
In the first step, An 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
In the above URL, the grant_type parameter equal to client_credentials means that the credential type is used, and client_id and client_secret are used to let B confirm the identity of A.
The second step is to return to the token directly after the verification of the B website is passed.
The token given in this way is for third-party applications, not for users, that is, it is possible for multiple users to share the same token.
Use of tokens
After website A gets the token, it can request data from the API of website B.
At this point, every request to the API must be accompanied by a token. To do this, add an Authorization field 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, ACCESS_TOKEN is the token you got.
Update token
The validity period of the token is up, and if you ask the user to go through the above process and apply for a new token, it is likely to be a bad experience and unnecessary. OAuth 2.0 allows users to update tokens automatically.
The specific method is that when B website issues tokens, it issues two tokens at a time, one for obtaining data and the other for obtaining new tokens (refresh token field). Before the token expires, the user uses refresh token to issue 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_type parameter refresh_token indicates that the token is required to be updated, the client_id parameter and client_secret parameter are used to confirm the identity, and the refresh_token parameter is the token used to update the token.
After the verification of the B website, a new token will be issued.
This is the end of the content of "what are the four ways of OAuth 2.0". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.