[TOC]

A, the opening

The Spring OAuth2 Development Guide is a series of articles detailing OAuth2 development based on the Spring ecosystem (including Spring Cloud). This series will consist of five articles:

  1. (1) Architecture and development overview: It is the beginning of a series of articles, mainly combing and analyzing the architecture and main process of OAuth2, and making a general and global introduction to the current development of Spring OAuth2;
  2. (2) OAuth2 password mode development example
  3. (3) OAuth2 client mode development example
  4. (4) OAuth2 authorization code mode development example
  5. (5) OAuth2 microservice scenario example development: Taking password mode as an example, this paper introduces the key technologies and methods of using OAuth2 and integrating JWT in microservice scenario, mainly focusing on client, microservice gateway and authentication and authorization service, excluding other modules of microservice.

The first part of this series mainly focuses on the concept of OAuth2 system, while the other parts are more practical, mainly realizing three authorization modes of OAuth2: password mode, client mode and authorization code mode, including the interaction of authorization server, resource server, client and other roles, as well as the integration of JWT. And each instance provides two code versions: one based on the old Spring Security OAuth2 component; One is based on the new Spring Authorization Server component.

It is important to note the password mode because OAuth2.1 not recommended so can only provide the old component code version, specific see datatracker.ietf.org/doc/html/dr…

If you are interested in the theory of authentication and authorization platforms, you can refer to my two earlier articles:

  1. SaaS platform level architecture: the basis of unified identity management system, www.jianshu.com/p/990d8acfd…
  2. Micro service architecture of the unified identity authentication and authorization, www.jianshu.com/p/2571f6a4e…

Second, OAuth2 architecture

OAuth authorization system was designed primarily to solve the problem of third-party application login and authorization at the beginning, but due to its strict and standardized process definition, wide authorization universality, and is independent of specific technology platform and many other advantages, it has gradually developed into the mainstream technical specifications in the field of authentication and authorization. However, the OAuth2 specification is not complicated to summarize, with only four main authorization modes and five roles.

The four authorization modes are as follows:

  1. Authorization Code
  2. Simplified patterns (Implicit)
  3. Password mode (Resource owner Password Credentials)
  4. Client credentials

The five main roles are:

  1. User Agent/browser User Agent
  2. The Client Client
  3. Resource Owner Resource Owner
  4. Resource Server Resource Server
  5. Authorization Server Authorization Server

It is suggested to master the above concepts and clarify the relationship, which is helpful to have an overall understanding of the whole system. If you start coding, you’re going to end up with an unhealthy system. An IDENTITY management system is an essential part of any platform’s infrastructure, and if it is not built securely, it will be like a delayed bomb planted in the foundation of a building.

Back to the theme, each of the four modes has its own specific usage scenarios, but in the implementation process, you can choose according to the actual situation. For the convenience of the following introduction, we assume two sets of demonstration cases: IBCS (Image-based Classification System) and PAPS (Photo Album Preview System).

Why assume two sets? The purpose is to analyze and compare the application scenarios of various authorization modes.

Scenario Hypothesis A: IBCS (Image-based Classification System)

Assume that the team is developing a set of “Image-based Classification System”. The System uses RESTful API to interact externally, and its main function is to allow users to upload pictures through H5 application or APP. After system analysis, the classification result is returned. To demonstrate the entire process of OAuth2 system authentication, authorization, authentication, and permission control, we constructed a minimal IBCS demo project:

The service name category describe Technology selection
ibc-service Internal service Resource server role, image classification service RESTful service developed by Spring Boot
idp Internal service The role of the authorization server, which is responsible for authentication, authorization, and authentication Spring Boot development
demo-h5 External application Front-end of demo applications Antd – Pro development
demo-service External application Back-end of the Demo application Spring Boot development

A demo application is designed here. For IBCS, a Demo application is an external application and a consumer, including front-end Demo-H5 and back-end Demo-Service. However, in the whole demo project, ibc-service, IDP, Demo-h5, and Demo-service are all their own applications and trust each other.

