Basic introduction to Oauth2

OAuth2

1. What is OAuth2

OAuth 2.0 is currently the most popular authorization mechanism to authorize third-party applications and obtain user data.

OAuth (Open Authorization) is an open standard for authorization that allows users to authorize third-party mobile applications to access their information stored on another service provider (such as photos, videos, user information, etc.) without the need for usernames and passwords All content provided to third-party mobile applications or sharing their data, OAuth2.0 is a continuation of the OAuth protocol, but it is not backward compatible with OAuth 1.0. That is, OAuth1.0 is completely abolished. The OAuth 2.0 protocol was officially released as RFC-6749.

OAuth2 mainly includes the following features:

1. Proxy authorization framework for REST/APIs (delegated authorization framework)

2. Token-based authorization allows applications to obtain limited access to user data without revealing user passwords

3. Decouple authentication and authorization

4. The de facto standard security framework supports multiple use case scenarios

1. Server-side WebApp
2. Browser single page SPA
3. Wireless/Native App
4. Server-to-server oauth2

Second, the principle of OAuth2

Under normal circumstances, an application requests a resource server to access customer data. Without OAuth2, the resource server cannot distinguish whether the requested application is a malicious user or another user, and the data will be returned. As shown below:

Therefore, for users to safely access data, an Access Token mechanism is added in the middle of access. The client needs to carry the Access Token to access the protected resources.

OAuth2 is to let us use the authorization server to issue Access Token to the client application.

Finally, the client gets the Access Token to the resource server for verification, and the data is returned after the verification is passed.

The overall flow chart of OAuth2 is as follows:

flow chart

(A) The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown in the figure), or indirectly through the authorization server as an intermediary (the preferred solution).
(B) The resource owner allows authorization and returns the credentials (such as code).
(C) The client authenticates through the authorization server, provides authorization credentials (such as code), and requests an access token.
(D) The authorization server authenticates the client, verifies the authorization credentials, and if valid, issues an access token.
(E) The client requests the protected resource from the resource server and authenticates by providing an access token.
(F) The resource server verifies the access token and returns the protected resource if it is correct.

Simply put: the client application requests the Access Token from the authorization server —> the authorization server asks the user for comments, whether to grant the permission to the client application —> user consent —> the authorization server generates and issues Access Token to the client application —> the client application holds the Access Token Go to request the resource server —> the resource server verifies the Access Token of the client application —> the verification is passed and the data is returned

3. Roles and terms in OAuth2

There are four main roles in OAuth2, mainly as follows:

1. Resource Owner: The user, the resource owner, wants to share some resources to third-party applications
2. Resource Server (resource server): put protected resources, to access these resources, you need to obtain an access token
3. Authorization server (authorization (authentication) server): Authorization server is used to issue access tokens to clients
4. Client (client (third-party application)): The client represents a third-party program requesting resource server resources

Other terms in OAuth2:

1. Client Credentials: The clientId and password of the client are used to authenticate the client
2. Access Token: The access token issued by the authorization server after receiving the client request
3. Scopes: When a client requests an access token, the subdivision permissions (permissions) additionally specified by the resource owner
4. User Agent: User agent. Generally refers to the browser

Types of tokens in OAuth2:

1. Authorization Code Token (authorization code): only used for authorization code authorization type, used to exchange access tokens and refresh orders
2. Refresh Token: used to get a new access token from the authorization server
3. Access Token: used to directly access protected resources on behalf of a user or service
4. Proof of Possession (PoP) Token: It can verify whether the client has a clear ownership of the Token

Through the above introduction, we roughly summarized as follows:

The essence of OAuth lies in how to obtain tokens and how to use tokens.
OAuth is a delegation authorization protocol between systems.
OAuth provides a broad protocol framework. Specific security scenarios require customizing
OAuth to use proxy protocols to resolve password sharing issues. Pattern problem

Four, OAuth2's four authorization methods

It is not difficult to see from the running process that to obtain an access token, you must first obtain user authorization (authorzation grant), so what if you obtain such user authorization? OAuth 2.0 defines four types of authorization types

1. Authorization code mode (authorization code)
2. Simplified mode (implicit)
3. Password mode (resource owner password credentials)
4. Client credentials

1. Authorization code mode (authorization code)

The authorization code mode is the most complete, widely used, and most rigorous authorization mode.

The authorization code method means that a third-party application first applies for an authorization code, and then uses the code to obtain a token.

The first step: the user visits the client, the client directs the user to the authorization server, and sends the client identifier, the scope of the request, the local state and a redirection URI through the user agent (User-Agent), and the authorization server is granting (Or deny) access and send it to the user agent. The URI is as follows:

http://localhost:8080/oauth/authorize?client_id=clientapp&redirect_uri=http://localhost:9001/callback&response_type=code&scope=read_userinfo

In the URI, the response_type parameter indicates the request to return the authorization code (code), the client_id parameter lets the authorization server know who is requesting, the redirect_uri parameter is the redirect URL after the authorization server accepts or rejects the request, and the scope parameter indicates the requested authorization scope (here is Read only).

Step 2: The authorization server authenticates the resource owner (through the user agent, the user enters the user name and password), and determines whether the resource owner grants or denies the client's access request.

Step 3: After the user is redirected, if the resource owner agrees to the authorization request, the authorization server will use the redirection URI provided earlier or specified in advance to redirect to the client and attach an authorization code (Code) and a previously provided local state (state) (if any, the original value is returned).

