Analysis of Loop Login Issues in Single Sign-On (SSO) and Their Solutions

Author: Wang Fei from the Vivo Internet Server Team.

Single Sign-On (SSO) is a common public component used across many internal systems. While it simplifies user authentication, it can encounter problems such as loop login, where the front‑end page continuously redirects and shows a “too many redirects” error.

1. Introduction to SSO

When a company has multiple systems, requiring users to log in to each one is inefficient. SSO allows a user to authenticate once and then access all authorized applications without re‑entering credentials.

SSO (Single Sign On) enables one‑time login to obtain a token or ticket that grants access to multiple services.

2. Basic Implementation Principle

The typical flow includes:

User login: credentials are submitted to an authentication system.

Authentication verification: a signed token (e.g., Token or Ticket) is generated.

Token distribution: the token is returned to the requesting application.

Application authorization: the application validates the token and grants access.

Cross‑domain access: the same token can be used across different domains without re‑authentication.

3. Loop Login Problem

During a routine login to an internal system, the front‑end started refreshing repeatedly with a “too many redirects” message.

Network inspection revealed a large number of redirect requests.

Deleting the browser cookies temporarily resolved the issue, prompting an analysis of the root cause.

4. Normal Login Flow (Illustrated)

The standard steps are:

User accesses https://aaa.x.y for the first time.

Permission system intercepts the request and redirects to the SSO login page if the user is not authenticated.

User submits credentials; SSO authenticates and writes the login state to its session.

SSO generates a token and redirects back to the original system, passing the token as a parameter.

The system validates the token with SSO.

Upon successful validation, the system stores a top‑level domain cookie.

Relevant HTTP headers captured during the process:

Connection: keep-alive
Content-Length: 0
Date: Wed, 25 Oct 2023 08:29:43 GMT
Location: http://aaa.x.y/console/login/auth?redirectUrl=http://aaa.x.y/
optrace: xx.xx.xx.xx:80/302 <- -
Server: nginx
Set-Cookie: token=fakdfajdfdjfdjkfaldfjk'afafjasfasfa; Max-Age=86400; Expires=Thu, 26-Oct-2023 08:29:43 GMT; Domain=x.y; Path=/; HttpOnly

Because the company uses a single top‑level domain (e.g., x.y ) with multiple sub‑domains, the SSO cookie is set for the top‑level domain so that all sub‑systems can share it.

5. Root Causes of Loop Login

(1) After a page refresh, the request is redirected to the permission system, but the Cookie header does not contain the expected token.

(2) When the permission system redirects back, the Set‑Cookie response includes a warning: the cookie is being set over an insecure (HTTP) connection, so the Secure attribute should have been used.

The Secure attribute restricts a cookie to HTTPS only. Because the subsequent login request was made over HTTP, the cookie was not sent, causing the authentication check to fail and the redirect loop to continue.

6. Clearing Browser Cache – Underlying Principle

Removing the cookie (by clearing cache) also deletes the Secure attribute, allowing the subsequent HTTP request to set a new cookie without the Secure flag, thus breaking the loop.

7. Additional Solutions

Method 1: Access the system via HTTPS, ensuring that Secure cookies are transmitted correctly.

Method 2: Introduce a new cookie parameter (e.g., newToken ) that is not marked Secure, allowing HTTP services to read/write authentication data without being blocked by the Secure flag.

8. Cookie Port Non‑Isolation

According to RFC 6265, cookies are not isolated by port. Therefore, a cookie set by a service on port 443 (HTTPS) can be read by a service on port 8080 (HTTP) if they share the same domain, which explains why the Secure attribute is crucial for preventing cross‑protocol leakage.

Reference: RFC 6265 – Weak Confidentiality

9. Conclusion

The article analyzes a loop‑login issue caused by Secure‑flagged cookies being set over HTTP, presents the root cause, and offers two practical mitigation strategies (HTTPS enforcement and a secondary non‑Secure token). The insights are valuable for developers dealing with authentication and permission systems.