It’s worth noting that in the real world, there are two types of applications: server-side applications; The other is a serverless application. The former is easier to understand. It can be a single MVC application with a separate front and back end, or a RESTFUL front and back end application, which are common development structures. In addition, there are some apps that have no or no backend, such as SinglePage H5, a simple H5 developed by Vue or React. The entire application consists of JavaScript code, and the front end is the whole application. One of the biggest security issues for this type of application is how client_secret is stored securely. Neither the classic authorization mode nor the password mode can effectively solve this problem in a serverless scenario, because a program written entirely in JavaScript is completely transparent in nature. Client_secret is at risk of disclosure. Client_secret will cause the client to be forged, that is, an attacker will forge an App after obtaining client_ID and client_secret to make a fake request. Of course, many platforms will add redirect_URI binding or IP/ domain name whitelist mechanism on the IDP side to effectively reduce security risks such as forgery/hijacking.

It is wrong to say that the PKCE (Proof Key for Code Exchange by OAuth Public Clients) protocol proposed by the OAuth 2.0 specification solves this problem. PKCE does not solve the risk of client_secret disclosure technically, so it is best not to use serverless mode when security requirements are high. However, PKCE as an enhanced protocol can be used in combination with OAuth2 to improve overall security. The main process is as follows: Generated by “front end” itself exposed a string of random authentication code, again according to the verification code generated challenge code, and then use the challenge code request authorization code to the license server, authorization server save challenge code return authorization code to the “front end”, “front end” after obtaining authorization code with the first step to generate random authentication code + authorization code apply to the license server tokens, After obtaining the verification code and authorization code, the authorization server generates a challenge code based on the verification code. If the generated challenge code is the same as the one saved in the previous step, the authorization server issues a token. Interested students can consult relevant information by themselves.

Scenario HYPOTHESIS B: Photo Album Preview System (PAPS)

PAPS is a subsystem of a social platform. Similar to IBCS, PAPS uses RESTful API to interact with the outside world. Its main function is to allow users to preview their albums.

The service name category describe Technology selection
photo-service Internal service Resource server role, album preview service RESTful service developed by Spring Boot
idp Internal service The role of the authorization server, which is responsible for authentication, authorization, and authentication Spring Boot development
demo-h5 External application Front-end of demo applications Antd – Pro development
demo-service External application Back-end of the Demo application Spring Boot development

The only difference between the two demo cases is the core service, one is the image classification service and the other is the album preview service. While this may seem like no difference, their business models are actually quite different, which we’ll look at next.

Authorization code mode vs password mode vs client mode

Consider how to choose the authorization code mode, password mode and client mode in different business scenarios.

There are two ways to do this:

  1. No matter whether it is 30, 70 or 20, the whole project only uses one authorization mode, simple and clear;
  2. Carefully analyze various business scenarios and give appropriate model selection.

The first approach, simple and crude, may seem undesirable, but it should not be killed outright, depending on the business model, design objectives and specific requirements of the project. But for the sake of scientific rigor or technical research, the second approach is surely preferable. Next, we will expand with the second approach, and analyze the problem of mode selection in detail.

Authorization code mode and password mode

We’ll look at comparison between authorization code mode and password mode, as we all know, authorization code is the highest OAuth2 system security model, compared with password mode, the main difference is less a layer of the user to confirm the authorization, the lack of this action leads to authorize stage, users need to put the user name password to inform the client, This causes potential password leakage risks. Let’s look at the comparison:

Comparative study Authorization code mode Password mode
Applicable scenario Untrusted/third party authentication and authorization, trusted/internal service authentication and authorization Trusted/internal service authentication and authorization
The development of the difficulty More complicated Relatively simple
security The highest It is safe as long as it is not used in untrusted/third party scenarios

Here, the trusted/internal service scenario is defined as a relative concept, referring to applications and services that are part of the same OAuth2 architecture and are developed by the same or trusted team, also known as first-party applications. For example, the B2C mall system under the microservice architecture basically consists of front-end H5, wireless APP, API gateway, authentication and authorization service, order service, commodity service, etc. Since all the above components belong to the same OAuth2 system and are developed by the same team, Then they all belong to the trusted/internal service scenario.