http://localhost:9001/callback?code=ghN0hf

Step 4: The client receives the authorization code, attaches the previous redirect URI, and applies for a token from the authorization server. This step is done on the server in the background of the client and is not visible to the user. When making a request, the authorization server authenticates the client. The request parameters include the authorization code, the redirect URI of the authorization code used to obtain authentication, the client id and the client secret that identify the client's identity.

 http://localhost:8080/oauth/token?client_id=clientapp&client_secret=123&code=ghN0hF&grant_type=authorization_code&redirect_uri=http://localhost:9001/callback&scope=read_userinfo

Note: User keys and passwords can be added to the headers for authentication and authorization.

In the above URL, the client_id and client_secret parameters are used to allow the authorization server to confirm the identity of the client (the client_secret parameter is confidential, so requests can only be sent on the backend), and the value of the grant_type parameter is authorization_code, indicating that the authorization method used 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 5: The authorization server authenticates the client, verifies the authorization code, and ensures that the received redirect URI matches the URI used to redirect the client in step ©. If valid, the authorization server will send Access token and refresh token (optional).

Then the authorization server returns the authorization code to us, as follows:

{
    
    
    "access_token": "36cded80-b6f5-43b7-bdfc-594788a24530",
    "token_type": "bearer",
    "expires_in": 43199,
    "refresh_token":"45cdce99-b6f5-8866-bdfc-764745a45780",
    "scope": "read_userinfo"
}

The main parameters here are:

access_token: Represents an access token. required.
token_type: indicates the token type. The value is case-insensitive, it is a required option, and can be bearer or mac.
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 refresh token. Optional, used to get the next access token.
scope: Indicates the scope of authority. Optional, if it is consistent with the scope of the client application, this item can be omitted.

Finally, we get the access_token to access the protected resources, as follows:

http://localhost:8080/api/userinfo?access_token=f4345f3a-34a3-4887-bc02-e95150c54bf4

2. Simplified mode (implicit)

Simplified mode (implicit grant type) does not go through the server of a third-party application, and directly applies for a token from the authentication server in the browser, skipping the "authorization code" step, hence the name. All steps are completed in the browser, the token is visible to visitors, and the client does not need to be authenticated.

The first step: the user visits the client, the client directs the user to the authorization server, and sends the client identifier, the scope of the request, the local state and a redirection URI through the user agent (User-Agent), and the authorization server is granting (Or deny) access and send it to the user agent. The URI is as follows:

http://localhost:8080/oauth/authorize?client_id=clientapp&redirect_uri=http://localhost:9001/callback&response_type=token&scope=admin&state=abc

This step is to directly apply for an authorization token. The parameters are similar to the application authorization code. The client_id, redirect_uri callback address, and response_type have been changed. Instead, obtain the token and scope permissions directly. The state is used for authentication marks, and what is returned when the callback is passed.

Step 2: The authorization server authenticates the resource owner (through the user agent, the user enters the user name and password), and determines whether the resource owner grants or denies the client's access request.

Step 3: After the user is redirected, if the resource owner agrees to the authorization request, the authorization server will use the redirection URI provided earlier or specified in advance to redirect to the client and attach the access token And other information. as follows:

http://localhost:9001/callback#access_token=0406040a-779e-4b5e-adf1-bf2f02031e83&token_type=bearer&state=abc&expires_in=119

In the same way, we can access protected resources when we get the access_token.

http://localhost:8080/api/userinfo?access_token=0406040a-779e-4b5e-adf1-bf2f02031e83

3. Password mode (resource owner password credentials)

In the password mode, the user provides his user name and password to the client. The client uses this information to request authorization from the "service provider".

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 degree of trust in the client, such as the client is part of the operating system or produced by a well-known company. The authentication server can only consider using this mode when other authorization modes cannot be implemented.

The first step: the user accesses the client, the client directs the user to the authorization server, and then provides the URI connection containing the user name and password information to the authorization server. as follows:

Note: User keys and passwords (client_id and client_secret) can be added to the headers for authentication and authorization.

Step 2: After the authorization server authenticates the user name and password information, it returns the client access_token and other information, as follows:

{
    
    
    "access_token": "58a02fd5-87f5-44ff-bbdd-d429cf6a2f60",
    "refresh_token":"45cdce99-b6f5-8866-bdfc-dtfsdft55780",
    "token_type": "bearer",
    "expires_in": 43199,
    "scope": "admin"
}

In the same way, we can access the resources we need to access by getting the access_token.

4. Client credentials

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

Step 1: The client directly initiates an authentication request to the authorization server. The URI is as follows:

 http://localhost:8080/oauth/token?client_id=clientapp&client_secret=123&grant_type=client_credentials&scope=admin

Note: User keys and passwords (client_id and client_secret) can also be added to the headers for authentication and authorization.

Step 2: After the authorization server passes the authentication, it directly returns the client access_token and other information, as follows:

{
    
    
    "access_token": "776b162a-949e-4dcb-b16b-9985e8171dc0",
    "refresh_token":"46ffdtfa-b6f5-8866-bdfc-dtfsdft55780",
    "token_type": "bearer",
    "expires_in": 43188,
    "scope": "devops"
}

Finally, we get the access_token to access related resources.