认证协议：OAuth 2.0 和 JWT的学习总结

生活化场景说明OAuth 2.0 和 JWT

  • OAuth 2.0（酒店门禁）

用户（房客）把门禁权限委托给酒店前台（授权服务器），清洁工（第三方应用）拿到临时门卡（access token）就能进门打扫，但开不了保险箱（敏感操作）。这个场景能覆盖四个核心角色和token流转逻辑。

  • JWT（带防伪印章的体检报告）

医生（资源服务器）拆开信封就能看到所有健康数据（payload），印章（签名）保证没人篡改

  • OAuth 是钥匙 ；JWT 是信息包

JWT常作为OAuth的token载体。就像酒店给的门卡（OAuth token）里嵌入了房客身份信息（JWT），保安刷卡时能直接显示房号而不查数据库
微信登录用OAuth流程，返回的token如果是JWT格式就能直接解析用户昵称

一、OAuth 2.0：授权委托协议 (借钥匙协议)

核心问题 OAuth 解决

  • 想象一下：你有一个装满私人照片的网盘（资源服务器）。现在有一个在线打印店（第三方应用）说可以帮你把照片打印成精美相册。打印店需要访问你的照片才能工作。
  • 最差的做法： 你把网盘的用户名和密码直接告诉打印店。这太危险了！打印店不仅能看到你所有照片，还能删除、修改它们，甚至用你的账号干别的事。
  • OAuth 要解决的问题： 如何让打印店只获得访问你照片的权限，而不需要知道你的网盘密码？并且，你还能控制这个权限的范围（比如只读）和有效期。

OAuth 2.0 是怎么做的？（授权码模式 - 最常见）

把它想象成一个“借钥匙”的过程，涉及几个角色：

  1. 你 (资源拥有者)： 拥有照片的人。
  2. 你的网盘 (资源服务器)： 存放照片的地方。
  3. 打印店 (第三方应用/客户端)： 想访问你照片的应用。
  4. 网盘公司 (授权服务器)： 管理用户账号和权限发放的官方机构（通常和资源服务器是同一家）。

步骤：

  1. 打印店请求授权： 你去打印店下单。打印店说：“我们需要访问你网盘里‘度假照片’文件夹的照片。请去网盘公司官方认证页面确认一下。”
  2. 你登录并授权 (关键！)： 你被重定向到网盘公司的官方登录页面。你输入自己的用户名和密码（只给网盘公司看！）。登录后，页面问你：“打印店申请访问你的‘度假照片’文件夹，权限是【只读】，有效期1小时。同意吗？”
  3. 你同意授权： 你点击“同意”。网盘公司认证服务器记录下你的授权决定。
  4. 授权码： 网盘公司服务器生成一个一次性的、短命的“授权码”，通过浏览器重定向回传给打印店。
  5. 打印店换取“钥匙”： 打印店拿到授权码后，连同它自己的身份证明（App ID + Secret），直接（不经过你的浏览器）发送给网盘公司的授权服务器，说：“看，用户给了我授权码，请给我真正的‘钥匙’吧。”
  6. 发放“钥匙”： 网盘公司授权服务器验证打印店的身份和授权码有效后，颁发一个 Access Token (访问令牌)。这就是那把“钥匙”！同时可能还会发一个 Refresh Token (刷新令牌，用于在钥匙快过期时换新钥匙)。
  7. 打印店使用“钥匙”： 打印店拿着 Access Token 去访问你的网盘（资源服务器），说：“用户授权我来拿‘度假照片’文件夹的照片，这是凭证（Token）。” 网盘服务器验证这个 Token 确实是自家授权服务器发的、且有效、且权限匹配（只读、特定文件夹），就把照片给打印店了。
  8. 你用后即焚 (可选)： 打印店完成工作后，可以主动归还钥匙（使 Token 失效），或者钥匙自己到期（Token 过期）。

OAuth 2.0 的精髓

  • 你不需要告诉第三方应用你的密码！ 密码只给受信任的官方（授权服务器）。
  • 细粒度控制： 你可以控制应用能访问什么（范围 Scope：如只读照片）、能访问多久（Token 有效期）。
  • 随时撤销： 你可以在网盘公司的设置里随时撤销对某个应用的授权，那把“钥匙”就立刻失效了。
  • 应用独立认证： 第三方应用也需要向授权服务器证明自己是谁（App ID + Secret）。

通俗总结 OAuth 2.0： 它是一套标准流程，让你可以安全地授权一个应用（比如打印店）去访问你在另一个服务（比如网盘）上的特定资源（比如照片），而无需把你的密码告诉那个应用。核心是颁发一个代表特定权限的、有时效的“令牌”（Access Token）给第三方应用。

二、JWT：信息包装和验证标准 (带印章的纸条)

核心问题 JWT 解决

  • 在 OAuth 2.0 里，最后给第三方应用的是 Access Token。这个 Token 是什么？可以是一个随机的字符串（像酒店房卡号），服务器需要查数据库才能知道这个 Token 对应哪个用户、有什么权限。
  • JWT 提供另一种思路： 能不能把这个 Token 本身就包含用户信息和权限？就像一个自带信息的证件，服务器只要验证这个证件是真实有效的，就能直接读取里面的信息，不用每次都查数据库。这就是 JWT。

