My personal blog is blog.sqdyy.cn

The problem OAuth2 is trying to solve

Open inter-system authorization issues

OAuth2 was originally proposed based on the issue of open inter-system licensing, assuming that there was now a third-party application: a “cloud printing service” that could print out users’ photos stored at Google. To use the service, users have to let the Cloud Print service read their photos stored on Google. The problem is that Google will allow the Cloud printing service to read the photos only if the user gives permission. So “cloud printing service” how to obtain user authorization?

Method 1: Copy the password and user name

With traditional way, resource owner will own user name and password tell third party service, and then the third party service to read user protected resource, it is suitable for the use of internal application development, between the open system to do so is not suitable, because the third party service to follow-up service, will save the user’s password, it is not safe.

Method 2: master key

Another method is to negotiate a common developer key between the client application and the protected resource. The user obtains a developer key from the protected resource and gives it to the third-party application. The third-party application accesses the user’s protected resource through this developer key. This approach applies to situations where there is a trust relationship between the client application and the protected resource, for example, the two parties are partners, or the applications between different departments of the same company. But it’s also not appropriate for untrusted third-party applications.

Option 3: Special tokens

The third method is to use a special token, it only can access the protected resource, this kind of practice is relatively more on the former two methods, and OAuth2 already close to the fact, but how to manage the tokens, issued token, revoke the token is in need of some exquisite, those we leave behind to introduce OAuth2 again to get to know.

Security issues in modern microservices

In a traditional single-block application architecture, our single-block application is typically deployed in a cluster of application servers with a dedicated user database for processing login authorization. When a user accesses the application server, the application interceptor intercepts and authenticates the user. If the authentication succeeds, the server sends a Session ID to the client. The client stores the Session ID in a Cookie, and the server records the mapping between the Session ID and the authenticated user.

In contrast, traditional monolithic applications are primarily Web applications directly aimed at PC users. For modern microservices architectures, this does not apply. For modern microservice architecture, the granularity of separation between services is small, and the authentication between services needs to be considered. In addition, the forms of applications become diverse, such as single-page applications, wireless native apps, and server-side apps. In this scenario, we usually design a separate service, and make authentication and authorization into an AuthServer, and use tokens for authentication and authorization. This is also a major problem that OAuth2 solves, which we will discuss later.


Basic concepts of OAuth

OAuth2.0 is a delegated Authorization framework used for REST/APIs. Based on Token authorization, it enables applications to obtain limited access rights to user data without disclosing user passwords. Oauth2.0 can decouple authentication and authorization. It is the de facto standard security framework that supports a variety of application scenarios such as server-side WebApp, browser single page application SPA, wireless/native App, server to server invocation, and so on.

OAuth2.0 has the following advantages:

  • The client does not touch the user password, and the server is easier to centrally protect
  • Widespread and continued adoption
  • Supports short – lived and encapsulated tokens
  • The resource server and authorization server are decoupled
  • Centralized authorization, simplified client
  • HTTP/JSON friendly, easy to request and pass tokens
  • Consider multiple client architecture scenarios
  • Clients can have different levels of trust

Shortcomings of OAuth2.0:

  • The protocol framework is too broad, resulting in poor compatibility and interoperability of various implementations
  • Incompatible with OAuth1.0

OAuth:

  • OAuth does not support protocols other than HTTP.
  • OAuth is not an authentication protocol.
  • OAuth does not define an authorization processing mechanism.
  • OAuth does not define a Token type.
  • OAuth2.0 does not define encryption methods.
  • OAuth2.0 is not a single protocol.
  • OAuth2.0 is only an authorization framework and is only used to authorize agents.

OAuth Main roles and terms

  • Client Application: Usually a Web or wireless Application that needs to access the user’s protected resources.
  • Resource Server: A Web site or Web Service API where the user’s protected data is stored.
  • Authorized Server: Issues an Access Token to a client application after it has been successfully authenticated and Authorized.
  • Resource Owner: The Owner of a Resource who wants to share certain resources with a third party application.
  • Client Credentials: The clientId and password of the customer are used to authenticate the customer.
  • Tokens: The authorization server issues access Tokens after receiving a user request.
  • Scopes: When the client requests access to the token. Additional permissions specified by the resource owner

OAuth Indicates the token type

A Token is the core concept of OAuth2.0. A Token can be likened to a Valet Key, which gives an application limited access to the user’s data on behalf of the user.

  • Authorization Code Token: An Authorization type used only for Authorization codes. It is used to exchange access tokens and refresh tokens.
  • Refresh Token: Used to deauthorize the server to obtain a new Token.
  • Access Token: Used to directly Access a protected resource on behalf of a user or service.
  • Bearer Token: Whoever gets a Token can access resources.
  • Proof of Possession(Pop) Token: Checks whether the client has a clear Possession of the Token.

OAuth2 Authorization mode

Here’s how OAuth2.0 works:

  • (A) After the user opens the client, the client requests authorization from the user.
  • (B) The user agrees to authorize the client.
  • (C) The client uses the authorization obtained in the previous step to request a token from the authentication server.
  • (D) After the authentication server authenticates the client, it confirms the information and agrees to issue the token.
  • (E) The client uses the 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.

Step B here is the key, that is, how the client gives the authorization to the client. With this authorization, the client can obtain the token and then obtain the resource with the token. OAuth2.0 provides four modes for the client to obtain the authorization:

  • Authorization Code Mode
  • Implicit mode
  • Password Mode (Resource Owner Password Credentials)
  • Client Credentials Mode

