惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

MongoDB | Blog
MongoDB | Blog
V
V2EX
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
有赞技术团队
有赞技术团队
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
罗磊的独立博客
月光博客
月光博客
爱范儿
爱范儿
D
Docker
U
Unit 42
P
Proofpoint News Feed
I
InfoQ
腾讯CDC
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
L
LangChain Blog
V
Visual Studio Blog
IT之家
IT之家
Vercel News
Vercel News
G
Google Developers Blog
M
MIT News - Artificial intelligence
美团技术团队
The GitHub Blog
The GitHub Blog
阮一峰的网络日志
阮一峰的网络日志
MyScale Blog
MyScale Blog

Jiajun的技术笔记

你好,2026! TiDB 源码阅读(六):TiDB Coprocessor 源码解析 性能优化的核心思想 TiDB 源码阅读(五):索引 TiDB 源码阅读(四):AST、逻辑计划、物理计划 CockroachDB Serverless Architecture podman 无故退出 Cursor Control-L (CTRL-L) Keyboard Shortcuts in Terminal Replace docker with podman Using xmonad with xfce4 A RC script for freebsd frpc 自己动手写一个k8s controller AI 会取代你的(编程)岗位吗? 自建DERP服务器提升Tailscale连接速度(使用Nginx转发) 自动升级Docker容器 再读《程序员修炼之道-从小工到专家》 让浏览器下载文件 再读《软件随想录》/《黑客与画家》/《软技能》 HTTP 压力测试中的 Coordinated Omission 2的补码 编程语言中的 context 是什么? flutter macOS 构建出错 Flatpak 使用小记 Golang CAS 操作是怎么实现的 PostgreSQL 当MQ来使用 Clash 结合 工作VPN 的网络设计 使用 PostgreSQL 搭建 JuiceFS PostgreSQL 配置优化和日志分析 有GitHub Copilot?那就可以搭建你的ChatGPT4服务 窗口函数的使用(以PG为例)
OAuth 2 详解(六):Authorization Code Flow with PKCE
Jiajun Huang · 2022-10-12 · via Jiajun的技术笔记

我们在前面了解到,Authorization Code 模式是最安全的一种模式,但是必须要有服务端参与进来,因为 client_secret 必须保存在 服务端才安全。OAuth 2.0 在 RFC7636 中定义了一种扩展模式,这种模式下,客户端 不需要使用 client_secret,模式中 PKCE 的全称是 Proof Key for Code Exchange。那怎么理解这个呢?简单来说,就是我们仍然 使用 Authorization Code 模式的流程,但是原来是需要服务端参与保存 client_secret,现在改成客户端临时生成一对密钥。

Authorization Code Flow with Proof Key for Code Exchange (PKCE)

  1. 用户点击登录按钮
  2. 应用生成 code_verifier,是一个随机值,然后对 code_verifier 做sha256,得到哈希值 code_challenge
  3. 应用携带 client_id, code_challenge 请求 Authorization Server
  4. Authorization Server 提示用户是否授权
  5. 用户点击同意授权
  6. Authorization Server 生成 code,同时保存 code_challenge
  7. 应用使用 codecode_verifier 请求 Authorization Server
  8. Authorization Server 对 code_verifier 做sha256,得到哈希值,与 code_challenge 对比
  9. 对比成功,下发 access_token
  10. 应用请求资源
  11. access_token 校验通过,返回响应

为什么这样可以保证安全性?

首先临时生成一个 code_verifier,保存在本地,然后将 code_challenge 发给服务端,服务端进行保存,然后换取 access_token 时,再将 code_verifier 提交上去,如果黑客获取了 code_challenge,他也无法进行下一步操作,如果黑客获取了 code_verifier, 他虽然可以获得 access_token,但是无法使用 code_verifier 再次获取,因为 code_verifiercode_challenge 是一对临时 生成的随机密钥(准确来说是一个随机值和随机值的哈希值)。

如果是客户端直接保存了 client_secret 那就不一样了,黑客获取之后,总是可以通过 client_secretcode 来换取 access_token。 这就是这种模式的安全所在。

总结

这就是我们看到的第六种OAuth授权模式,整个系列也就到此结束了。希望对读者有所帮助。


refs: