Detailed explanation of oauth2 - Introduction (I)

Oauth2 Detailed explanation - Introduce ( One )

1. What is? OAuth2

---

OAuth( Open licensing ) It's an open standard , Allow users to authorize third-party mobile applications to access information they store on another service provider , Instead of providing a user name and password to a third-party mobile app or sharing all of their data ,OAuth2.0 yes OAuth Continuation of agreement , But not backward compatible OAuth 1.0 It's completely abolished OAuth1.0.

2. Application scenarios

---

Third party application authorization login ： stay APP Or web access to some third-party applications , For a long time, users will need to log in to another cooperation platform , such as QQ, Microblogging , Authorized login of wechat .

The illustration OAuth

Native app to grant authorization ：app Login request background interface , For safety certification , All requests are accompanied by token Information , If login authentication 、 Request background data .

Separate front and back single page application (spa)： Front and rear end separation frame , Front end requests background data , Need to carry out oauth2 Safety certification , For example, use vue、react the latter h5 Developed app.

3 Noun description

---

(1) Third-party application： Third party applications , Also known as " client "(client), For example, open Zhihu , Use a third party login , choice qq Sign in , At this time, Zhihu is the client .
(2)HTTP service：HTTP Service provider , Abbreviation in this paper " Service provider ", That is to say qq.
(3)Resource Owner： Resource owner , Also known as " user "(user), The login user .
(4)User Agent： The user agent , Browser in this article .
(5)Authorization server： Authentication server , That is, the server used by the service provider to handle authentication .
(6)Resource server： Resource server , The server where the service provider stores the user generated resources . It and authentication server , Can be the same server , It can also be a different server .

4 Operation process

---

OAuth 2.0 The operation flow of is as follows , Excerpt from RFC 6749.

OAuth 2.0 Operation flow

OAuth Operation process

(A) After the user opens the client , Client requires authorization from user .
(B) User agrees to authorize client .
(C) The client uses the authorization obtained in the previous step , Request token from authentication server .
(D) After the authentication server authenticates the client , Confirm no mistake , Agree to issue token .
(E) Client use token , Request resources from resource server .
(F) Resource server confirms that the token is correct , Agree to open the information to the client
Source .

5 Authorization mode

---

• Authorization code mode (authorization code)
• Simplified mode (implicit)
• Password mode (resource owner password credentials)
• Client mode (client credentials)

5.1 Authorization code mode

Authorization code mode (authorization code) Is the most complete function 、 The most rigorous authorization mode .

(1) User access client , The latter will direct the former to the authentication server , Suppose the user gives authorization , The authentication server directs users to the specified " Redirect URI"(redirection URI), With an authorization code .

(2) Client receives authorization code , Attach the previous " Redirect URI", Request token from authentication server ：GET /oauth/token?response_type=code&client_id=test&redirect_uri= Redirect page links . Request returned successfully code Authorization code , The general effective time is 10 minute .

(3) Authentication server checked authorization code and redirection URI, After confirmation , Send access token to client (access token) And update token (refresh token).POST /oauth/token?response_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri= Redirect page links .

5.2 Simplified mode

Simplified mode (implicit grant type) Servers that do not pass through third-party applications , Request token directly from authentication server in browser , Skip the " Authorization code " This step , Hence the name . All steps in browser , The token is visible to the visitor , And the client does not need authentication .

Simplified mode

Process steps ：

(A) Clients direct users to authentication servers .
(B) The user decides whether to authorize the client .
(C) Suppose the user gives authorization , The authentication server directs the user to the specified " Redirect URI", And in URI Of Hash Part contains access tokens .
(D) Browser makes request to resource server , It does not include the last received Hash value .
(E) Resource server returns a web page , The code contained in it can be obtained Hash Token in value .
(F) The browser executes the script obtained in the previous step , Extract token .
(G) Browser sends token to client .

request URL：

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

5.3 User name password mode

Password mode (Resource Owner Password Credentials Grant) in , Users provide their own user name and password to the client . Clients use this information , towards " Service provider " Asking for authorization . In this mode , The user must give his password to the client , But the client must not store the password . This is usually used when the user has a high trust in the client . In general, it does not support refresh token.

Illustration user name password mode

Step-by-step instructions ：
(A) User provides user name and password to client .
(B) Client sends user name and password to authentication server , Request token for the backer .
(C) After confirming that the authentication server is correct , Provide access token to client .

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

<article class="hentry">

5.4 Client mode (Client Credentials Grant)

Client in its own name , Not in the name of the user , towards " Service provider " authentication . Strictly speaking , Client mode does not belong to OAuth Problems to be solved by the framework . In this mode , Users register directly with clients , Client requests in its own name " Service provider " Provide services , In fact, there is no authorization problem .

Client mode

Its steps are as follows ：
(A) Client authenticates to authentication server , And requires an access token .
(B) After confirming that the authentication server is correct , Provide access token to client .

A In the step , From the client HTTP request , Contains the following parameters ：

• granttype： Indicates the type of Authorization , The value here is fixed to "clientcredentials", Will options .
• scope： Indicates permission range , optional .

POST /token HTTP/1.1     Host: server.example.com     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW     Content-Type: application/x-www-form-urlencoded      grant_type=client_credentials

</article>