SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillssa-token-sso

sa-token-sso

General & other

View repository

Updated 10-15 21:48

About this skill

Sa-Token SSO Single Sign-On

Based on sa-token-doc/sso/ all 18 documents. Basic authentication uses the sa-token skill.

Capability Boundaries

✅ Strong Suits

  1. SSO Mode 1 (same domain + Cookie) — same frontend domain + same Redis, shared Cookie session synchronization
  2. SSO Mode 2 (cross-domain + redirection) — different frontend domains + same Redis, session propagation via URL redirection
  3. SSO Mode 3 (cross-domain + Http ticket) — different Redis + different network, obtain ticket via Http request
  4. SSO-Server setup — unified login/logout at the authentication center
  5. SSO-Client integration — application systems integrate with SSO
  6. Single sign-out — logging out in one place logs out all systems simultaneously
  7. Frontend-backend separation SSO — H5 solution adapted for SPA applications
  8. Custom login page — customized Server-side login page
  9. Domain verification — client domain whitelist
  10. NoSdk/ReSdk — SSO integration for non-Java projects

⚠️ Requirements

  1. Mode 1 and Mode 2 require all services to share the same Redis
  2. SSO-Server and SSO-Client need network connectivity
  3. For production environments, it is recommended to configure secret-key encrypted communication

❌ Out of Scope

  1. Basic login/permissions/annotation-based authentication → sa-token
  2. OAuth2.0 server → sa-token-oauth2
  3. Microservice authentication → sa-token-micro

Comparison of the three modes

Mode Scenario Shared Redis Authentication mechanism Applicable
Type 1 Same domain ✅ Cookie sharing Subsystems under the same parent domain
Type 2 Different domains ✅ URL redirection Different domains but shared Redis
Type 3 Fully isolated ❌ HTTP ticket Different Redis, different network

When to use which mode

  • Multiple subsystems under the same parent domain(such as admin.example.com、shop.example.com) → Mode 1, the simplest
  • Different domains but shared Redis infrastructure → Mode 2
  • Completely independent services, different Redis, different network environments → Mode 3
  • Not sure which to choose → choose Mode 3 by default, for the highest flexibility

Workflow

Step 1. Confirm the environment — import the sa-token-sso dependency, confirm the Redis connection Step 2. Choose a mode — choose Mode 1/2/3 according to the system architecture Step 3. Set up SSO-Server — configure the authentication center /sso/auth and other endpoints Step 4. Integrate SSO-Client — configure the authentication address for each application system Step 5. Configure domain verification — set the allowed domain whitelist Step 6. Enable single sign-out — configure is-slo: true Step 7. Test and verify — Verify the cross-system login/logout process

Reference Documentation

Topic File Source
SSO-Server setup + three modes references/sso-server.md sso-server、sso-type1、sso-type2、sso-type3
SSO-Client integration + logout + FAQ references/sso-client.md readme、signout、sso-questions
Frontend-backend separation SSO (H5) references/sso-h5.md sso-h5

FAQ

Q: What is the difference between SSO and OAuth2.0? A: SSO solves the problem of unified login across multiple systems (one account logs into all systems). OAuth2.0 solves the problem of third-party authorization (allowing third-party applications to access user data). For simple scenarios choose SSO, for open platform scenarios choose OAuth2.0.

Q: How to choose among the three SSO modes? A: For the same domain use mode one (the simplest), for cross-domain but shared Redis use mode two, for fully isolated environments use mode three. When unsure, choose mode three.

Q: Must SSO-Server and SSO-Client use the same language? A: Modes one and two require it (they depend on the shared Redis Java SDK), mode three is language-agnostic (interacts via HTTP).

Q: How to ensure the security of the ticket? A: 1) Configure secret-key encrypted communication; 2) the ticket validity period defaults to 5 minutes, which is relatively short; 3) configure is-check-sign: true to verify the signature.

Q: Does SSO support frontend-backend separation projects? A: Yes. There is a dedicated H5 solution, where the frontend SPA application passes the ticket via URL parameters, and the backend provides an interface to exchange it for the login state.

Q: How does single sign-out work? A: When the user logs out on the SSO-Server, the Server sends a logout notification to all registered Clients, and each Client clears its local session.

Gotchas

  1. Mode three requires configuring ticket-url — must not omit the ticket-url configuration, otherwise the Client cannot verify the ticket with the Server
  2. secret-key must be configured in production — during debugging it can be set to is-check-sign: false, in production it must be enabled
  3. Domain verification whitelist — when allow-domains is not configured, all domains can connect; in production it needs to be restricted
  4. Single sign-out requires two-way configuration — Server side is-slo: true + Client side reg-logout-call: true
  5. With frontend-backend separation, the ticket parameter in the URL needs to be actively handled by the frontend — the backend will not automatically redirect
  6. Mode one depends on Cookie same-domain — subdomains must be under the same parent domain (e.g. .example.com）
  7. Do not confuse Same-Token with SSO — Same-Token is used for internal authentication of microservices, SSO is used for sharing the user login state

Data Privacy

This skill does not collect, store, or transmit any user data. All code examples are for local development reference only.