主流Web应用是基于HTTP协议的，而HTTP协议是无状态的，就是服务器不知道谁发送这个HTTP请求，无法识别用户身份。

登录态就是服务器用来区分用户身份的，同时对用户进行记录的技术方案。怎么实现用户的登录态呢？常见的实现流程如下：
login

  1. 客户端用户输入登录凭据（如账户和密码），发送登录请求。
  2. 服务端校验用户是否合法（如认证和鉴权），合法后返回登录态，不合法返回第1步。
  3. 合法后携带登录态访问用户数据。

HTTP基本验证

HTTP基本认证是HTTP协议本身提供了一种服务端对客户端进行用户身份验证的方法。流程如下：
http_basic_auth

  1. 客户端向服务端请求需要登录态的数据
  2. 服务端向客户端返回401状态码，要求客户端验证
  3. 客户端根据返回的 WWW-Authenticate: Basic realm=”qq.com”，弹出用户名和密码输入框要求用户进行验证。
  4. 用户输入用户名和密码后，客户端将用户名及密码以 Base64 格式发送给服务端。
  5. 服务端验证通过后返回用户数据。

优点：兼容性好,主流浏览器都支持。实现简单,无需服务端维护状态。

缺点：

  • 安全性差：账号密码仅使用Base64编码(非加密),很容易被解码。必须配合HTTPS使用,否则明文传输极易被截获。
  • 无法主动注销：除非关闭标签或浏览器,否则凭证会持续发送。
  • 用户体验差：每次401响应都会弹出浏览器原生对话框,无法自定义。
  • 功能受限：无法实现复杂的权限控制和会话管理。

Cookie和Session认证

什么是Cookie？

Cookie是客户端请求服务端时，由服务端创建并由客户端存储和管理的小文本文件。具体流程如下：

  1. 客户端首次发起请求。
  2. 服务端通过HTTP响应头里Set-Cookie字段返回Cookie信息。
  3. 客户端再发起请求时会通过HTTP请求头里Cookie字段携带Cookie信息。

什么是Session？

Session是客户端请求服务端时服务端会为这次请求创建一个数据结构，这个结构可以通过内存、文件、数据库等方式保存。
具体流程如下：

  1. 客户端首次发起请求。
  2. 服务端收到请求并自动为该客户端创建特定的Session并返回SessionID，用来标识该客户端。
  3. 客户端通过服务端响应获取SessionID，并在后续请求携带SessionID。
  4. 服务端根据收到的SessionID，在服务端找对应的Session，进而获取到客户端信息。

Cookie和Session认证流程

cookie_session

  1. 客户端向服务端发送认证信息（例如账号密码）
  2. 服务端根据客户端提供的认证信息执行验证逻辑，如果验证成功则生成Session并保存，同时通过响应头Set-Cookie字段返回对应的SessionID
  3. 客户端再次请求并在Cookie里携带SessionID。
  4. 服务端根据SessionID查找对应的Session，并根据业务逻辑返回相应的数据。

如何注销登录态？

  1. 客户端请求注销接口
  2. 服务端删除对应的Session数据
  3. 客户端清除Cookie中的SessionID(可选,也可以通过设置过期时间为过去时间)
  4. 返回注销成功响应

Cookie和Session认证优缺点

优点：

  • Cookie由客户端管理,支持设定有效期、HttpOnly、Secure、SameSite等安全属性。
  • Session由服务端管理,支持有效期,可以存储各类数据(对象、数组等)。
  • 服务端完全控制会话,可以随时失效Session。
  • 成熟稳定,已被广泛应用和验证。

缺点：

  • Cookie只能存储字符串,有大小(约4KB)和数量限制,对移动APP端支持不好,同时有跨域限制(主域不同)。
  • Session存储在服务端,对服务端有内存/存储开销,客户端量太大会影响性能。
  • 分布式环境下需要Session共享方案(如Redis集中存储),会带来额外的部署维护成本和单点故障风险。
  • 需要防范CSRF(跨站请求伪造)攻击,需要额外的CSRF Token机制。
  • Cookie容易受到XSS(跨站脚本)攻击,需要设置HttpOnly属性防止JS读取。

