The 2.0

(the original: tutorials.jenkov.com/oauth2/inde…). Demo: github.com/qihaiyan/ng…

The 2.0 tutorial

OAuth 2.0 is an open standard protocol that allows applications to access user-authorized data from other applications. For example, a game can get user information from Facebook, or a location-based application can get user information from Foursquare, etc.

Here’s an example:

First the user enters the game’s Web application, which requires the user to log in with a Facebook account and is directed to the Facebook login screen. Once the user logs in to Facebook, the user is redirected to the previous game application. At this point, the application has access to the user’s Facebook user data and authorization information.

The 2.0 cases

OAuth 2.0 can be used to access user information from other applications within one application and provide user authorization services for other applications to invoke. OAuth 2.0 is an alternative to OAuth 1.0 because OAuth 1.0 is too complex, such as certificates. OAuth 2.0 is simpler and does not require certificates, just SSL/TLS.

The 2.0 specification

The purpose of this tutorial is to provide an overview of the OAuth 2.0 protocol to help understand it, not to cover all the details of the protocol. If you plan to implement a protocol for the 2.0, it is best to read the specification details, specification of address: tools.ietf.org/html/draft-…

Summary of the 2.0

As mentioned in the previous introduction, OAuth 2.0 is an open standard that allows applications to access user-authorized data from other applications. Now let’s introduce how this protocol works and the various concepts mentioned in the specification.

OAuth 2.0 provides different ways to obtain permissions to access resources in the resource server. Let’s look at one of the safest and most common uses: how one Web application requests access to another web application.

The following example diagram illustrates the entire process:

First the user accesses the client application, which has a “Sign in via Facebook” button.

Second, when the user clicks this button, the user is redirected to the authentication server (Facebook). The user then logs in and is asked if the client application can use his user information. The user clicks ok.

Third, the authentication server redirects the user to the URL provided by the client application. The redirected URL is typically registered with the authentication server by the owner of the client application. After registration, the authentication server generates a Client ID and a Client password. The redirected URL will have a code parameter, which is an identification of the authentication.

Step 4: After the redirection is complete, the user will enter the redirected page, and the client application communicates with the authentication server in the background, sending the client ID,client password, and code parameters obtained in the previous step to the authentication server. The authentication server returns the Access Token to the client application.

Once a client application receives an Access token, it can use it to access resources provided by Facebook.

OAuth 2.0 application role

OAuth 2.0 defines the following application roles:

Resource Owner Resource Server Client Application Authorization ServerCopy the code

Resrouce Owner is the Owner of the data. For example, a user on Facebook or Google is a Resrouce Owner. The resource they have is user data. The user icon in the sample figure represents Resrouce Owner. Resrouce Owner can also be an application.

Resource Servers are services that host resources, such as Facebook or Google.

The Client Application requests access to resources stored on the Resource server that are owned by the Resource Owner.

The Authorization Server authorizes Client applications. Client applications can access resources on the resource Server only after the Authorization passes. The authentication server and resource server can be the same application or deployed separately.

OAuth 2.0 Client type

The OAuth 2.0 specification defines two client types:

Private type
overt

The private client saves the client password. The authentication server generates a Client password for each client application. The authentication server uses the client password to identify the client application as a registered application, rather than other fraudulent programs. A Web application can be a private client. Only the system administrator can log in to the application server and view the client password.

Open clients do not save client passwords. For example, if the client password is stored in a mobile APP or desktop program, the client password can be obtained by means of cracking, which is very insecure.

Client application representation

Web Application
User Agent (Rich Web Client)
Native app

Web Application

Web programs run on web servers. The Client password used for web application authentication is stored on the server and therefore is private. Here is an example diagram of a Web application:

User Agent Application (Rich Web Client)

Rich Web client applications refer to web applications built by javascript, and the browser is the client proxy. The feature of this type of application is that the program is stored on the Web server, but when running, the browser downloads javascript programs to the local, directly executed in the browser, such as those developed in javascript web version of the game. Here is an example diagram of a rich Web client:

Native app

(Note: this refers to the application without back-end server, all data and configuration can only be stored in the client program.)

Native apps include mobile apps and desktop apps. Native applications are directly installed on the user’s device (computer, mobile phone, tablet), and Client Password is saved on the user’s device. Here is an example of a native app:

Hybrid applications

These applications are usually a mix of native and Web application development techniques, with corresponding back-end servers. This type of application is not mentioned in the OAuth 2.0 specification, and can be flexibly selected from any of the three authentication types mentioned above.

The 2.0 certification

Client ID, Client Secret and Redirect URI
Authorization Grant
Authorization Code
Implicit
Resource Owner Password Credentials
Client Credentials

To access resources on the resource server, a client application must obtain authentication and authorization.

Client ID, Client Secret and Redirect URI

The client application needs to be registered with the authentication server. After the registration is complete, the authentication server generates the client ID and client password of the application. Client_id and client_password are unique on the same authentication server and will not be duplicated. Client applications can register with multiple authentication servers (for example, Facebook and Google). Different authentication servers generate different client_id and client_password for client applications. When client applications need to access resources on the resource server, the authentication server is preferred for authentication. During authentication, the corresponding client_id and client_password must be sent to the authentication server. When a client application registers with the authentication server, it needs to fill in a redirection URL. After the resource owner successfully authorizes the client application, the resource owner (simply referred to as the system user) is redirected to the page specified by the redirected URL.

Certificate authority

The resource owner applies authentication and authorization to the client. Authentication and authorization require the cooperation of the authentication server and resource server.

The OAuth 2.0 specification lists four authentication and authorization modes, each of which has different security features:

Authorization Code
Implicit is a simplified model.
Resource Owner Password Credentials (User Password mode)
Client Credentials

Each of these authorization methods is explained below.

Authorization Code

The Authorization Code authentication process is as follows:

The resource owner (user) enters the client application.
The client application allows users to log in through an authentication server.
Before login, the client application redirects the user to the login page of the authentication server and sends the client ID to the authentication server so that the authentication server knows which client application is requesting authentication and authorization.
After a user logs in to the authentication server, the system prompts the user whether to authorize the client application. After the user agrees to authorize the client application, the user is redirected back to the client application.
When a client application is redirected, the URL specified when the client application is registered with the authentication server is used. At the same time, the authentication server sends an authorization code that represents the authentication process.
After the client application is successfully redirected to the authentication server, the client application interacts with the authentication server in the background and sends the authorization code obtained in the previous step together with the client ID and client password to the authentication server.
The authentication server verifies the received data and sends the Access token to the client application.
Then the client application can use the access token received to access the resource server. Here is an example diagram:

Implicit is a simplified model.

Implicit (simplified mode) is similar to Authorization Code (Authorization Code mode), except that when a user is redirected to a client application after successful login, the Access Token is directly returned to the client application. This means that the Access token is visible in the client application. While the Authorization Code (Authorization Code mode), access token is in the Web server, is not visible to the client. This is the biggest difference between the two models. In addition, the client application only sends the client ID to the authentication server. If the password is sent together with the client password, the client password needs to be stored in the client application, which is a security risk. It is easy to get the Client password stored in the client application by means of cracking. Here is an example diagram:

Resource Owner Password Credentials (User Password mode)

Resource Owner Password Credentials (Password mode) Allows client applications to use user names and passwords. For example, users can enter their Twitter username and password directly into the client application. Password mode should only be used if the client application is fully trusted. (Because the user name and password are entered in the client application, the client application can obtain and save the user’s user name and password). Password mode is generally used in rich Web client applications and native applications.

The Client Credentials (Client mode)

The Client Credentials mode is used to access resources independent of the user and therefore does not require user authorization.

The 2.0 node

OAuth 2.0 defines a collection of nodes. A node is typically a URL on a Web server. Specifically include:

Certification of the node
Token node
Redirection node

Authentication nodes and Token nodes reside on authentication servers, and redirection nodes reside on client applications. Here’s an example:

The OAuth 2.0 specification does not explicitly define the URL of a node, and different implementations will provide different urls.

Certification of the node

The authentication node is the address for users to log in to.

Token node

Token nodes are provided by authentication servers for client applications to obtain access Token addresses.

Redirection node

Redirection Node In client applications, users are redirected to this address after successful login.

OAuth 2.0 request and response

When a client application requests an Access Token, it sends an HTTP request to the authentication server. Different authentication and authorization types have different request and response contents. There are four authentication and authorization types:

Authorization Code
Implicit is a simplified model.
Resource Owner Password Credentials (User Password mode)
Client Credentials

The content of each type of request and response will be explained in detail in a subsequent article.

OAuth 2.0 Authorization Code request and response

The authorization code mode has two requests and two responses:

Authentication request + response
Access Token Request + response.

The authorization request

The authorization request is sent to the authentication server and an authorization code is obtained.

Response_type Mandatory (fixed value: "code") client_id Specifies the client ID. redirect_uri generated by the client application when the authentication server is registered. T Redirection URL entered when the client application registers with the authentication server scope Optional. Request permission scope State optional (recommended) The parameters in the request URL of the client application can be any values.Copy the code

Authorization response

The authorization response contains the authorization code that will be required to obtain the Access token later.

Code Mandatory. Authorization code returned by the authentication server State Specifies the value of this parameter if it exists in the request of the client application.Copy the code

Authorization error Response

There are two cases of misauthorization.

The client application fails to authenticate. For example, the redirection URL sent in the authorization request is different from the URL entered when the client application is registered with the authentication server.

Another error occurs, in which case the following error message is returned to the client application:

error Required. Must be one of a set of predefined error codes. See the specification for the codes and their meaning. error_description Optional. A human-readable UTF-8 encoded text describing the error. Intended for a developer, not an end user. error_uri Optional. A URI pointing to a human-readable web page with information about the error. state  Required, if present in authorization request. The same value as sent in the state parameter in the request.Copy the code

Token request

After obtaining the authorization code, the client application can use the authorization code to obtain the Access token. The request parameters are as follows:

client_id   Required. The client application's id.
client_secret   Required. The client application's client secret .
grant_type  Required. Must be set to authorization_code .
code    Required. The authorization code received by the authorization server.
redirect_uri    Required, if the request URI was included in the authorization request. Must be identical then.Copy the code

Token response

The access token response content is in JSON format:

{ "access_token" : "..." , "token_type" : "..." , "expires_in" : "..." , "refresh_token" : "..." ,}Copy the code

“Access_token” : access token, “token_type” : token type that is generally bearer, “expires_in” : token expiration time in seconds, “refresh_token” : when an access token fails, a new access token can be obtained with an update token

OAuth 2.0 simplified mode for request and response

Simplified mode has only one request and one response.

Simplified mode authorization request

The parameters of the request are as follows:

response_type   Required. Must be set to token .
client_id   Required. The client identifier as assigned by the authorization server, when the client was registered.
redirect_uri    Optional. The redirect URI registered by the client.
scope   Optional. The possible scope of the request.
state   Optional (recommended). Any client state that needs to be passed on to the client request URI.Copy the code

Simplified mode authorization response

The response contains the following parameters. Note that the format of the response is not JSON.

access_token Required. The access token assigned by the authorization server. token_type Required. The type of the token  expires_in Recommended. A number of seconds after which the access token expires. scope Optional. The scope of the access token. state Required, if present in the autorization request. Must be same value as state parameter in request.Copy the code

Simplified mode error response

The client application fails to authenticate. For example, the REdirection URL sent in the authorization request is different from the URL entered when the client application is registered with the authentication server.

Another error occurs, in which case the following error message is returned to the client application:

error Required. Must be one of a set of predefined error codes. See the specification for the codes and their meaning. error_description Optional. A human-readable UTF-8 encoded text describing the error. Intended for a developer, not an end user. error_uri Optional. A URI pointing to a human-readable web page with information about the error. state  Required, if present in authorization request. The same value as sent in the state parameter in the request.Copy the code

User password mode request and response

User password mode has only one request and response.

User password mode request

The request contains the following parameters:

Grant_type This parameter is mandatory. Fixed value "password" username Mandatory. Password Specifies the username in UTF-8 encoding. This parameter is mandatory. Utf-8 encoded password Scope Optional. The scope of permission requested.Copy the code

User password mode response

The response is in JSON format:

{ "access_token" : "..." , "token_type" : "..." , "expires_in" : "..." , "refresh_token" : "..." ,}Copy the code

“Access_token” : access token, “token_type” : token type, “expires_in” : token expiration time in seconds, “refresh_token” : when the access token becomes invalid, a new access token can be obtained with the updated token

Client mode request and response

Client mode request