So why is it relative? We focus on the Angle of the whole mall system, there is no doubt that the gateway to border security, certificate authority within the gateway service, order service, goods and services belong to the internal services, while the front-end H5, wireless terminal APP belongs to the external application, if the external applications are other team development, we can also define them for third party applications. In this way, the gateway is the boundary between internal and external services, which is called the relative concept.

Then, what is the difference between the authorization code mode and the password mode in the authentication and authorization stage of the front-end H5 and wireless APP of the e-commerce system? The authorization code pattern provides almost the same security flow, except that there is a layer of user confirmation of authorization actions to avoid disclosing user names and passwords to third-party applications. Isn’t the third party application referred to here the front-end H5 and wireless APP? Are their own development of the application, is naturally credible, so there is no need to worry about the risk of leakage.

From this point of view, the security of the two modes is even under the limits of the above conditions. Follow the “principle of simplicity” and use the password mode, of course, students who like challenging complexity can choose the authorization code mode.

But also not to say that the authorization code model can be replaced by password mode, main application scenario for the authorization code mode, is in the third party/untrusted application login and authorization, mainly to solve without disclosing how users password security authorization one application to another application provides the user resources problems, for instance, The authorization code pattern is particularly suitable for scenarios where a third-party application (client) needs to obtain the user data (resource) of a user (resource owner) on another untrusted application (resource server).

To sum up, the choice between authorization code mode and password mode depends on the service scenario. The key decision point is whether applications or services trust each other.

Client mode

Which authorization mode should PAPS Album Preview demo use?

Before you answer this question, consider the following question: what does PAPS refer to as a resource owner?

The first is to define what a resource is, the second is that the resource is protected, and the last is who owns the resource. In PAPS, it is obvious that the protected resource is the user’s photo album, and the owner of the resource is naturally the user himself.

After the definition of the resource owner is made clear, and based on the above analysis, there is no doubt that if the PAPS Demo application is an untrusted application of a third party, the authorization code mode should be adopted. If you’re a first-party trusted application, you can use password mode, or you can go to the trouble of using authorization code mode.

Next, we will analyze the pattern used in the IBCS picture classification system demonstration case.

Again, before answering this question, consider: what is the object of resource owner in IBCS?

First, the object to which the resource owner refers is not immutable. In the IBCS demo case, the demo application sends an image to the IBC-Service and expects to return the classification result. What are the protected resources in this case? Unlike PAPS album preview service, which has a physical resource concept, its protected resource is the user’s album, while IBCS is difficult to abstract a physical resource.

It can be understood that the core capability provided by IBCS is the image classification algorithm, which is its protected resource. The owner of the image classification algorithm is obviously the entity organization or person that owns the algorithm, and therefore the resource owner is the entity organization or person that owns the algorithm. Take password mode for example. According to OAuth2’s design, the resource owner provides the user name and password to the client, and the client requests the token from the authorization server with client_id and client_secret, together with the user name and password. The owner of the resource here is an ordinary user of the IBCS, but as stated earlier, the owner of the resource should be an entity or individual holding the image classification algorithm. Isn’t that a contradiction?

Therefore, from the perspective of the resource owner, the AUTHORIZATION code pattern is not suitable for the IBCS demo case, and the password pattern is not suitable for the client pattern. The IBCS does not have user resources. The authorization code mode and password mode require user authorization. The resources and services provided by IBCS do not belong to users, so user authorization is not required.

The above is an analysis model for choosing the authorization mode, starting from the resource owner dimension. To sum up:

case scenario Suitable for model
IBCS image classification system case study Trusted/internal services Client mode
IBCS image classification system case study Untrusted/external applications Client mode
PAPS album preview system case Trusted/internal services Password mode
PAPS album preview system case Untrusted/external applications Authorization code mode

In fact, the specific reference to the resource owner is not an important aspect of the actual development, the key is that developers have their own understanding and can use flexibly. As an aside, although OAuth2 is the authority in today’s field, we should not blindly believe in authority unconditionally. The development of technology is bound to have loopholes and imperfections.

Typical architectural hierarchies and major flows for cryptographic patterns

We take PAPS album preview system as an example to introduce the architecture level and main flow of password mode.

