HTTPS加密与JWT鉴权机制详解

1.HTTPS 数据传输加密流程

1. 1. 非对称加密（公钥/私钥）并不直接用于数据传输

• • 直接用公钥加密大量业务数据效率太低（RSA、ECC 这种算法比 AES 慢几个数量级）。
• • 实际上，非对称加密只用来 安全地交换对称密钥。

2. 2. 过程简化版

• • 客户端（浏览器）连接服务端时，服务端会把证书（包含公钥）发给客户端。
• • 客户端会生成一个随机的“会话密钥”（Session Key，通常是 AES/ChaCha20 之类的对称密钥）。
• • 客户端用服务端的公钥加密这个 Session Key，并发送给服务端。
• • 服务端用自己的私钥解密，得到同一个 Session Key。
• • 之后双方就都用这个 Session Key（对称密钥）来加解密数据。

3. 3. 所以

• • 非对称加密： 只在握手阶段使用，用来安全地分发会话密钥。
• • 对称加密： 一旦握手完成，绝大部分实际的数据传输都是用对称加密完成的。

---

📌 和 TLS1.2 相比，TLS1.3 的主要区别：

• • 🚀 握手更快（1-RTT，甚至支持 0-RTT）。
• • 🔑 不再直接用 RSA 公钥加密 Session Key，而是通过 ECDHE（椭圆曲线 Diffie-Hellman） 协商共享密钥。
• • 🔒 更安全（前向安全性：即使服务器私钥泄露，也无法解密过去的会话）。

---

2.两个服务间通过 非对称 JWT（比如 RS256/ES256）做鉴权

总体思路（一句话）

• • 用 服务 A（Issuer） 用自己的 私钥 签发 JWT（含 issuer/aud/exp/iat/jti 等），通过 HTTPS 调用时把 JWT 放在 Authorization: Bearer头；
• • 服务 B（Relying Party / Resource） 接收请求后，用 A 的公钥验证 JWT 的签名并校验声明（issuer/aud/exp/nbf/clock skew/jti 等），校验通过则认为调用方合法并执行授权逻辑。

---

2.1 端到端流程（步骤化）

1. 1. 密钥对生成与分发

• • 在 KMS（或 HSM）里生成非对称密钥对（RSA 或 ECC）。
• • 私钥仅存放在签发方安全环境（Issuer、KMS）中，不外泄。
• • 将公钥以 JWKS（JSON Web Key Set）或静态 PEM 暴露给被鉴权方（Resource）用于验证。建议托管一个 /jwks.json 或用配置中心分发并缓存。

2. 2. 签发 JWT（Issuer）

• • iss：签发者标识（比如 auth.myservice.internal）

• • sub：主体（client id 或 service id）

• • aud：目标服务或 API（保证只给目标消费）

• • exp：过期时间（短，建议几分钟到几小时）

• • iat：签发时间

• • jti：唯一 id（用于可选的撤销/防重放）

• • scp / roles / claims：权限信息

• • 构造 JWT header，比如 {“alg”:“RS256”,“typ”:“JWT”,“kid”:“key-id-1”}。kid 用于公钥轮换/选择。

• • 构造 payload（claims），常见：

• • 使用私钥签名（RS256/ES256 等），返回 compact JWT 字符串。

3. 3. 调用方把 JWT 放入请求头

• • Authorization: Bearer，通过 HTTPS 发送到 Resource。

4. 4. 接收方验证 JWT（Resource）

• • exp（过期）

• • nbf（生效时间，如果有）

• • iss（是否来自可信 issuer）

• • aud（是否面向本服务）

• • 时钟偏差（常用 ±30s）

• • 提取并解析 JWT header 找到 kid（若有）。

• • 从本地缓存或从 /jwks.json 获取对应公钥（按 kid 取），缓存并设置合理的过期。

• • 验证签名（用公钥 + 指定 alg），并严格拒绝 alg=none。

• • 校验标准声明：

• • 可选：校验 jti 是否在黑名单（用于撤销），或检查 sub 是否在允许列表等。

• • 通过后根据 scp/roles 做授权决策。

---

2.2 为什么公钥泄露不会导致伪造 JWT？

原因在于：

• • 非对称签名的本质

• • 签名：用 私钥 生成。

• • 验证：用 公钥 校验。

• • 任何人（包括第三方服务 C）即使拿到了公钥，也只能验证别人签的 JWT，而无法用公钥去生成一个合法签名。

• • 伪造 JWT 需要私钥

• • 只有持有私钥的一方才能产生有效的签名。

• • 公钥暴露给全世界都没关系，它就是拿来校验的。很多开放的 OAuth2 / OpenID Connect 平台（比如 Google、Auth0）都会把 JWKS（公钥集合）公开在 /.well-known/jwks.json，这是正常做法。

• • 真正的风险

• • 如果私钥泄露，那才是真的危险：任何人都能伪造合法 JWT。

