Solve the single sign-on (SSO) problem after Spring Boot upgraded from 1.x to 2.x

Solve the single sign-on (SSO) problem after Spring Boot upgraded from 1.x to 2.x

When learning Spring Cloud, when encountering the related content of authorized service oauth, he always knows half of it, so he decided to study and collate the content, principle and design of Spring Security, Spring Security Oauth2 and other permissions, authentication-related content. This series of articles is written to enhance the impression and understanding in the process of learning. If there is any infringement, please let me know.

Project environment:

JDK1.8

Spring boot 2.x

Spring Security 5.x

Previously, Spring Security related content has almost been written, so I recently sorted out Spring Sexuality Oauh2 related content, but when I went to single sign-on (OSS), there was a problem that has been bothering me for a long time, because of the online upgrade of Spring Boot 1.x to Spring Boot 2.x and then single point. There is very little information about landing related problem solving, so here is a special article to describe the problems encountered in the upgrade process, the problem manifestation phenomenon and how I solve these problems.

Question 1: Sprboot 2 removes @EnableOAuth2Sso?

First of all, let me tell you very clearly, no!! But why did the introduction of spring-security-oauth2 maven rely on IDEA prompt @Enable OAuth2Sso not find it? First we find out. Official Spring Boot 2.x Upgrade Document We will find out about Oauth2:

OAuth 2.0 Support
Functionality from the Spring Security OAuth project is being migrated to core Spring Security. OAuth 2.0 client support has already been added and additional features will be migrated in due course.

If you depend on Spring Security OAuth features that have not yet been migrated you will need to add org.springframework.security.oauth:spring-security-oauth2 and configure things manually. If you only need OAuth 2.0 client support you can use the auto-configuration provided by Spring Boot 2.0. We're also continuing to support Spring Boot 1.5 so older applications can continue to use that until an upgrade path is provided.

_We can roughly understand that official 2.x is migrating Spring Security OAuth project functionality to Spring Security. But most notable is that If you only need OAuth 2.0 client support you can use the auto-configuration provided by Spring Boot 2.0. (If you want to use Oauth2 client-related functions in Spring Boot 2.0 (and above), you need to use auto-configuration.)

application.yml configuration

auth-server: http://Localhost: 9090# authorization service address
security:
oauth2:
client:
user-authorization-uri: ${auth-server}/oauth/authorize #Address Requesting Authentication
access-token-uri: ${auth-server}/oauth/token #The address of the request token
resource:
jwt:
key-uri: ${auth-server}/oauth/token_key #Resolve the address of the key required by the jwt token. When the service starts, the authorization service will be called to obtain the jwt key. So it is necessary to ensure that the authorization service is normal.
sso:
login-path: /login #The path to the login page, where the OAuth2 authorization server triggers redirection to the client, defaults to / login
spring:
profiles:
active: client1

_Because we need multi-client single-point testing, here we use Spring boot multi-environment configuration, where the configuration of authorization services is not described, and the default build of an available authorization service (if you do not know how to build Oauth2 authorization services and resource services, you can pay attention to me, the follow-up will be relevant. Article).

Problem Description and Phenomena

_Browser access test interface localhost:8091/client/1, jump to authorization service landing interface, after successful landing, jump back to the client/login address (that is, spring.security.sso.login-path we configured), under normal circumstances will again jump to localhost:8091/client/1 (this has been authenticated). Visit after work. The whole process is the authorization code mode process of Oauth2. But now there is a problem that when the authorization service calls back to the client's / login address, the browser displays HTTP ERROR 401, as follows:

From the figure, we can see that the authorization service successfully returned the authorization code, but because of the problems of our client, 401 occurred, which caused the whole authorization code mode process to be interrupted. Look at Official auto-configuration document In the process, unintentional discovery

Also note that since all endpoints are secure by default, this includes any default error handling endpoints, for example, the endpoint "/error". This means that if there is some problem during Single Sign On that requires the application to redirect to the "/error" page, then this can cause an infinite redirect between the identity provider and the receiving application.
First, think carefully about making an endpoint insecure as you may find that the behavior is simply evidence of a different problem. However, this behavior can be addressed by configuring the application to permit "/error":

_roughly means that since all endpoints are secure by default, this includes any default error handling endpoints, such as endpoint "/ error". This means that if there are some problems during single sign-on, requiring the application to redirect to the'/ error'page, this will lead to an infinite redirection between the identity provider and the receiving application.

According to this prompt, I started DEBUG. As the document says, there are some problems redirected to / error during single sign-on. So we configure / error as unauthorized access and restart the test interface. This error interface prompt is obvious:

_Since there is a clear indication of Unauthorized, let's take a step-by-step DEBUG to see what's wrong during the single point period.

III. Problem Investigation and Solution

From the description of previous phenomena, we can know that the problem point is calling to get token after the authorization code comes back. Then according to the source code, the step of getting token is inside the OAuth2Client Authentication Processing Filter filter. The key code is as follows:

_We hit the breakpoint here, under Debug, as expected, when we got token, the exception information was: Possible CSRF detected - state parameter was required but no state could be found, debug screenshot is as follows:

_There is a statement about consulting online materials:

Local development, auth server and client are both local hosts, resulting in the interaction of JSESSIONID. This can be done by configuring the context-path or session name of the client

According to this description, I try to solve the problem by modifying the session name:

server:
servlet:
session:
cookie:
name: OAUTH2CLIENTSESSION # Solve the Possible CSRF detected - state parameter was required but no state could be found ed problem

Restart the project, test SSO, perfect solution!!!

_This paper introduces the code of SMS login development, which can access the security module in the code warehouse. The GitHub address of the project is https://github.com/BUG9/spring-security.

If you are interested in these, you are welcome to support star, follow, collect and forward!