This is the minimal architectural level of the cryptographic pattern, as shown in the figure, and can be used as a basis for expansion in real life development. Password mode involves five main roles, plus one user agent/browser role:

  1. User agent/browser: Generally, single applications are MVC structures separated from the front and back ends. From this point of view, user agent/browser can be specifically understood as the FRONT-END H5 application or wireless APP. In other words, H5/APP becomes user agent by carrying user interaction. Specific to PAPS demo case is Demo-H5;
  2. Client: refers to the back-end service of a single application. Demo-service is the specific example of PAPS.
  3. Authorization server: The AUTHENTICATION Provider (IDP) is responsible for authentication, authorization, and authentication. It is also the core service of OAuth2 system, or auth-Service. The specific PAPS demonstration case is IDP;
  4. Protected resource: resource server, generally internal services, such as product services, order services, etc. The specific PAPS demo case is photo-service;
  5. Resource owner: As the name implies, the owner of the protected resource, usually referring to the user himself. The specific PAPS demo case is the user.

The whole process is divided into two stages:

  • Phase 1: Authentication and authorization phase
  1. The user agent (Demo-h5) sends the user name and password entered by the user to the client (demo-service).
  2. The client (demo-service) sends the user name and password entered by the user together with client_id + client_secret (assigned by IDP) to idP to request the token. If SCOPE is specified by IDP, scope parameter is required.
  3. Idp first verifies the validity of client_id + client_secret, then checks whether scope is correct, and finally verifies that the user name and password are correct. If they are correct, the token is generated. This step is also called “authentication”;
  4. The IDP returns the authentication result to the client. If the authentication succeeds, the TOKEN is returned. If the authentication fails, 401 is returned. If the authentication succeeds, this step is also called “authorization”.
  5. After receiving the token, the client stores the token temporarily and creates a corresponding session.
  6. The client issues cookies to the user agent/browser.

At this point, the authentication and authorization phase is complete. There are other session schemes in Steps 5-6. For example, A REST application may store tokens in the browser, but session/cookie is undoubtedly the safest choice.

In a typical Web application, you can think of this phase as a user login process.

  • Phase 2: Request resources after authorization
  1. The user accesses the My Album page through the user agent (Demo-h5). The user agent sends a request to the client (Demo-service) with cookies.
  2. The client finds the corresponding token through the session and carries the token to send a request to the resource server (photo-service).
  3. The resource server (photo-service) requests the IDP to verify the token validity;
  4. Idp verifies the validity of the token, checks whether the client (Demo-service) has the permission to invoke the API based on scope, and returns the verification result to the resource server. This step is also called “authentication”;
  5. The resource server decides whether to return user album data to the client based on the IDP check (true/false or equivalent). If the token check fails, 401 is returned to the client. If the scope check fails, 403 is returned. This step is also called “permission control”.

At this point, the post-authorization request resource phase is complete.

In fact, the scope parameter is not the core content, and can even be ignored in practical work to simplify the development steps. The scope parameter is used to constrain client permissions, as opposed to the authorities. For example, scope parameter can be used in IDP to constrain a client to only initiate read (GET) requests, or to only call several specified APIS, etc. The specific business logic can be written by itself.

Microservices architecture levels and major processes for cryptographic patterns

We still take PAPS album preview system as an example to introduce the architecture level and main process of password mode in micro-service scenario.

In the microservice scenario, a gateway is added, which is actually a reverse proxy that forwards user requests to the internal server. Similarly, the microservices scenario is divided into two phases, and the first phase is unchanged, with the main difference being the second phase:

  1. The user accesses the My Album page through the user agent (Demo-h5). The user agent sends a request to the client (Demo-service) with cookies.
  2. The client finds the corresponding token through the session and carries the token to the gateway to initiate a request to the resource server (photo-service).
  3. The gateway intercepts the token and, together with the details of the request, requests verification from IDP.
  4. Idp verifies the validity of the token, determines whether the client (Demo-service) has the permission to call the API based on scope and request details, and returns the verification result to the gateway. If all the checks pass, IDP generates JWT and returns it to the gateway. Return 401 if token verification fails. Return 403 if scope check fails;
  5. If the verification passes, the gateway will get the JWT and forward the request to the resource server with the JWT.
  6. The resource server parses JWT to obtain user information, queries user album data and returns it to the gateway.
  7. The gateway returns the user album data to the client.