• • 所以保护私钥（放在 KMS/HSM，限制权限，定期轮换）才是重中之重。

• • 一个额外的注意点

• • 即便公钥是公开的，你也要在验证时检查 JWT 的 iss（issuer）、aud（audience）等声明。

• • 否则，有人可能用其它系统签的合法 JWT 直接拿来访问你的服务（签名对得上，但不是你信任的 issuer）。

---

所以总结：

• • 公钥公开是安全的，不会导致伪造。
• • 只有私钥泄露才会有伪造风险。
• • 服务 B 验证时要 不仅看签名对不对，还要校验 iss/aud/exp 等声明，否则容易被“合法但不属于你系统的 token”误用。

---

2.3 JWT被截获（重放攻击）？

2.3.1 场景

• • A = 签发方（Issuer，Auth Service）
• • B = 资源服务（Resource，Service B）
• • C = 攻击者（或第三方系统）
• • A 给调用方签发了一个有效的 JWT，原本是给 B 用的。
• • 如果这个 token 被截获，C 拿着它直接请求 B，看起来就能“冒充”调用方。

---

2.3.2 为什么会这样？

JWT 本身 不是防窃听机制，它只解决了：

• • 签发者可验证：B 确认 token 来自 A
• • 不可篡改：签名确保内容不能改

但是：

• • JWT 只要被窃取（无论是网络截获还是日志泄露），在未过期之前就是一张有效的“门票”。
• • 这叫 Replay Attack（重放攻击）。

---

2.3.3 如何防止？

要避免“截获即复用”，常见的手段有：

1. 1. HTTPS 必须全程传输

• • 防止 token 在传输过程中被窃听。
• • 这是 JWT 安全的第一道防线。

2. 2. 设置较短的过期时间 (exp)

• • token 有效期不要太长（几分钟到几十分钟）。
• • 减少被窃取后可利用的时间窗口。

3. 3. 使用 aud（Audience）字段

• • 在 token 中声明目标服务（比如 aud = serviceB）。
• • B 只接受 aud=serviceB 的 token。
• • 即使 C 把 token 拿去请求别的系统，也会因为 aud 不匹配而失败。

4. 4. 绑定上下文（可选强化）

• • 比如在 token 中加入 sub（调用方 ID）、jti（唯一 ID）。
• • B 可以检测 jti 是否被重复使用（防重放）。
• • 甚至可以把 token 绑定到客户端证书/设备信息，但这通常需要额外的基础设施。

5. 5. 引入 Refresh Token + 短期 Access Token 模式

• • Access Token（JWT）很短命，被盗也没多大用处。
• • Refresh Token 只在和授权服务交互时使用，不直接对外暴露。

6. 6. 使用 mTLS（双向 TLS）

• • 只有握手时持有有效客户端证书的服务，才能和 B 建立连接。
• • 即使 JWT 泄露，没有证书也没法连上。

---

2.4 Refresh Token + Access Token

2.4.1 原理

• • Access Token（短期访问令牌）

• • 用来直接访问资源（API）。

• • 生命周期很短（比如 5-15 分钟）。

• • 被窃取也只能用很短时间。

• • Refresh Token（刷新令牌）

• • 生命周期很长（几个小时到几天甚至几周）。

• • 只在和认证服务器交互时使用，不直接调用资源服务。

• • 作用是 用来换新 Access Token。

• • 一般只保存在可信的客户端或安全存储中。

---

2.4.2 特点

• • 安全性提升：Access Token 短命，被截获损失可控；Refresh Token 不会频繁出现在网络请求中。
• • 用户体验好：用户不用频繁登录，因为客户端可以自动刷新 Access Token。
• • 可控性：Refresh Token 可以在服务端主动撤销（踢出用户），比单纯的 JWT 可控。

---

2.4.3 典型流程

1. 1. 用户登录 / 授权

• • 客户端向授权服务（Auth Server / Identity Provider）申请 Token。
• • 返回 Access Token + Refresh Token。

2. 2. 客户端调用 API

• • 带着 Access Token 调用资源服务（Resource Server）。

3. 3. Access Token 过期

• • 客户端用 Refresh Token 向授权服务申请新的 Access Token。
• • 授权服务验证 Refresh Token 的合法性 → 返回新的 Access Token（可能还返回新的 Refresh Token）。

4. 4. 循环使用

• • 只要 Refresh Token 没过期，就可以不停换新的 Access Token。
• • 如果 Refresh Token 被吊销（比如用户退出登录），那就彻底失效。

---

2.4.4 Refresh token 安全保证

如果 Refresh Token 被截获，意味着攻击者可以不断拿它去换新的 Access Token，从而“长期持有”用户身份。

---

🔑防御机制

1. 1. 短期 Refresh Token + Rotation（轮换刷新）

• • 不要让 Refresh Token 永久有效。
• • 每次用 Refresh Token 换新 Access Token 时，授权服务器会：

