按照不同的技术手段和实现机制，可以将单点登录（SSO）的方法划分为以下几类：

适用于同一个主域名下的多个子域名。通过在主域名设置共享的 Cookie，实现跨子域名的单点登录。

优点是实现简单，无需额外的认证服务器。缺点是只能在同一主域名下使用，跨域名无法使用。
实现步骤：
1. 用户在主域名（如 example.com）登录后，服务器在该域名下设置一个 Cookie。
2. 子域名（如 app1.example.com 和 app2.example.com）可以读取这个 Cookie，从而确认用户身份。
应用场景：
企业内部系统：公司内部多个子系统需要共享用户身份，如企业门户网站、内部邮件系统、员工管理系统等。
如：Google：用户在 google.com 登录后，可以无缝访问 mail.google.com、drive.google.com 等所有子域名下的服务。

2. 基于认证中心
通过独立的认证服务器（认证中心）管理用户的身份验证。

优点是支持跨域名的单点登录，安全性高，集中管理用户认证逻辑。缺点是实现复杂， 需要维护独立的认证中心。

典型框架：
* CAS (Central Authentication Service)
* OAuth2（例如，Auth0，Spring Security OAuth）
* SAML (Security Assertion Markup Language)（例如，Shibboleth）
实现步骤：
1. 用户访问需要认证的应用（如 app1.example.com），被重定向到认证中心（如 auth.example.com）进行登录。
2. 用户在认证中心登录成功后，生成一个令牌并将用户重定向回原始应用，同时携带令牌。
3. 应用接收令牌并向认证中心验证其有效性，获取用户信息。
4. 应用创建会话并允许用户访问。
应用场景：
跨域名的企业应用：企业内部多个系统分布在不同的域名下，需要统一用户认证。
多租户的SaaS服务：不同租户的应用需要统一的身份认证服务。

3. 基于令牌（Token）的SSO
通过使用令牌（如 JWT）进行身份验证和授权。

优点是无需依赖 Cookie，适用于移动应用和SPA（单页面应用），跨域名支持良好。缺点是 令牌的安全存储和管理需要特别注意。
实现步骤：
1. 用户登录后，服务器生成一个令牌（如 JWT）。
2. 客户端保存该令牌，并在后续请求中携带它。
3. 服务器验证令牌的有效性以确认用户身份。
典型框架：
* JWT (JSON Web Token)
* OAuth2

应用场景：
移动应用和SPA（单页面应用）：移动端应用和前后端分离的SPA应用，通常使用令牌进行身份验证。
微服务架构：各个微服务之间需要安全可靠地传递用户身份信息。

4. 基于浏览器的 LocalStorage 和跨域消息传递
利用浏览器的 LocalStorage 和跨域消息传递（Cross-Origin Messaging）实现单点登录。

优点是可以实现跨域名的单点登录， 无需依赖 Cookie。缺点是安全性较低，LocalStorage 中的数据容易被恶意脚本访问， 实现较为复杂，需要处理跨域消息传递的安全性和可靠性。
实现步骤：
1. 用户在某一应用（如 app1.com）登录后，将用户信息存储在 LocalStorage 中。
2. 其他应用（如 app2.com）通过嵌入隐藏的 iframe（指向登录应用的域名）或使用跨域消息传递的方式，从 LocalStorage 中读取用户信息。
3. 应用读取用户信息并确认身份。
应用场景：
需要在跨域环境中实现单点登录的应用：无法通过父域 Cookie 实现跨域认证的场景。
多域名的前端应用：同一个公司或组织的不同域名下的前端应用，需要共享用户认证信息。

5. 基于反向代理
使用反向代理服务器统一处理用户认证，代理服务器在后端各个应用之间共享用户身份信息。

优点是可以集中管理认证逻辑和安全策略，跨应用实现简单。缺点是依赖代理服务器的性能和可靠性。
实现步骤：
1. 用户访问应用时，首先通过反向代理服务器进行认证。
2. 代理服务器在用户认证通过后，在请求中添加用户身份信息。
3. 后端应用根据代理服务器提供的用户身份信息，实现单点登录。
典型框架：
* Nginx 配合 Auth_request 模块
* Apache 配合 mod_auth 模块

应用场景：
企业网关：企业内部通过反向代理统一管理多个内部应用的认证和授权。
API网关：通过反向代理的方式统一管理微服务的认证和访问控制。

不同的技术手段和实现机制有各自的适用场景和优缺点，选择合适的SSO方案需要根据具体需求和应用环境来确定。