还在手写JWT鉴权？我劝你把OAuth2这层护城河挖深点

“鉴权”这两个字，在多数开发团队的日常里，存在感低得可怜。项目启动时，从某个开源模板里扒拉出一段JWT签发与校验的代码，塞进拦截器，跑通登录流程，这事就算翻篇了。直到某天，产品经理提了个需求：第三方合作方要接入我们的用户体系，只读取订单数据，不能碰其他接口。你打开代码一看，手里只有一张用户表和一个全局的token校验逻辑，瞬间头皮发麻。这时候你才会意识到，手写JWT那套东西，从第一天起就埋下了无法扩展的基因缺陷。

JWT本身没有错，它轻量、自包含、跨语言友好，作为身份断言（assertion）的载体非常合格。问题出在“手写”二字上。多数团队手写JWT鉴权，本质上是在重复实现一个残缺的授权服务器：自己签发token、自己维护黑名单、自己处理刷新逻辑、自己定义payload里的角色字段。这套东西在单体应用里勉强能转，一旦遇到多端登录、服务拆分、第三方授权，立刻捉襟见肘。更隐蔽的风险在于，很多人把JWT当成了会话管理的银弹，在payload里塞用户角色、权限列表甚至敏感业务字段，然后指望前端解析后做菜单控制。这等于把授权决策权交给了客户端，服务端只验签不验权，越权漏洞就这么来的。

真正该挖深的地方，是OAuth2这层授权框架。注意，我说的是授权框架，不是某个具体的协议实现。OAuth2解决的核心问题是：在资源拥有者（用户）不直接交出凭证的前提下，让客户端获得有限的、可撤销的、范围明确的访问权限。这个模型天然适配现代软件的多角色协作场景。把OAuth2的授权码模式、客户端凭证模式、隐式模式（虽然已不推荐）理解透，你会发现手写JWT那套东西，只是OAuth2流程末端的一个环节——令牌的格式选择而已。JWT可以是OAuth2的access token载体，但OAuth2远不止签发一个JWT那么简单。

先说授权码模式，这是最该吃透的。很多开发者觉得它绕：前端跳转授权页、拿code、后端换token，为什么不直接发token给前端？因为code是一次性的、短命的、且只能由后端兑换。这一层设计把access token彻底隔离在前端之外，前端拿到的只是code，即使被截获，攻击窗口也极小。手写JWT鉴权往往省掉了这一层，直接让前端持有长期token，XSS一打一个准。把授权码模式落地，配合PKCE（Proof Key for Code Exchange）应对公共客户端，才是移动端和SPA的正确姿势。PKCE的code_verifier和code_challenge机制，本质上是在没有客户端密钥的场景下，用数学方法证明“换token的请求来自发起授权的那一方”，这个思路比手写一个refresh token轮换逻辑要严谨得多。

再说令牌的生命周期管理。OAuth2框架里，access token短命、refresh token长命但一次性使用（或轮换使用），这是标准操作。手写JWT的团队往往只发一个长效token，过期时间设个七天，刷新逻辑靠前端定时器重新登录。这种设计在安全审计里是过不了关的。OAuth2的refresh token轮换机制，配合令牌撤销端点（revocation endpoint），能实现“用户改密码后所有已签发令牌立即失效”这种刚需。手写方案要实现同等效果，得自己维护一张令牌状态表，每次请求都查库，性能和安全两头不讨好。而OAuth2框架下，令牌内省（introspection）端点让资源服务器可以实时校验令牌状态，同时把校验逻辑集中到授权服务器，资源服务器只做无状态验签，架构上干净得多。

还有scope（授权范围）这个概念，是手写JWT最容易忽略的。多数手写方案里，权限控制靠角色字段，粗粒度地判断“是不是管理员”。但真实业务里，权限是细碎且动态的：第三方物流系统只需要读取订单发货状态，不需要看到用户手机号；内部客服系统可以查用户资料，但不能修改订单金额。OAuth2的scope机制，让客户端在发起授权请求时就声明所需权限范围，授权服务器在签发令牌时把scope写入令牌，资源服务器按scope做细粒度校验。这套模型把“谁能访问什么”从代码里的if-else判断，变成了可配置、可审计的授权策略。配合RBAC或ABAC做策略决策，整个权限体系的可维护性会上一个台阶。

当然，挖深OAuth2不是让你自己从头造一个授权服务器。市面上有成熟的开源实现和云服务，选型时关注几个关键点：是否支持授权码+PKCE、是否支持令牌轮换与撤销、是否提供内省端点、是否支持scope细粒度控制、是否兼容OIDC（OpenID Connect）做身份认证。OIDC是在OAuth2之上的身份层，补足了“用户是谁”这个信息，返回ID Token（本身也是JWT），但它的签发和校验由授权服务器统一负责，业务代码只需要信任授权服务器的公钥。这种分工让鉴权逻辑从业务代码里彻底剥离，安全边界清晰。

回到标题那句话。手写JWT鉴权不是原罪，但它往往意味着团队把授权当成了一个顺带实现的功能，而不是一个需要独立设计的架构层。OAuth2这层护城河，挖的不是代码量，而是对授权模型的认知深度：理解授权码为什么绕、refresh token为什么要轮换、scope为什么比角色字段更灵活、内省端点为什么能解决令牌撤销难题。把这些想清楚，再回头看那段手写的JWT拦截器，你会庆幸自己没在第三方接入的需求砸过来时才临时抱佛脚。鉴权这事，平时不显山露水，一旦出事就是系统性风险。把OAuth2的底子打牢，比在拦截器里堆一百行if-else要踏实得多。