Understanding OAuth 2.0 and oauth2.0

Understanding OAuth 2.0 and oauth2.0
 

OAuth is an open network standard for authorization. It is widely used all over the world. The current version is version 2.0.

This article provides a concise and plain explanation of the OAuth 2.0 design concept and operation process. The main reference material is RFC 6749.

I. Application scenarios

To understand the applicability of OAuth, let me give a hypothetical example.

There is a "cloud printing" website that can print photos of users stored in Google. To use this service, you must allow "cloud printing" to read photos stored on Google.

The problem is that Google will accept "cloud printing" to read the photos only after being authorized by the user. Then, how does "cloud printing" obtain user authorization?

The traditional method is to tell your Google user name and password to "cloud printing", and the latter can read your photos. This practice has the following serious disadvantages.

(1) "cloud printing" will save the user's password for subsequent services, which is not safe.
(2) Google has to deploy Password Logon, but we know that simple Password Logon is not secure.
(3) "cloud printing" has the right to obtain all the information stored by users on Google, and users cannot limit the scope and validity of "cloud printing" authorization.
(4) only by changing the password can the user revoke the power granted to "cloud printing. However, this will invalidate all other third-party applications authorized by users.
(5) As long as a third-party application is cracked, the user password and all password-protected data will be leaked.

OAuth was born to solve these problems.

2. Glossary

Before explaining OAuth 2.0 in detail, you need to know a few special terms. They are crucial to understanding the subsequent explanations, especially several images.

(1)Third-party application: A third-party application, also known as "client" (client) in this article, that is, "cloud printing" in the previous example ".
(2)HTTP service: HTTP service provider, referred to as "service provider" in this article, that is, Google in the previous example.
(3)Resource Owner: Resource owner. This document is also called "user ).
(4)User Agent: User proxy. This document refers to the browser.
(5)Authorization server: Authentication server, that is, the server dedicated by the service provider to process authentication.
(6)Resource server: Resource server, that is, the server where the service provider stores user-generated resources. It can be the same or different server as the authentication server.

Once you understand the terms above, it is easy to understand that the role of OAuth is to allow the "client" to securely and controllable access to "user" Authorization and interact with "service provider.

Iii. OAuth ideas

OAuth sets an authorization layer between "client" and "service provider ). "Client" cannot directly log on to "service provider". You can only log on to the authorization layer to distinguish users from clients. The token used by the "client" to log on to the authorization layer, which is different from the user's password. You can specify the permission range and validity period of the token at the authorization layer during logon.

After the "client" logs on to the authorization layer, the "service provider" opens the user storage information to the "client" based on the permission range and validity period of the token.

Iv. Running Process

For example, the process of running OAuth 2.0 is from RFC 6749.

(A) After the user opens the client, the client requires the user to authorize.
(B) The user agrees to authorize the client.
(C) The client uses the authorization obtained in the previous step to apply for a token from the authentication server.
(D) after the authentication server authenticates the client, it confirms the correctness and agrees to issue a token.
(E) The client uses a token to apply for resources from the resource server.
(F) The resource server confirms that the token is correct and agrees to open the resource to the client.

B is the key in the above six steps, that is, how the user can authorize the client. With this authorization, the client can obtain the token and then obtain the resource with the token.

The following describes the four authorization modes of the client.

V. client Authorization Mode

The client must be authorized by the user to obtain the access token ). OAuth 2.0 defines four authorization methods.

• Authorization code)
• Implicit)
• Resource owner password credentials)
• Client credentials)

Vi. Authorization code mode

The authorization code mode is the most complete and rigorous authorization mode. It interacts with the "service provider" authentication server through the backend server of the client.

The procedure is as follows:

(A) when the user accesses the client, the latter directs the former to the authentication server.
(B) Select whether to authorize the client.
(C) assuming that the user is authorized, the authentication server directs the user to the "Redirect URI" (redirection URI) specified in advance by the client and attaches an authorization code.
(D) The client receives the authorization code and attaches the previous "redirection URI" to apply for a token from the authentication server. This step is completed on the backend server of the client, which is invisible to users.
(E) The authentication server checks the authorization code and redirect URI. After confirming the correctness, it sends the access token and the update token to the client ).

The following are the parameters required for the preceding steps.

In step A, the URI requested by the client for authentication includes the following parameters:

• Response_type: indicates the authorization type. required. The value here is fixed to "code"
• Client_id: indicates the Client ID, required
• Redirect_uri: indicates the redirection URI. Optional
• Scope: indicates the permission range applied for. Optional
• State: indicates the current status of the client. You can specify any value. The authentication server returns this value intact.

The following is an example.

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1Host: server.example.com

In step C, the server responds to the URI of the client, which includes the following parameters:

• Code: indicates the authorization code, required. The validity period of this code should be very short, usually set to 10 minutes. The client can only use this code once, otherwise it will be rejected by the authorized server. This Code corresponds to the Client ID and redirection URI.
• State: if the client request contains this parameter, the response from the authentication server must also contain this parameter.

The following is an example.

HTTP/1.1 302 FoundLocation: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA          &state=xyz

Step D: the client requests an HTTP request from the authentication server, which includes the following parameters:

• Grant_type: indicates the authorization mode used. required. The value here is fixed to "authorization_code ".
• Code: The authorization code obtained in the previous step. required.
• Redirect_uri: indicates the redirection URI, which is mandatory and must be consistent with the value of this parameter in step.
• Client_id: Client ID, required.

The following is an example.

POST /token HTTP/1.1Host: server.example.comAuthorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JWContent-Type: application/x-www-form-urlencodedgrant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

In Step E, the HTTP Response sent by the authentication server includes the following parameters:

• Access_token: indicates the access token, which is mandatory.
• Token_type: indicates the token type. The value is case-insensitive and mandatory. It can be of the bearer or mac type.
• Expires_in: indicates the expiration time, in seconds. If this parameter is omitted, the expiration time must be set in other ways.
• Refresh_token: indicates the update token used to obtain the next access token. Optional.
• Scope: indicates the permission range. If it is the same as the range applied by the client, this option can be omitted.