There are two major changes to this process: the addition of a gateway makes the process a little more complicated; The other is to use JWT as a token within the gateway. There is no further explanation of these two points in this article. Those who are interested can refer to my earlier article “Unified Identity authentication and Authorization under microservices architecture”.

It is worth noting that there is another way to handle steps 9-11, which is to put the scope client permission check into the gateway:

  1. After intercepting the token, the gateway requests the IDP for verification.
  2. Idp verifies the validity of token. After verification, user information and scope are queried based on token, and JWT is generated and returned to the gateway. If it doesn’t pass, return 401;
  3. The gateway gets the JWT and determines whether the client has the permission to call this API according to scope after parsing. If so, it carries the JWT forward request to the resource server; otherwise, 403 is returned to the client.

If the client permission check is placed on the gateway, the gateway maintains the logic of scope and client permission.

Client-side pattern of microservices architecture hierarchies and major processes

We take IBCS picture classification system as an example to introduce the architecture level and main process of client mode in microservice scenario.

As you can see, the client mode process is relatively simple and I won’t go into details here, but note step 2:

  1. Before a client requests a token from idP, it should check whether a valid token is cached and skip to step 6 to initiate a service access request.

Microservice architecture hierarchy and main flow of authorization code pattern

Taking PAPS album preview system as an example, we introduce the architecture level and main process of authorization code mode in micro-service scenario.

The whole process is divided into two stages:

  • Phase 1: Authentication and authorization phase
  1. The user clicks the login button at the user agent (Demo-h5), or requests authorization to log in. This operation accesses a URI of the client.
  2. The demo-service client directs the user to the authentication and authorization page provided by IDP, and carries client_id, response_type=code, redirecT_URI (optional), scope (optional), and state (optional) in ULR parameters of the page.
  3. A user can select whether to grant authorization on the AUTHENTICATION and authorization page of the IDP by using the user agent (Demo-h5). If the user does not log in to the IDP, the user needs to log in first and then perform operations.
  4. The user gives authorization, idP directs the user to the page specified by redirect_URI, and attaches authorization code (code); If redirect_URI is not specified, it directs to the URI at the time the request is made, along with an authorization code.
  5. After receiving the authorization code, the client initiates a token request to IDP with client_ID (required) + client_secret (required) + state (if any) + scope (if any) attached. Note that this step is initiated by the client in the background and cannot be sensed by the user.
  6. After receiving the request, IDP first checks whether client_ID + client_secret + scope (if any) is correct, then verifies the authorization code and issues the token to the client.
  • Phase 2: Request resources after authorization

The process in this phase is the same as that in the microservice scenario in password mode and is not described here.

For restful Demo applications

If the demo application is a REST application, you can also do this in steps 1 and 2:

  1. After the user clicks the login button or the request for authorized login button at the user agent (Demo-h5), the demo-service will be notified to the client (Demo-service). After receiving the notification, the client will return the instruction of redirection, scope (optional), state (optional), etc.
  2. After receiving the response, Demo-h5 directly directs the user to the authentication and authorization page provided by IDP, and carries the parameters returned by the client in the URL parameters of the page (except the state parameter, other parameters can be written out in Demo-h5) client_id. Response_type =code, redirect_URI (mandatory), scope (optional), state (optional), where the redirect_URI recommendation is mandatory and must be the URI (callback address) provided by the client.

It can also be handled like this:

  1. After a user clicks the login button or request authorization login button at the user agent (Demo-h5), the user is directly directed to the authentication and authorization page provided by IDP, and the URL parameter of the page contains client_id, response_type=code, redirect_uri (mandatory). Scope (optional), but does not need to carry the state argument because the client is unaware of its existence, where the redirect_URI suggestion is mandatory and must be the URI (callback address) provided by the client.

At this point, the authentication and authorization process in authorization code mode is complete.

Discussion: Does IDP need to authenticate the client when the client first directs the user to the authentication and authorization page provided by IDP? Or should I provide client_secret?

Load issues with the microservice gateway

