认证系统里的名词很多：Cookie、Session、Token、JWT、OAuth2、OIDC、授权码、客户端模式、资源服务器、认证服务器。真正落地时，最先要做的不是背协议细节，而是把边界分清楚。
这篇从后端工程角度梳理几个常用概念，重点放在“它们各自解决什么问题”。
认证和授权不是一回事
认证回答的是：你是谁。比如用户名密码、短信验证码、扫码登录、生物特征，都属于认证。
授权回答的是：你能访问什么。比如某个用户能不能看订单、某个应用能不能调用接口、某个 token 是否带有指定 scope。
OAuth2 更偏授权框架。它定义了客户端、资源所有者、授权服务器、资源服务器之间如何拿到访问凭据。很多系统也会把登录和 OAuth2 放在一起做，但心里要清楚：登录只是认证，后续访问资源还要做授权。
Cookie 和 Session 是传统 Web 会话方案
HTTP 本身是无状态的。服务端不知道下一次请求是不是同一个用户，所以需要某种凭据。
传统方案是 Session：
- 用户登录成功。
- 服务端创建一份会话数据。
- 浏览器拿到一个 SessionID。
- SessionID 通常放在 Cookie 里。
- 后续请求带上 Cookie，服务端根据 SessionID 找会话。
它的好处是服务端掌控强，想让会话失效比较容易。缺点是服务端需要存会话，多实例部署时还要考虑共享 Session、Redis 存储、过期时间和清理策略。
Cookie 本身只是浏览器存储和自动携带的一种机制。不要把 Cookie 和 Session 混为一谈。Cookie 可以放 SessionID，也可以放其他标记；Session 是服务端维护的会话状态。
Token 更适合多端和接口调用
Token 是调用接口时携带的一段访问凭据。常见方式是登录后服务端签发 access token，客户端后续请求在 Header 里带上它。
Token 可以是有状态的，也可以是无状态的。
有状态 token 需要服务端查存储，比如 Redis 里存 token 元数据。好处是可撤销、可控，缺点是每次校验要访问存储。
无状态 token 常见代表是 JWT。服务端用密钥校验签名，解析出用户、过期时间和权限信息。好处是校验快、少查存储，缺点是签发后不容易主动失效，除非再引入黑名单、版本号或短过期时间。
选哪种方式，不是看哪个更“先进”，而是看业务是否需要强撤销、唯一在线、跨端控制、权限实时变更和审计追踪。
OAuth2 常见模式怎么选
OAuth2 有多种授权模式，日常工程里最常见的是：
- 授权码模式：适合浏览器跳转、第三方登录、前后端分离配合 PKCE。
- 客户端模式：适合服务和服务之间调用，没有具体用户参与。
- 密码模式：把用户名密码直接交给客户端，信任要求高，现代系统里要慎用。
- 刷新令牌：用于 access token 短过期后的续期。
自建认证中心时，授权服务器负责签发令牌、校验客户端、处理授权流程；资源服务器负责保护业务接口，校验 token 后再执行业务授权。
不要把认证中心写成“顺手处理业务”的大服务。它的边界应该清楚：签发、校验、撤销、客户端注册、会话管理、用户中心调用。业务规则仍然放在下游业务系统。
Spring Security 和认证中心落地要点
Spring Security 或 Spring Authorization Server 这类框架能提供很多基础能力，但真正项目化时，通常还要处理这些扩展点：
- 客户端信息从数据库、Redis 或远程服务读取。
- 用户信息从用户中心或账号服务读取。
- 登录成功后的统一 JSON 响应。
- 资源服务器的 JWT 校验。
- 登出、撤销和刷新令牌。
- 验证码、异常码和下游接口透传。
- 会话从内存迁移到 Redis。
这些都不是简单引一个依赖就结束。每个扩展点都要有明确的测试链路，尤其是授权码、刷新、撤销、过期、登出和多端登录。
安全边界要提前写清楚
认证系统最怕“先跑起来再说”。上线前至少要确认：
redirect_uri是否严格匹配。- 客户端凭据是否按环境隔离。
- 私钥、密钥和 token 签名材料没有暴露在代码和日志里。
- access token 过期时间是否合理。
- refresh token 是否能撤销。
- 资源服务器是否真的校验签名和过期时间。
- 前端把 token 放 Cookie 还是 localStorage，风险是否接受。
- introspect、revoke 等接口是否有客户端权限控制。
如果一个接口只要拿到 token 和 client 凭据就能查到用户信息，那它本身就是敏感接口，不能默认对所有客户端开放。
最后用一句话记住
Cookie 是浏览器携带机制，Session 是服务端会话状态，Token 是接口访问凭据，OAuth2 是授权框架，认证中心是把这些能力按边界组织起来的服务。
先分清职责，再谈框架选型。否则很容易把登录、授权、用户中心、业务权限和会话管理揉成一团，后面排查问题会非常痛苦。
