Mastering SSO: JWT, Session, CAS & OAuth Explained with Real-World Implementation

Background

During a recent project migration, two systems used different login schemes, leading to cross‑domain login state sharing problems. The migration prompted an investigation into Single Sign‑On (SSO) mechanisms.

Login State Maintenance Methods

JWT (JSON Web Token)

What is JWT?

JWT is an open JSON‑based token standard that provides a compact, secure way to transmit data using signatures. It is commonly used to store login information without requiring the server to maintain session state.

Structure

JWT consists of three parts: header, payload, and signature, separated by dots (.) and encoded with Base64URL.

{
  "alg": "HS256",
  "typ": "JWT"
}

The payload can contain standard fields such as iss (issuer), exp (expiration), sub (subject), aud (audience), nbf (not before), iat (issued at), and jti (JWT ID), as well as custom claims.

Characteristics

JWT is not encrypted by default; sensitive data should not be placed in the payload.

It reduces server‑side database queries because the token carries the necessary information.

Since the server does not store session state, revoking a token before its expiration requires additional logic.

Tokens should be short‑lived and transmitted over HTTPS to mitigate theft.

Session & Cookie

Cookie

A cookie is a small piece of data stored by the browser and sent with each request to the same server, enabling the server to recognize the client and maintain login state.

There are two main types: session cookies (deleted when the browser closes) and persistent cookies (stored until a specified expiration date).

Session

A session lives on the server and holds user‑specific data across multiple requests. The server creates a session ID, sends it to the client via a Set‑Cookie header, and the client returns it in subsequent requests.

Session vs. Cookie Differences

Security: Session data resides on the server, making it less vulnerable to theft than client‑side cookies.

Data Types: Cookies store only strings; sessions can store any data type.

Size: A single cookie is limited to ~4 KB, while sessions can hold much larger data, though they consume server resources.

Single Sign‑On (SSO)

What is SSO?

SSO allows a user to log in once and gain access to multiple independent applications without re‑authenticating.

CAS (Central Authentication Service)

CAS is an open‑source, enterprise‑grade SSO solution originally developed by Yale. It defines several key concepts:

User : the end‑user.

Web Application : a client that trusts the CAS server.

CAS Server : the authentication authority.

CAS issues a Ticket‑Granting Ticket (TGT) stored in a cookie (TGC). When a service needs authentication, it requests a Service Ticket (ST) from CAS using the TGT.

OAuth

OAuth is an open standard for delegated authorization. It enables third‑party applications to obtain limited access to a user's resources without exposing credentials.

Key roles include:

Resource Owner : the user.

Client : the third‑party application.

Authorization Server : issues access tokens after user consent.

Resource Server : hosts the protected resources.

OAuth defines several grant types (authorization code, implicit, password, client credentials) each with its own flow and security considerations.

Implementing a Simple SSO Demo

Architecture Overview

The demo consists of six sub‑projects organized in a monorepo: three React front‑ends (Platform A, Platform B, Unified Login) and three Node back‑ends (Platform A, Platform B, Unified Login). All services run locally on different ports.

Key Modules

FE‑Platform A / BE‑Platform A

FE‑Platform B / BE‑Platform B

FE‑Unified Login / BE‑Unified Login (SSO server)

Core APIs

/authentication

(GET): checks login status, returns 200 on success. /userLogout (POST): logs out the current user. /ssoLogout (POST): clears the token on the SSO server. /login (POST, SSO): accepts account and password, returns a token on success. /sendToken (POST, SSO): receives a token from a client platform. /searchLoginState (GET, SSO): validates a token. /logout (POST, SSO): invalidates a token.

Login Flow Diagrams

First‑time login:

Subsequent login:

Logout flow:

Additional Implementation Details

Front‑End Framework

The front‑ends are built with React and share a common monorepo configuration.

Token Persistence

For the demo, logged‑in tokens are stored in a JSON file on the Node back‑end using the fs module to simulate persistence.

Local Development Ports

FE‑Unified Login: 3000

BE‑Unified Login: 4000

FE‑Platform A: 3001

BE‑Platform A: 4001

FE‑Platform B: 3002

BE‑Platform B: 4002

Cross‑Origin Proxy

During development, a proxy configuration in devServer forwards API calls to the appropriate back‑end ports.

devServer: {
  proxy: {
    '/api': {
      target: 'http://localhost:400x',
      changeOrigin: true,
      pathRewrite: { '^/api': '' }
    }
  }
}

Discussion

Q: How can a JWT be invalidated?

A: Because JWTs are stateless, the server does not store them, so true revocation requires additional state (e.g., a blacklist) or short‑lived tokens.

Q: What happens if a business system integrates SSO but does not maintain its own login state?

A: Each request would need to go through the SSO server, increasing load on the SSO service and adding latency for the user.

Supplementary Content

Encryption Algorithms

Common symmetric algorithms include DES, 3DES, AES; asymmetric algorithms include RSA, DSA; hash algorithms include SHA‑1, MD5.

Hash functions are fast to compute, irreversible, highly sensitive to input changes, and have a negligible chance of collisions.

References

Localhost ports: http://localhost

Article on seven common encryption algorithms: https://juejin.cn/post/6844903638117122056

Understanding Cookie, Session, Token, JWT: https://juejin.cn/post/6844904034181070861#heading-17

SSO & CAS basics for front‑end developers: https://juejin.cn/post/6844903509272297480

OAuth 2.0 fundamentals: https://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html