In micro service scenario, a large number of requests and responses are gateway forwarding, we imagine, if similar PAPS photo system, returns the image data, and do not use the CDN distributed technology such as network or file storage service, then the image flow through the gateway again returned to the user, the gateway will be a huge load?

Of course, the gateway itself can do load balancing, can introduce cache, data flow can do CDN processing, etc., these are very good high-performance solutions, in addition, is there any other way?

Here we introduce a concept in the field of network technology — there are three modes of load balancing: reverse proxy, transparent mode and triangle mode. Here is a brief introduction to the triangle mode:

Consider a network structure that includes Web servers, PC clients, and load balancers. The PC initiates access to the Web server through a load balancer. The access flow in triangle mode is as follows:

  1. The PC sends a request to the load balancer to access the Web server.
  2. The load balancer forwards the PC’s requests to the Web server;
  3. After receiving the request, the Web server directly sends the response data to the PC.

The PC, Web server, and load balancer are triangular in shape, hence the triangular pattern. The advantage of this mode is that the load balancer is only responsible for forwarding requests, and the response packet does not need to be received and forwarded, thus reducing the load balancer’s own data flow pressure. Triangle mode is also similar to THE DR mode of LVS in that the LVS scheduler only receives and forwards requests, and the real packets returned by the cluster server at the back end are sent directly to the requesting client.

According to this idea, we can introduce triangle mode into the gateway, so that the chief officer can reduce the load pressure of the gateway.

Token reuse issues

We imagine a scenario where the platform developed by the team includes both IBCS image classification service and PAPS album preview service. After logging in to the platform (authenticated and authorized by password mode), the user first visits “my album” and then selects a photo from it to initiate a request for item identification.

According to the pattern selection analysis of the article, IBCS service should adopt client mode and PAPS service should adopt password mode. Then, should the client apply for two sets of tokens?

To answer this question, let’s start with a specific scenario:

  1. If the user needs to log in to the platform to use the IBCS and PAPS services, then only the password mode token is needed.
  2. If the PAPS function does not require login and visitors can use it, password mode and client mode should be handled separately.

The authorization code mode is the most strict, followed by the password mode, and the client mode is the worst. Therefore, the authorization code mode token can be used by other modes, and the password mode token can be used by the client mode, but the client mode can only be used by itself.

An overview of OAuth2 components in the Spring family

All right, from this point on we’re going to move away from the boring theory and into the equally boring field development channel.

Currently, there are three ways to build the OAuth2 licensing system: one is to build based on mainstream open source components; Second, access third-party authorization services (such as Google and GitHub OAuth2); Third, according to OAuth2 standard specifications to develop their own authorization components.

Common open source components include RedHat Keycloak, Spring Security, Spring Security OAuth2, and the fledgling Spring Authorization Server. It’s worth mentioning RedHat Keycloak, which is an open source, mature IAM solution that is powerful and privately-deployable.

In the development ecology of Spring, it is suggested to adopt the open source component scheme in the direction of Spring Security, which has good scalability, strong customization, extensive users and active community.

Spring Security OAuth2 has stopped updating and is officially not recommended. Related functionality has been migrated to Spring Security, but Authorization Server functionality is not included. The Authorization Server function will be provided by the Spring Authorization Server open source component developed by the Spring Security team. For details, please check the official announcement: Spring. IO /blog/2020/0…

Spring Authorization Server project is still in iteration, the project development plan on the ZenHub custody, interested students can understand: app.zenhub.com/workspaces/…

A) Based on Spring Framework

  • spring-security

The core component that almost all current Spring OAuth2 open source technology solutions rely on. Core module: Spring-security-core.

<dependencies> <! -... other dependency elements ... --> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-web</artifactId> < version > 5.5.1 < / version > < / dependency > < the dependency > < groupId > org. Springframework. Security < / groupId > The < artifactId > spring ws-security - config < / artifactId > < version > 5.5.1 < / version > < / dependency > < / dependencies >Copy the code
  • [Stopped updating] spring-security-oauth2

Rely on Spring-Security. This component is now incorporated into Spring-Security and is no longer officially recommended. Previously, it was the only widely used component officially maintained by the Spring Security team.