JWT 是什么？

JWT 全称 JSON Web Token。你可以把它想象成一张经过防伪处理、自带信息的纸条。它由三部分组成，用点 . 连接：Header.Payload.Signature

  1. Header (头)： 说明这个 JWT 的类型（JWT）和用了什么签名算法（比如 HMAC SHA256 或 RSA）。就像纸条的抬头，说明了纸条的格式和防伪方式。
    • 示例： {"alg": "HS256", "typ": "JWT"} (然后用 Base64 编码)
  2. Payload (载荷)： 这里存放实际要传递的信息，也叫 Claims (声明)。通常包含：
    • 标准声明：如 签发者 (iss)、过期时间 (exp)、受众 (aud)、生效时间 (iat) 等。
    • 自定义声明： 这才是核心！ 比如用户ID (sub)、用户名、用户角色、权限范围 (scope) 等。你想让 Token 携带什么信息都可以放这里（注意不要放敏感信息如密码）。
    • 示例： {"sub": "1234567890", "name": "小明", "iat": 1516239022, "exp": 1516239322, "scope": "read:photos"} (然后用 Base64 编码)
  3. Signature (签名)： 这是最关键的部分，用于防伪！
    • 服务器用 Header 里声明的算法，一个只有服务器自己知道的密钥 (Secret Key) 或 私钥 (Private Key)，对 Header + '.' + Payload 进行签名计算。
    • 计算结果就是 Signature。它像是一个独特的“防伪印章”或“指纹”。

最终 JWT = Base64(Header) + '.' + Base64(Payload) + '.' + Base64(Signature)

JWT 怎么工作？（以 OAuth Access Token 为例）

  1. 签发： 授权服务器验证用户身份和授权后，生成包含用户信息和权限的 Payload，加上 Header，然后用密钥生成 Signature，组合成 JWT 发给客户端（打印店）。
  2. 传递： 客户端拿着这个 JWT（作为 Access Token）去访问资源服务器（网盘）。
  3. 验证： 资源服务器收到 JWT：
    • 检查签名： 用预先和授权服务器约定好的密钥（或授权服务器的公钥）重新计算 Header + '.' + Payload 的签名。如果计算出来的签名和 JWT 里的 Signature 完全一致，就证明：
      • 这个 JWT 是合法的授权服务器签发的（因为只有它知道密钥或持有私钥）。
      • JWT 的内容（Header + Payload）在传输过程中没有被篡改（改一点签名就对不上）。
    • 检查有效期： 读取 Payload 里的 exp (过期时间) 和 iat (签发时间)，确认 Token 没有过期。
    • 检查权限： 读取 Payload 里的 scope 等信息，确认客户端请求的操作（如读取照片）在授权范围内。
  4. 处理请求： 验证通过后，资源服务器直接读取 Payload 里的信息（如用户ID sub），就知道是谁在访问、有什么权限，然后处理请求（返回照片）。整个过程不需要去查数据库验证 Token 有效性！

JWT 的精髓

  • 自包含： Token 本身携带了有用的信息（Payload）。
  • 可验证： 通过签名机制，接收方可以验证 Token 是谁发的、内容是否被篡改。签名是核心安全机制。
  • 无状态： 资源服务器不需要存储 Token 的状态（如 Session），只需验证签名和有效期即可。这使得扩展（加服务器）更容易。
  • 灵活： Payload 可以自定义各种你需要的信息。

通俗总结 JWT： 它是一种标准格式的“加密小纸条”（JSON Web Token）。这个小纸条自身就写明了包含哪些用户信息（Payload），并且带有一个特殊的防伪印章（Signature）。服务器只需要验证这个印章是真的（用密钥或公钥），就能完全信任纸条上写的信息是真实、未被篡改的。它常用于作为 OAuth 2.0 的 Access Token，让资源服务器能快速验证请求者身份和权限。

OAuth 2.0 和 JWT 的关系

  • OAuth 2.0 是一个授权框架： 它定义了流程（怎么借钥匙），规定了角色（你、网盘、打印店、网盘公司），以及核心概念（授权、Access Token）。
  • JWT 是一种 Token 的实现方式： 它定义了 Access Token（钥匙）可以长什么样、里面装什么信息、如何保证这个钥匙是真实可靠的（通过签名）。
  • OAuth 2.0 不强制规定 Token 格式： Access Token 可以是一个随机字符串（不透明令牌），也可以是一个 JWT（自包含令牌）。JWT 是 OAuth 2.0 中 Access Token 的一种非常流行和有用的格式选择。
  • JWT 不局限于 OAuth： JWT 也可以用在其他需要安全传递信息的场景，比如用户登录后，服务器生成一个包含用户ID的 JWT 返回给浏览器（作为 Session Token），浏览器后续请求带上它，服务器验证签名就能知道用户是谁。

简单来说：OAuth 2.0 是“怎么安全地借钥匙”的规则说明书，而 JWT 是一种“自带身份信息和防伪标识的智能钥匙”的制作标准。 OAuth 2.0 可以选择使用 JWT 这种智能钥匙。

posted @ 2025-08-12 13:50  hqq的进阶日记  阅读(59)  评论(0)    收藏  举报