安全性建议

  1. 使用HTTPS传输：防止Cookie在传输过程中被窃取。
  2. 设置Cookie安全属性：
    • HttpOnly: 防止JavaScript访问Cookie,减少XSS攻击风险。
    • Secure: 仅通过HTTPS传输Cookie。
    • SameSite: 防止CSRF攻击(Strict或Lax模式)。
  3. 实施CSRF防护：使用CSRF Token验证请求来源。
  4. Session固定攻击防护：登录成功后重新生成SessionID。
  5. 设置合理的超时时间：避免Session长期有效带来的安全风险。

Token认证

Token又叫令牌，是服务端生成用来验证客户端身份的凭证，客户端每次请求都携带Token。Token一般由以下数据组成：

  • uid(用户唯一的身份标识)
  • time(当前时间的时间戳)
  • sign(签名，由token的前几位+盐用哈希算法压缩成一定长的十六进制字符串)

Token认证流程

token_auth

  1. 客户端向服务端发送认证信息（例如账号密码）
  2. 服务端根据客户端提供的认证信息执行验证逻辑（如查询数据库），如果验证成功则生成Token并返回。
  3. 客户端存储（可以存在Cookie、LocalStorage或本地缓存里）收到的Token，再次请求时携带Token（可以通过HTTP请求头Authorization字段）。
  4. 服务端校验Token（如查询数据库），并根据业务逻辑返回相应的数据。

Token认证优缺点

优点：

  • 无状态：服务端不需要存储会话信息(仅需验证签名),水平扩展方便,无需Session共享。
  • 跨域友好：可以在HTTP Header中传递,不受Cookie跨域限制。
  • 移动端友好：支持APP、小程序等各种客户端环境。
  • 防CSRF：Token通常不存储在Cookie中,天然防御CSRF攻击。
  • 灵活性高：可以在Token中携带自定义信息(如权限、用户信息等)。

缺点：

  • 占用带宽：Token较大(特别是JWT),每次请求都需要传输,消耗带宽。
  • 无法主动失效：无状态特性导致服务端无法主动让Token失效(除非维护黑名单,但失去了无状态优势)。
  • 性能开销：每次请求都需要解析和验证签名,有一定性能开销。
  • 有效期管理：为避免被盗用需要设置较短有效期,但会影响用户体验,需要配合Refresh Token使用。
  • XSS风险：如果存储在LocalStorage中,容易受到XSS攻击,需要做好前端安全防护。

Token安全性建议

  1. 使用HTTPS传输：防止Token在传输过程中被截获。
  2. 合理设置有效期：Access Token设置较短有效期(如15-30分钟),配合Refresh Token使用。
  3. 存储选择：
    • 浏览器环境：优先考虑HttpOnly Cookie,其次是内存存储,避免LocalStorage(XSS风险)。
    • 移动端：使用安全的本地存储机制(如KeyChain、KeyStore)。
  4. 实施Token刷新机制：使用Refresh Token自动刷新过期的Access Token。
  5. 添加额外校验：如设备指纹、IP白名单等增强安全性。
  6. 敏感操作二次验证：重要操作(如修改密码、支付)要求重新验证身份。

Refresh Token

点击跳转

JWT

点击跳转

单点登录认证(SSO)

上面说的都是同一个域名(或同一主域)下,通过Cookie或Token携带凭证实现登录态管理。但是如果有很多域名,
如何实现用户在一个域名下登录后,访问另一个域名也能自动登录呢？这就是单点登录问题(Single Sign On,简称SSO)。

单点登录的核心思想是：用户只需要登录一次,就可以访问所有相互信任的应用系统。

要实现SSO,需要有一个CAS(Central Authentication Service)中央授权服务(假设域名为cas.com)
来提供统一的登录功能。所有应用系统都信任CAS颁发的Token。

单点登录认证流程