1. 1. 签发一个新的 Refresh Token（替换旧的）。
2. 2. 立即废弃旧的 Refresh Token。

• • 如果攻击者拦截了旧的 Refresh Token 并尝试再用一次，授权服务器会发现这是“重放攻击”，直接拒绝并吊销会话。

👉 这叫 Refresh Token Rotation，OAuth2.1 标准也推荐这么做。

---

1. 2. 绑定客户端/设备

• • Refresh Token 在签发时绑定到某个 客户端 ID / 设备指纹。
• • 拿到 Refresh Token 的请求如果不是来自绑定的客户端，就拒绝。
• • 有的实现还会绑定 IP 地址、User-Agent 等上下文信息。

---

1. 3. 存储保护

• • 客户端必须妥善保存 Refresh Token：

• • 移动端：存安全存储区（如 iOS Keychain，Android Keystore）。

• • Web 应用：不要存到 localStorage，建议用 HttpOnly + Secure Cookie。

• • 不要通过 URL 传递 Refresh Token（避免出现在日志）。

---

1. 4. 服务端控制 & 黑名单

• • 授权服务器会维护 Refresh Token 的状态：

• • 是否已使用（轮换模式下）

• • 是否已吊销（用户登出、管理员强制下线）

• • 可以支持黑名单机制，随时让某个 Refresh Token 失效。

---

1. 5. 缩短有效期 + 分层 TTL

• • 例子：

• • Access Token：5-15 分钟

• • Refresh Token：1-2 小时（配合 Rotation 可延长）

• • 如果攻击者窃取了 Refresh Token，也只能使用有限时间。

---

文章来自网上，侵权请联系博主

互动话题：如果你想学习更多网安方面的知识和工具，可以看看以下题外话！

学习资源

如果你是也准备转行学习网络安全（黑客）或者正在学习，这里开源一份360智榜样学习中心独家出品《网络攻防知识库》,希望能够帮助到你

知识库由360智榜样学习中心独家打造出品，旨在帮助网络安全从业者或兴趣爱好者零基础快速入门提升实战能力，熟练掌握基础攻防到深度对抗。

1、知识库价值

深度： 本知识库超越常规工具手册，深入剖析攻击技术的底层原理与高级防御策略，并对业内挑战巨大的APT攻击链分析、隐蔽信道建立等，提供了独到的技术视角和实战验证过的对抗方案。

广度： 面向企业安全建设的核心场景（渗透测试、红蓝对抗、威胁狩猎、应急响应、安全运营），本知识库覆盖了从攻击发起、路径突破、权限维持、横向移动到防御检测、响应处置、溯源反制的全生命周期关键节点，是应对复杂攻防挑战的实用指南。

实战性： 知识库内容源于真实攻防对抗和大型演练实践，通过详尽的攻击复现案例、防御配置实例、自动化脚本代码来传递核心思路与落地方法。

2、 部分核心内容展示

360智榜样学习中心独家《网络攻防知识库》采用由浅入深、攻防结合的讲述方式，既夯实基础技能，更深入高阶对抗技术。

360智榜样学习中心独家《网络攻防知识库》采用由浅入深、攻防结合的讲述方式，既夯实基础技能，更深入高阶对抗技术。

内容组织紧密结合攻防场景，辅以大量真实环境复现案例、自动化工具脚本及配置解析。通过策略讲解、原理剖析、实战演示相结合，是你学习过程中好帮手。

1、网络安全意识

2、Linux操作系统

3、WEB架构基础与HTTP协议

4、Web渗透测试

5、渗透测试案例分享

6、渗透测试实战技巧

7、攻防对战实战

8、CTF之MISC实战讲解

3、适合学习的人群

‌一、基础适配人群‌

1. ‌零基础转型者‌：适合计算机零基础但愿意系统学习的人群，资料覆盖从网络协议、操作系统到渗透测试的完整知识链‌；
2. ‌开发/运维人员‌：具备编程或运维基础者可通过资料快速掌握安全防护与漏洞修复技能，实现职业方向拓展‌或者转行就业；
3. ‌应届毕业生‌：计算机相关专业学生可通过资料构建完整的网络安全知识体系，缩短企业用人适应期‌；

‌二、能力提升适配‌

1、‌技术爱好者‌：适合对攻防技术有强烈兴趣，希望掌握漏洞挖掘、渗透测试等实战技能的学习者‌；

2、安全从业者‌：帮助初级安全工程师系统化提升Web安全、逆向工程等专项能力‌；

3、‌合规需求者‌：包含等保规范、安全策略制定等内容，适合需要应对合规审计的企业人员‌；

因篇幅有限，仅展示部分资料，完整版的网络安全学习资料已经上传CSDN，朋友们如果需要可以在下方CSDN官方认证二维码免费领取【保证100%免费】

🐵这些东西我都可以免费分享给大家，需要的可以点这里自取👉:网安入门到进阶资源