一位后端开发者第三次删掉自己写的令牌验证模块后，终于决定彻底拥抱 OAuth2 和 JWT。他苦笑：“每次新项目都要重造一遍轮子，轮子还总漏风。”API 是攻击者的高频目标，身份验证和鉴权却是很多新手最头疼的地狱模式——既要挡住坏人，又不能把正经用户拦在门外。

OAuth2 和 JWT 不是二选一的竞品，而是天生一对的搭档。一个负责委托授权，一个提供紧凑可靠的信息载体，让令牌的签发、校验、权限管理不再是一团乱麻。下面就用五件事，帮你一口气弄懂这套组合拳。

打开网易新闻 查看精彩图片

1. 你的 API 在裸奔，坏人就盯着它
API 直接暴露数据与功能，没有一道靠谱的“门卫”，等于把所有接口敞开给攻击者扫。常见做法是自己写 Token 生成逻辑，再配上散落在各处的权限判断——结果要么签发逻辑有漏洞，要么一个疏忽就把不该给的数据泄了出去。OAuth2 + JWT 把发牌和验牌拆成两件事，让专业分工替你填上这些坑。

2. 认证是“你是谁”，授权是“你能干嘛”
别再把这两个概念搅在一起。认证靠密码、令牌或证书证实身份，JWT 就像一张电子身份证，里面可以写上角色和权限声明。授权则是决定这个身份能碰哪些资源、允许什么操作。用 OAuth2 的术语说，JWT 是那张“门禁卡”，OAuth2 规定卡片怎么发、怎么验、过期了该怎么办。

3. OAuth2：只管发令牌的“牌局总监”
OAuth2 是一套委托授权的框架，用户不必把密码直接交给第三方应用，而是授权给它一个代表权限的令牌。你的后端（扮演资源服务器）根本不用亲自签发令牌，它只负责信任并校验授权服务器发来的令牌。这种职责解耦让 API 精简到只剩两件事：接收 Bearer Token，然后验签名、查过期、核对作用域和角色。发牌、登录跳转这些麻烦事全交给授权服务器。

4. JWT：小巧到可以塞进 HTTP 头的信息包裹
JWT 是一种紧凑、Web 友好的字符串，靠 Base64URL 编码，随便放在 Header 或查询参数里都不会出乱码。每个令牌要么带签名，要么加密，接收方能验明来源是否可信。它把用户标识、过期时间、权限范围全部打包进一段文本，解析快，跨系统传递零负担。正因为足够轻量，才跟 OAuth2 这种集中发牌、分布式验牌的模式完美适配。

5. 你的资源服务器只需要当“验牌员”
资源服务器不必关心用户怎么登录、浏览器怎么跳转，它的唯一职责是：拿到令牌→核对签名→检查是否过期→按作用域/角色放行。就像门卫只认工牌真假，不负责印工牌。这样一来，API 的安全策略变得统一透明，每一次校验都走同一套规则，再也不会出现 A 模块宽松、B 模块乱拒绝的割裂局面。

把 OAuth2 作为授权骨架，用 JWT 承载紧凑可信的身份声明，等于用一套标准化的流程替换掉所有自研的临时方案。这篇教程后续还将推出基于 Ktor 协程的配套文章，如果你正在用 Spring Boot 构建后端，不妨现在就试试这种“只验牌、不造牌”的安全架构。