Mastering CAS-Based Single Sign-On: From Session Mechanics to Seamless Logout

As business systems grow, users often need to log into multiple applications, leading to fragmented credential management and poor user experience. A unified authentication approach—single sign‑on (SSO)—eliminates this friction by allowing one login to access an entire application cluster.

Traditional Session Mechanism

Typical single‑system login relies on cookie‑based sessions: after successful authentication, the server creates a session ID stored in the browser’s cookie. Subsequent requests carry this cookie, enabling the server to retrieve the session and verify the user’s login state.

CAS Overview

CAS (Central Authentication Service) consists of a CAS‑SERVER and multiple CAS‑CLIENT modules. The server handles user credential verification and issues tickets, while each client protects its resources by redirecting unauthenticated requests to the server.

Single Sign‑On Implementation

The SSO service presents a login page; after user authentication it creates a global session and generates a login token tied to the target application. The application receives the token, calls the SSO API to obtain user information, and establishes a local (partial) session.

Local sessions rely on the global session, so the global session’s lifetime must exceed that of any local session.

Session Renewal

To keep the global session alive longer than any local session, a renewal rule is applied: when a user accesses an application, the system checks the remaining lifetime of the local session. If it is less than half of its configured duration, the application invokes the SSO API (providing the token and user info) to extend the global session.

Single Logout

When a logout request arrives, the application terminates its local session and calls the SSO API with the token to invalidate the global session. The SSO service then retrieves all associated local sessions and triggers logout on each application.

Business Requirement Extensions

To avoid changing existing login pages, the original login flow can be preserved: users log into the local system, which then creates a token and redirects to the SSO service. The SSO service converts the token to user information, stores it in the global session, and enables seamless access to other systems.

When a user logs in from a different browser, previous global sessions are cleared to prevent multiple concurrent sessions that could interfere with renewal and logout processes.

Key Considerations

Concurrent requests may cause parallel redirects to the SSO service, leading to inconsistent login tokens between the global and local sessions. A solution is to lock token generation on the SSO side and cache the token for a short period (e.g., 3 seconds) so that concurrent requests receive the same token. Additionally, ensure that cookies set by the application use the token’s MD5 hash as the value to keep them consistent.

Conclusion

The article presents a comprehensive CAS‑based SSO solution covering single sign‑on, session renewal, and single logout, along with extensions for preserving existing login flows and handling multi‑device logins. While the implementation details are covered, integrating permission verification remains essential for a production‑grade SSO system.