常见的登录鉴权方式有 Session + Cookie、Token、JWT、OAuth 2.0 和 SSO 等。
Session + Cookie
Session + Cookie 是服务端保存用户登录状态，客户端通过 Cookie 携带 Session ID，优点是服务端容易管理会话，缺点是分布式部署时需要解决 Session 共享问题。
完整过程是：用户提交账号和密码，服务端校验成功后创建 Session，并生成对应的 Session ID。服务端通过 Set-Cookie 把 Session ID 返回给浏览器，浏览器之后会自动携带 Cookie。服务端根据 Session ID 找到会话，完成身份识别。
用户退出登录时，服务端删除或失效 Session，同时让浏览器清除 Cookie。分布式部署时，可以通过 Redis 集中保存 Session，也可以使用负载均衡的会话粘滞，但会话粘滞会影响扩容和故障切换的灵活性。
服务端 Token
Token 是基于令牌的认证方式，服务端可以通过 Redis 等存储验证令牌，优点是方便主动撤销，缺点是通常需要查询存储。
登录成功后，服务端生成一个随机且不可预测的 Token，把 Token 与用户信息、权限和过期时间存入 Redis，再把 Token 返回给客户端。客户端后续通过 Authorization 请求头携带 Token，服务端查询 Redis 并验证有效期。
这种方案的核心是“Token 本身只作为索引，状态仍然保存在服务端”。当用户退出、修改密码或账号存在风险时，可以直接删除 Token，实现立即失效。为了降低泄露风险，需要设置过期时间、使用 HTTPS，并避免在日志中输出完整 Token。
JWT
JWT 是一种包含声明并通过签名验证的令牌格式，服务端可以在不查询会话存储的情况下验证令牌，适合分布式系统，但默认不容易立即撤销，需要关注令牌泄露和过期管理。
JWT 的过程是：用户登录成功后，服务端把用户标识、权限和过期时间等声明写入 Payload，并使用密钥签名。客户端携带 JWT 请求接口，服务端验证签名、有效期、签发方和接收方等信息，验证通过后再读取用户身份。
JWT 的 Payload 只是编码，不是加密，不能存放密码等敏感信息。实际使用时通常让 Access Token 保持较短有效期，再配合有效期更长的 Refresh Token。Access Token 过期后，客户端使用 Refresh Token 换取新令牌；Refresh Token 需要由服务端保存、轮换并支持撤销，避免长期凭证泄露后一直被滥用。
OAuth 2.0 与 OpenID Connect
OAuth 2.0 主要用于授权，OpenID Connect 则在其基础上提供身份认证能力，常用于第三方登录。
以第三方登录为例，用户先被引导到授权服务器完成登录和授权，授权服务器再把授权码返回给业务系统。业务系统使用授权码换取 Token，并通过 OpenID Connect 的 ID Token 或用户信息接口确认用户身份。
这个过程不应该把第三方账号密码交给业务系统。授权码模式还需要校验 state 防止 CSRF；公共客户端通常配合 PKCE，避免授权码被截获后直接换取 Token。
SSO
SSO 主要解决多个系统之间的统一登录问题。用户登录一次后，可以访问多个相互信任的业务系统，不需要在每个系统重复输入账号和密码。
典型过程是：用户访问业务系统 A，发现未登录后跳转到统一认证中心；认证中心完成登录，再向系统 A 返回一次性的登录凭证；系统 A 校验凭证后建立自己的登录态。用户之后访问系统 B，系统 B 同样跳转认证中心，此时认证中心已经有登录态，可以直接签发凭证并跳回系统 B。
SSO 需要特别处理统一退出、各业务系统会话过期时间不一致、凭证重放和认证中心高可用等问题。
简答
常见的登录鉴权方式有 Session + Cookie、Token、JWT、OAuth 2.0 和 SSO 等。
Session + Cookie 是服务端保存用户登录状态，客户端通过 Cookie 携带 Session ID，优点是服务端容易管理会话，缺点是分布式部署时需要解决 Session 共享问题。
Token 是基于令牌的认证方式，服务端可以通过 Redis 等存储验证令牌，优点是方便主动撤销，缺点是通常需要查询存储。
JWT 是一种包含声明并通过签名验证的令牌格式，服务端可以在不查询会话存储的情况下验证令牌，适合分布式系统，但默认不容易立即撤销，需要关注令牌泄露和过期管理。
OAuth 2.0 主要用于授权，OpenID Connect 则在其基础上提供身份认证能力，常用于第三方登录。SSO 主要解决多个系统之间的统一登录问题。
实际开发中，我会根据业务需求选择方案：传统 Web 可以使用 Session，需要分布式无状态验证时可以考虑 JWT，需要主动撤销令牌时可以考虑服务端管理的 Token。
实际如何选择
实际开发中，我会根据业务需求选择方案：传统 Web 可以使用 Session，需要分布式无状态验证时可以考虑 JWT，需要主动撤销令牌时可以考虑服务端管理的 Token。
具体选型过程可以按下面几步判断：
- 先判断是单体还是分布式系统。单体传统 Web 优先考虑 Session + Cookie，方案简单，服务端也容易控制会话。
- 再判断是否要求立即撤销。如果存在封禁账号、修改密码后全部下线等需求，服务端 Token 或集中式 Session 更直接。
- 如果服务很多，并且希望各服务独立验证身份，可以使用短期 JWT，但要同时设计 Refresh Token、密钥轮换和撤销机制。
- 如果需要接入微信、GitHub 等第三方账号，使用 OAuth 2.0，并通过 OpenID Connect 或第三方用户接口完成身份认证。
- 如果多个内部系统需要共享登录状态，使用 SSO，把认证职责集中到统一认证中心。
无论选择哪种方式，都需要使用 HTTPS，限制凭证有效期，区分认证与授权，并根据存储位置处理 XSS 和 CSRF 风险。登录成功只说明“你是谁”，接口能否访问还要继续判断“你有什么权限”。