The following is an example.

     HTTP/1.1 200 OK     Content-Type: application/json;charset=UTF-8     Cache-Control: no-store     Pragma: no-cache     {       "access_token":"2YotnFZFEjr1zCsicMWpAA",       "token_type":"example",       "expires_in":3600,       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",       "example_parameter":"example_value"     }

The code above shows that the parameters are sent in JSON format (Content-Type: application/json ). In addition, the HTTP header information explicitly specifies that the cache is not allowed.

VII. Simplified Mode

Implicit grant type does not pass the server of a third-party application. It directly applies for a token from the authentication server in the browser and skips the "authorization code" step, hence the name. All the steps are completed in the browser, the token is visible to the visitor, and the client does not need to authenticate.

The procedure is as follows:

(A) The client directs the user to the authentication server.
(B) The user decides whether to authorize the client.
(C) assuming that the user is authorized, the authentication server directs the user to the "Redirect URI" specified by the client and contains the access token in the Hash part of the URI.
(D) the browser sends a request to the resource server, excluding the Hash value received in the previous step.
(E) The resource server returns a webpage containing code that can obtain the token in the Hash value.
(F) The Browser executes the script obtained in the previous step to extract the token.
(G) The browser sends the token to the client.

The following are the parameters required for the preceding steps.

In step A, the HTTP request sent by the client includes the following parameters:

• Response_type: indicates the authorization type. The value here is fixed to "token", which is required.
• Client_id: indicates the Client ID, required.
• Redirect_uri: indicates the redirected URI, which is optional.
• Scope: indicates the permission range, which is optional.
• State: indicates the current status of the client. You can specify any value. The authentication server returns this value intact.

The following is an example.

    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

In step C, the authentication server responds to the URI of the client, which includes the following parameters:

• Access_token: indicates the access token, which is mandatory.
• Token_type: indicates the token type. The value is case-insensitive and mandatory.
• Expires_in: indicates the expiration time, in seconds. If this parameter is omitted, the expiration time must be set in other ways.
• Scope: indicates the permission range. If it is the same as the range applied by the client, this option can be omitted.
• State: if the client request contains this parameter, the response from the authentication server must also contain this parameter.

The following is an example.

     HTTP/1.1 302 Found     Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA               &state=xyz&token_type=example&expires_in=3600

In the preceding example, the authentication server uses the Location column of the HTTP header information to specify the URL of the browser redirection. Note that the Hash part of this URL contains a token.

According to Step D above, the next browser will visit the URL specified by Location, but the Hash part will not be sent. In Step E, the Code sent by the resource server of the service provider extracts the token in the Hash.

8. Password Mode

In Resource Owner Password Credentials Grant, users provide their usernames and passwords to the client. The client uses this information and requests authorization from the "service provider.

In this mode, you must give your password to the client, but the client cannot store the password. This is usually used when users have a high degree of trust in the client. For example, the client is part of the operating system or is produced by a famous company. The authentication server can use this mode only when other authorization modes cannot be executed.

The procedure is as follows:

(A) The user provides the user name and password to the client.
(B) the client sends the user name and password to the authentication server and requests the token from the backend.
(C) The authentication server will provide the access token to the client after confirmation.

In step B, the HTTP request sent by the client includes the following parameters:

• Grant_type: indicates the authorization type. The value here is fixed to "password", which is required.
• Username: User Name, required.
• Password: indicates the user's password, required.
• Scope: indicates the permission range, which is optional.

The following is an example.

     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

In step C, the authentication server sends an access token to the client. The following is an example.

     HTTP/1.1 200 OK     Content-Type: application/json;charset=UTF-8     Cache-Control: no-store     Pragma: no-cache     {       "access_token":"2YotnFZFEjr1zCsicMWpAA",       "token_type":"example",       "expires_in":3600,       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",       "example_parameter":"example_value"     }

In the above Code, for the meaning of each parameter, see the authorization code mode section.

The client may not save the user's password throughout the process.

9. Client Mode

Client Credentials Grant indicates that the Client authenticates to the "service provider" in its own name rather than the user name. Strictly speaking, the client mode is not a problem to be solved by the OAuth framework. In this mode, the user registers directly with the client, and the client requires the "service provider" to provide services in its own name. In fact, there is no authorization problem.

The procedure is as follows:

(A) The client authenticates the identity to the authentication server and requires an access token.
(B) The authentication server will provide the access token to the client after confirmation.

In step A, the HTTP request sent by the client includes the following parameters:

• GrantType: indicates the authorization type. The value here is fixed to "clientCredentials ", required.
• Scope: indicates the permission range, which is optional.

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

The authentication server must verify the client identity in some way.

In step B, the authentication server sends an access token to the client. The following is an example.

     HTTP/1.1 200 OK     Content-Type: application/json;charset=UTF-8     Cache-Control: no-store     Pragma: no-cache     {       "access_token":"2YotnFZFEjr1zCsicMWpAA",       "token_type":"example",       "expires_in":3600,       "example_parameter":"example_value"     }

In the above Code, for the meaning of each parameter, see the authorization code mode section.

10. Update the token

If the "access token" of the client has expired during user access, you must use "Update token" to apply for a new access token.

The HTTP request sent by the client to update the token contains the following parameters:

• GrantType: indicates the authorization mode used. The value here is fixed to "refreshToken ", required.
• Refresh_token: indicates the update token received earlier. required.
• Scope: indicates the authorization scope applied for. It cannot exceed the range of the previous application. If this parameter is omitted, it indicates that it is consistent with the previous application.

The following is an example.

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