Authorization code mode

Compared with the other three modes, the authorization code mode has the most complete functions and the most secure and rigorous procedures. It is characterized by the interaction between the back-end server of the client and the authentication server of the service provider:

The steps are as follows:

  • (A) The user accesses the client, and the client directs the user to the authentication server, which needs to carry the client ID credentials and the redirection URI.
  • (B) The user selects whether to grant authorization to the client.
  • (C) Assuming the user is authorized, the authentication server directs the user to a prespecified redirection URI along with an authorization code.
  • (D) After the client receives the authorization code, the backend server (invisible to the user) carries the specified redirection URI and authorization code to the authentication server to apply for the token.
  • (E) The authentication server verifies the authorization code and the redirection URI, and issues the Access token and refresh token to the client.

Simplify the model

Simplified mode does not use the server program to complete, compared to the authorization code mode to reduce the “authorization code” step, the browser directly sends the request to obtain the token, the token is visible to the visitor, and the client does not need to authenticate, this mode is generally used for single-page applications:

The steps are as follows:

  • (A) The user accesses the client, and the client directs the user to the authentication server, which needs to carry the client ID credentials and the redirection URI.
  • (B) The user selects whether to grant authorization to the client.
  • (C) Assuming the user is authorized, the authentication server directs the user to a prespecified redirection URI and includes an access token (Fragment) in the Hash section of the URI.
  • (D) The browser sends a request to the resource server, which does not contain the received Hash part (Fragment).
  • (E) The resource server returns a script containing code to retrieve the token in the Hash section.
  • (F) The browser executes the pre-obtained script and extracts the token
  • (G) The browser sends the token to the client.

Password mode

In password mode, the user provides the user name and password to the client, and the client uses the information to request authorization from the authentication server. This pattern runs counter to the aforementioned microservice security problem (not exposing usernames and passwords), but it can also be used in situations where users have a high degree of trust in the client, such as licensing between software within a company:

The steps are as follows:

  • (A) The user provides A 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 authentication server.
  • (C) After the authentication server confirms the error, it provides the access token to the client.

Client mode

In the client mode, the client applies for authorization token from the authorization server in its own name, but not in the full sense of authorization. It is mainly used in such scenarios where Docker pulls the image from DokcerHub:

The steps are as follows:

  • (A) The client authenticates its identity to the authentication server and asks for an access token.
  • (B) After the authentication server confirms the information, it provides the access token to the client.

The refresh token

If the client’s “access token” has expired by the time the user accesses it, a new access token needs to be requested using the “update token” :

The steps are as follows:

  • (A) The client authenticates its identity to the authentication server and asks for an access token.
  • (B) When the authentication server confirms that it is correct, it returns the access token and a refresh token.
  • (C) Clients access protected resources through access tokens.
  • (D) Provide resource services to the client if the access token has not expired.
  • (E) Clients access protected resources through access tokens.
  • (F) If the access Token expires, the protected resource server returns an Invalid Token Error.
  • (G) After receiving the error above, the client requests a new access token from the authorization server by refreshing the token.
  • (H) When the authentication server confirms that it is correct, it returns the access token and a refresh token.

Selection of four modes of OAuth2.0

The above four client authorization modes of Oauthare introduced. The technical selection of these four modes is introduced as follows. Before this, two concepts are laid down:

Channels: The interactions between the four primary roles of OAuth2 mentioned earlier can be divided into two types of channels, and the transmission interactions between the resource owner, the client application, and the authorization server can be divided into front-end channels. Any interaction that occurs between the authorization server, the client application, and the resource server can be classified as a back-end channel.

Type of customer application: Customer application can also be divided into two types of applications. The first type is public application, which mainly refers to single-page application SPA or native App application. These applications are located in the hands of the user. The second category is private applications, which mainly refer to Web server applications, services/apis (machine to machine), which are run in the back end, relatively secure overall, and can host user credentials information.

Features of the four OAuth2.0 authorization modes

Before selection, let’s summarize the characteristics of the four types of authorization:

Authorization code mode

  • Obtain authorization codes from front-end channel customers
  • Through the backend channel, customers use authorization codes to exchange access tokens and refresh tokens
  • Assume that the resource owner and customer are on different devices
  • The most secure process, because the token is not passed through the user-agent

Simplify the model

  • Suitable for public browser single page applications
  • Access tokens are returned directly from the authorization server (front-end channel only)
  • Refresh token is not supported
  • Assume that the resource owner and the exposed application are on the same application
  • Most vulnerable to security attacks

User name and password mode

  • Use the user name and password to log in to an application, such as a desktop App or internal software
  • Obtain the Access token from the authorization server using the user name and password as the authorization mode
  • Generally, refresh token is not supported
  • Assume that the resource owner and the exposed user are on the same device

Client mode

  • Suitable for communication between server manufacturers, confidential client on behalf of itself or a user
  • Only the back-end channel uses the client credentials to obtain an Access token
  • Because customer credentials can be encrypted symmetrically or asymmetrically, this method supports shared passwords or certificates

Authorization Mode selection

Based on the above, the following flow chart can be used for selection:

References for this article:

  • Actual combat 160 speak] [Yang Bo teacher micro service: time.geekbang.org/course/intr…
  • [understand the 2.0 nguyen other] : www.ruanyifeng.com/blog/2014/0…
  • Engineering: [login authentication technology of the traditional Web applications Chen section] : insights.thoughtworkers.org/traditional…