<! -- https://mvnrepository.com/artifact/org.springframework.security.oauth/spring-security-oauth2 --> <dependency> <groupId>org.springframework.security.oauth</groupId> <artifactId>spring-security-oauth2</artifactId> < version > 2.5.1. RELEASE < / version > < / dependency >Copy the code
  • spring-security-oauth2-authorization-server

Rely on Spring-Security. After Spring Security officially announced the discontinuation of the Spring-Security-OAuth2 component update, a replacement component for the Authorization Server was launched. Spring-security integration with Spring-Security-OAuth2 does not include Authorization Server functionality, so if this functionality needs to be developed, It is used with spring-security-OAUTH2-authorization-server.

<! -- https://mvnrepository.com/artifact/org.springframework.security.experimental/spring-security-oauth2-authorization-server  --> <dependency> <groupId>org.springframework.security.experimental</groupId> < artifactId > spring ws-security - oauth2 authorization - server < / artifactId > < version > 0.1.2 < / version > < / dependency >Copy the code

2) Based on Spring Boot

  • spring-boot-starter-security

Rely on Spring-Security. Is equivalent to the spring – the boot + spring ws-security, default includes SecurityAutoConfiguration. Class, thus will perform some automation configuration, can simplify the development steps. If you want to shut down automatically configure, you can modify the Spring Boot startup annotations for @ SpringBootApplication (exclude = {SecurityAutoConfiguration. Class})

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>
Copy the code

3) Based on Spring Cloud

  • spring-cloud-starter-oauth2

It relies on spring-boot-starter-Security + spring-security-oauth2, and provides many additional functions, which is more practical in microservice scenarios.

<dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Hoxton.SR12</version> <type>pom</type> <scope>import</scope>  </dependency> </dependencies> </dependencyManagement> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-oauth2</artifactId> </dependency>Copy the code

Selection of core components

The optimal solution is spring-boot-starter-security + spring-authorization-server

Since spring-security-oAuth2 has been migrated to spring-security, and spring-boot-starter-security integrates spring-Security with many simplified configurations, It is especially good for building spring-boot programs. As of August 2021, the latest version of Spring-authorization-Server is 0.1.2. Please check the official dynamic spring. IO /blog/2020/0…

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <! -- https://mvnrepository.com/artifact/org.springframework.security.experimental/spring-security-oauth2-authorization-server  --> <dependency> <groupId>org.springframework.security.experimental</groupId> < artifactId > spring ws-security - oauth2 authorization - server < / artifactId > < version > 0.1.2 < / version > < / dependency >Copy the code

Spring Authorization Server projects comply with the OAuth2.1 specification and do not support the Password pattern, so projects that need to use this pattern can consider alternatives.

App.zenhub.com/workspaces/…

Alternatives: Spring-security-oAuth2 or spring-Cloud-starter-oAuth2

This solution uses Spring-security-oauth2, which has been officially stopped updating by Sprnig Security and is therefore no longer recommended. Also note that spring-security-oauth2 2.4.0.RELEASE and later will indicate deprecated.

  • If spring-security-oauth2 is used, then the POM reference is as follows:
<! -- https://mvnrepository.com/artifact/org.springframework.security.oauth/spring-security-oauth2 --> <dependency> <groupId>org.springframework.security.oauth</groupId> <artifactId>spring-security-oauth2</artifactId> The < version > 2.3.8. RELEASE < / version > < / dependency > <! -- https://mvnrepository.com/artifact/org.springframework.security.oauth.boot/spring-security-oauth2-autoconfigure --> <dependency> <groupId>org.springframework.security.oauth.boot</groupId> < artifactId > spring ws-security - oauth2 - autoconfigure < / artifactId > < version > 2.1.2. RELEASE < / version > < / dependency > <! -- Spring-security-oauth2-autoconfigure 2.1.3.RELEASE and later will indicate deprecated.Copy the code
  • Or spring-cloud-starter-oauth2, the POM reference is as follows:

Spring-cloud-starter-oauth2 integrates spring-Security-OAuth2 with many simplified configurations and has been one of the main solutions for building OAuth2 based on open source software for a long time.

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-oauth2</artifactId>
</dependency>
Copy the code