Author: Wang Fei from vivo internet server team
As a public component, single sign-on is widely used by various systems within each company, but in the process of using it we will encounter a variety of problems, of which the circular login problem is a more classic problem. This paper mainly analyzes the basic principles of single sign-on and privilege system design, and then combines the actual cases to analyze the causes of circular login and give specific solutions.
A simple introduction to single sign-on
1.1 Basic concepts
A company may exist within a number of systems, if each person in the use of different systems need to re-login, then it will do a lot of system login to switch, consume more energy to manage accounts and passwords, then there is no way to log in all the systems in a company within the validation of a single login, and the subsequent use of other systems do not have to repeat the time to log in to be able to use it directly, this is the single sign-on This is the single sign-on to solve the problem.
Single Sign On (SSO) allows users to log in once to access multiple applications or systems without having to enter authentication credentials for each application or system separately, and then be authorized in all other systems without having to log in again.
1.2 Basic realization principle
-
User Login: Users authenticate in any application or system and provide their credentials. -
Authentication System Validation: The credentials are sent to the authentication system for validation. If the credentials are valid, the authentication system generates a digitally signed token (such as a Token or Ticket) for the user. -
Token Distribution: The authentication system returns the token to the application or subsystem. -
Application or system authorization: The application or system uses the token to authenticate the user's identity and authorize him or her to access the appropriate resources or services. -
Cross-domain system access: Users can access multiple cross-domain applications or systems with the same token without having to repeat authentication.
II. Cyclic login problems
One day when we were logging into an internal system, we suddenly had a recurring login problem, and the front-end page kept refreshing with the message "redirection too many times problem".
Open the front-end debugging function, we will find that there is indeed a large number of redirected requests:
Why does the system that usually has no problem logging in suddenly cycle through logins? And on the page prompted the solution "try to delete your cookie operation", according to this operation, indeed the system can jump to the login page to login normally, what is the reason for this? Here we will analyze one by one.
III. Starting with a normal login process
The above is a generalized standard process for system privilege control and single-point system authentication:
-
On the user's first visit, type Enter in the browser -
The permission system intercepts and determines whether the user is logged in or not, here it is mainly judged by whether there is login information or not, if there is no login, the permission system will help us jump to the single sign-on system and pop up the user login page. -
The user fills in the user name and password, and the single sign-on system authenticates and writes the login status to the SSO session. -
The SSO system generates a Token for our system after logging in and then jumps to our system while passing the Token as a parameter to our system. -
After our system gets the Token, it sends a request from the backend to the SSO to verify that the Token is valid. -
After the validation is passed, our system will record the cookie information under the top-level domain.
Connection: keep-alive
Content-Length: 0
Date: Wed, 25 Oct 2023 08:29:43 GMT
Location: /console/login/auth?redirectUrl=/
optrace: :80/302 <- -
Server: nginx
Set-Cookie: token=fakdfajdfdjfdjkfaldfjk'afafjasfasfa; Max-Age=86400; Expires=Thu, 26-Oct-2023 08:29:43 GMT; Domain=; Path=/; HttpOnlyGenerally, there is only one domain name within a company, and different systems are distinguished by second-level domain names. For example, we have a domain name: , at the same time there are two business systems are: and . SSO login, you can set the domain of the cookie to the top domain, that is, so that all sub-domains of the system can access to the top domain of the cookie, to realize the single sign-on function.
IV. Root causes of circular logging
So why the constant cycle of logging in?
(1) From the jump records, we found that after refreshing the page, it redirected to the permission system, and the cookie information in the Request Headers did not pass the corresponding Token information.
(2) After jumping to the privilege system and then jumping to this system, the corresponding token information has been obtained, but there is a warning when it comes to Set-Cookie information.
The specifics of the warning are:
Roughly speaking: this Set-Cookie operation was blocked because the cookie was not transmitted over a secure connection, we did use HTTP for this visit and should have overridden the corresponding cookie by setting the Secure property.
The Secure attribute is an attribute of the cookie. The Secure attribute means that if a cookie is set to Secure = true, the cookie can only be sent to the server using the HTTPS protocol, and will not be sent using the HTTP protocol, and we can see that the next login request from the location above does not pass the cookie information. The next login request at the location marked above does not pass the cookie information, and thus continues to verify whether the user is logged in or not, and enters a dead loop, which can be visualized in the following diagram.
V. The underlying principle and solution to clear the browser cache
5.1 The Underlying Principle of Clearing the Browser Cache
We can see that after the cycle of login, will be prompted in the browser page redirect too many times, try to clear the cookie information, that clear the cookie information, is it really can solve this problem, we try to clear the browser cache, can indeed solve this problem, that clear the browser cache to solve the cycle of login problem of the underlying principle is what, in essence, is that Delete the cookie, the Secure attribute on other domain name setting cookies will also be deleted, so that you can use the HTTP domain name to enter the re-login process, you can set the cookie information normally.
5.2 Other solutions
Method 1: Use HTTPS for Access
In reality, we can not control other HTTPS access to the same top-level domain name of the service does not set the Secure attribute of the Cookie, so we will still encounter this problem in the process of the later use, so there is a complete solution to avoid this problem again, we have analyzed, the reason why we started to use HTTP can be normal access and then suddenly not normal access is because the Cookie information has been set by HTTPS can not be reset by HTTP, and thus can not get the Cookie information. We have analyzed earlier, the reason why we can access normally using HTTP at the beginning, and then suddenly can not access normally, is because the cookie information that has been set by HTTPS can not be reset by HTTP, so we can not get the cookie information. The first solution is to use HTTPS to access, even if other services have set the Secure attribute of the cookie, HTTPS can still successfully set the cookie and get the cookie.
Method 2: Set a newToken in the Cookie information.
The above method from HTTP to HTTPS access in the user initiative to find us feedback is able to tell it to switch to HTTPS access, but if for some users who do not take the initiative to find us feedback, in fact, can not be resolved, and may be lost to the loss of this user caused by the loss of users, so we are not in the user to switch in the case of whether it is possible to solve this problem.
The same company's internal access rights system is a bottom of the public capacity, in order to ensure single sign-on, in fact, the user information is read through the same cookie parameters (such as Token) read, so in other domains set the Secure attribute of the public cookie parameters and affects the HTTP login, we can give the service to the new addition of a cookie parameter newToken to the service.
VI. Extension: Port Non-Isolation of Cookies
The problem described in this article appears in the context of two basic premises: one is to ensure single sign-on, the two domains belong to the same top-level domain, the verification of user information in the privilege system are read through the same cookie attribute; the second is that HTTPS sets the Secure attribute of the cookie information of the top-level domain, and then using HTTP access will The second is that HTTPS sets the Secure attribute of the cookie information of the top-level domain name, and then using HTTP access will lead to circular login. Some developers may have a question, that is, HTTPS we generally open port 443, HTTP we generally open port 8080, why not distinguish the same cookie attribute from the port to avoid interference?
This is described in the Cookie Specification (RFC 6265As described in the "Cookies" section of this document, cookies are not port-isolated, meaning that if a cookie can be read by a service running on one port on a server, it can also be read by a service running on another port on that server; if a cookie can be written to a service running on one port on a server, it can also be written to a service running on another port on that server; and if a cookie can be written to a service running on a port on a server, it can also be written to a service running on another port on that server. If a cookie can be written by a service running on one port on one server, it can also be written by a service running on another port on that server.
VII. Summary
This paper starts from the circular login problem encountered in the actual development process, analyzes the root cause of the circular login due to the setting of Secure attribute, which leads to the inability to save cookie information when accessing web pages using HTTP, and also gives two other solutions to solve this problem, which is of some reference significance for other developers to solve the circular login problem of the privilege system.
References:
Ideas and solutions for single sign-on
Sessions don't work in Chrome but do in IE
8.5. Weak Confidentiality