假如现在有域名http://abc.com和http://123.com要实现互相自动登录。流程如下：

  1. 先访问http://abc.com
    sso_1

    1. 客户端访问http://abc.com
    2. http://abc.com发现没有登录（http://abc.com域下没有Session或Session失效），302跳转到http://cas.com并携带http://abc.com的回调地址（登录成功跳转回来的页面链接）。
    3. http://cas.com发现没有登录（http://cas.com域下没有Session或Session失效），302跳转到http://cas.com登录页面并携带http://abc.com的回调地址。
    4. 客户端携带http://abc.com回调地址访问http://cas.com。
    5. 客户端向http://cas.com发送认证信息（例如账号密码）。
    6. http://cas.com登录成功并生成http://cas.com域下的Session，同时生成一个Token，根据回调地址携带此Token重定向到http://abc.com。
    7. 客户端携带Token访问http://abc.com。
    8. http://abc.com访问http://cas.com验证Token的有效性，验证成功并生成http://abc.com域下的Session，完成登录。

  2. 再访问http://123.com
    sso_2

    1. 客户端访问http://123.com
    2. http://123.com校验失败，需要登录（http://123.com域下没有Session或Session失效），302重定向到http://cas.com，并携带http://123.com回调地址。
    3. 客户端携带http://123.com回调地址访问http://cas.com。
    4. http://cas.com根据http://cas.com下的Session(访问http://abc.com时生成的)发现用户已登录,生成Token后302重定向到http://123.com。
    5. http://123.com访问http://cas.com验证Token的有效性,验证成功并生成http://123.com域下的Session,完成登录。

单点登录的注销

单点登录的注销相对复杂,需要同时清除CAS和所有子系统的登录态：

  1. 客户端向某个子系统(如http://abc.com)发起注销请求。
  2. http://abc.com清除本地Session,同时通知http://cas.com注销。
  3. http://cas.com清除Session,并通知所有已登录的子系统(需要维护已登录系统列表)。
  4. 各子系统收到通知后清除各自的Session。
  5. 完成全局注销。

SSO的优缺点

优点：

  • 用户体验好：一次登录,处处访问,减少重复登录操作。
  • 统一管理：集中管理用户认证,便于统一安全策略和审计。
  • 降低密码泄露风险：减少用户在多个系统使用不同密码的情况。

缺点：

  • 实现复杂：需要额外的CAS服务,涉及多次重定向和Token验证。
  • 单点故障：CAS服务故障会导致所有子系统无法登录,需要高可用方案。
  • 性能开销：每次验证都需要与CAS通信,增加网络开销。
  • 注销复杂：全局注销需要通知所有子系统,实现难度大。

OAuth 2.0 和 OpenID Connect

除了上述方案,现代应用中还常用OAuth 2.0和OpenID Connect：

  • OAuth 2.0：授权框架,允许第三方应用访问用户资源,但不直接提供认证功能。常用于”使用XX账号登录”场景。
  • OpenID Connect：基于OAuth 2.0的认证层,专门用于身份认证,是现代SSO的主流实现方式。

这两种方案适用于需要与第三方平台集成或构建开放平台的场景。

总结与选型建议

各方案适用场景

  • HTTP基本认证：适用于对安全要求不高或内部系统用户量极少的场景,如内网工具、临时测试环境。实际生产应用不多。

  • Cookie和Session认证：适用于传统Web应用(浏览器环境),特别是需要服务端严格控制会话的场景。需要注意安全防护(CSRF、XSS)。

  • Token认证：适用于前后端分离、移动端APP、小程序、PC端软件等多终端场景。特别适合微服务架构和分布式系统。

  • 单点登录(SSO)：适用于大型站群系统、企业内多个业务系统需要互通的场景。现代实现推荐使用OpenID Connect。

选型考虑因素

  1. 应用场景：Web端、移动端还是多端统一？
  2. 架构类型：单体应用、分布式系统还是微服务架构？
  3. 安全要求：对安全性的要求级别？是否需要合规认证？
  4. 用户规模：并发用户数和总用户量？
  5. 开发成本：团队技术栈和开发周期限制？
  6. 运维成本：是否有专门的运维团队？是否需要高可用？

最佳实践

  1. 永远使用HTTPS：无论哪种方案,生产环境必须使用HTTPS加密传输。
  2. 密码安全存储：使用bcrypt、PBKDF2等安全哈希算法,加盐存储,永不明文。
  3. 多因素认证(MFA)：对于敏感系统,建议实施双因素认证(如短信验证码、TOTP)。
  4. 日志与监控：记录所有认证相关操作,及时发现异常登录行为。
  5. 定期安全审计：定期检查和更新安全策略,修复已知漏洞。
  6. 限流与防暴力破解：实施登录频率限制、验证码等机制防止暴力破解。
许可协议

本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。