慣性聚合 高效追蹤和閱讀你感興趣的部落格、新聞、科技資訊
閱讀原文 在慣性聚合中打開

推薦訂閱源

博客园 - 司徒正美
V
V2EX
T
Tailwind CSS Blog
有赞技术团队
有赞技术团队
aimingoo的专栏
aimingoo的专栏
Apple Machine Learning Research
Apple Machine Learning Research
IT之家
IT之家
Blog — PlanetScale
Blog — PlanetScale
A
About on SuperTechFans
月光博客
月光博客
T
The Blog of Author Tim Ferriss
宝玉的分享
宝玉的分享
Martin Fowler
Martin Fowler
博客园 - 聂微东
The GitHub Blog
The GitHub Blog
V
Visual Studio Blog
WordPress大学
WordPress大学
酷 壳 – CoolShell
酷 壳 – CoolShell
Engineering at Meta
Engineering at Meta
GbyAI
GbyAI

阮一峰的网络日志

科技爱好者周刊(第 396 期):互联网通信的替代方案 科技爱好者周刊(第 396 期):互联网通信的替代方案 - 阮一峰的网络日志 科技爱好者周刊(第 395 期):软件开发的第三种方式 科技爱好者周刊(第 395 期):软件开发的第三种方式 - 阮一峰的网络日志 科技爱好者周刊(第 393 期):脑腐状态 科技爱好者周刊(第 392 期):axios 投毒与好莱坞式骗术 科技爱好者周刊(第 391 期):AI 的贫富分化 科技爱好者周刊(第 390 期):没有语料,大模型就是智障 套壳中国大模型撑起500亿美元估值?扒一扒 Cursor 的"套壳"疑云 科技爱好者周刊(第 389 期):未来如何招聘程序员 科技爱好者周刊(第 388 期):测试是新的护城河 零安装的"云养虾":ArkClaw 使用指南 科技爱好者周刊(第 387 期):你是领先的 科技爱好者周刊(第 386 期):当外卖员接入 AI 字节全家桶 Seed 2.0 + TRAE 玩转 Skill 科技爱好者周刊(第 385 期):马斯克害怕中国车企吗? 智谱旗舰 GLM-5 实测:对比 Opus 4.6 和 GPT-5.3-Codex 科技爱好者周刊(第 384 期):为什么软件股下跌 科技爱好者周刊(第 383 期):你是第几级 AI 编程 Kimi 的一体化,Manus 的分层 科技爱好者周刊(第 382 期):独立软件的黄昏 AI native Workspace 也许是智能体的下一阶段 科技爱好者周刊(第 381 期):中国 AI 大模型领导者在想什么 科技爱好者周刊(第 380 期):为什么人们拥抱"不对称收益" 科技爱好者周刊(第 379 期):《硅谷钢铁侠》摘录 我如何用 AI 处理历史遗留代码:MiniMax M2.1 升级体验 科技爱好者周刊(第 378 期):预测是新的互联网热点 科技爱好者周刊(第 377 期):14万美元的贫困线 科技爱好者周刊(第 376 期):太空数据中心的争议 科技爱好者周刊(第 375 期):一扇门的 Bug 终于有人做了 Subagent,TRAE 国内版 SOLO 模式来了 科技爱好者周刊(第 374 期):6GHz 的问题 VS Code 使用国产大模型 MiniMax M2 教程 科技爱好者周刊(第 373 期):数据模型是新产品的核心 国产大模型接入 Claude Code 教程:以 Doubao-Seed-Code 为例 科技爱好者周刊(第 372 期):软件界面如何设计 大模型比拼:MiniMax M2 vs GLM 4.6 vs Claude Sonnet 4.5 科技爱好者周刊(第 371 期):一个乐观主义者的专访 科技爱好者周刊(第 370 期):正确的代码高亮 错误处理:异常好于状态码 科技爱好者周刊(第 369 期):Tim 与罗永浩的对谈 科技爱好者周刊(第 368 期):不要这样管理软件团队 一天之内,智谱和 Anthropic 都发了最强编程模型 科技爱好者周刊(第 367 期):Nano Banana 的几个妙用 科技爱好者周刊(第 366 期):旧金山疯狂的 AI 广告 科技爱好者周刊(第 365 期):流量变现正在崩塌 科技爱好者周刊(第 364 期):最难还原的魔方 科技爱好者周刊(第 363 期):最好懂的神经网络解释 科技爱好者周刊(第 362 期):GitHub 工程师谈系统设计 科技爱好者周刊(第 361 期):暗网 Tor 安全吗?
OAuth 2.0 的一個簡單解釋
阮一峰 · 2019-04-04 · via 阮一峰的网络日志

OAuth 2.0 是目前最流行的授權機制,用來授權第三方應用,獲取用戶數據。

這個標準比較抽象,使用了很多術語,初學者不容易理解。其實說起來並不複雜,下面我就通過一個簡單的類比,幫助大家輕鬆理解,OAuth 2.0 到底是什麼。

一、快遞員問題

我住在一個大型的居民小區。

小區有門禁系統。

進入的時候需要輸入密碼。

我經常網購和外賣,每天都有快遞員來送貨。我必須找到一個辦法,讓快遞員通過門禁系統,進入小區。

如果我把自己的密碼,告訴快遞員,他就擁有了與我同樣的權限,這樣好像不太合適。萬一我想取消他進入小區的權力,也很麻煩,我自己的密碼也得跟著改了,還得通知其他的快遞員。

有沒有一種辦法,讓快遞員能夠自由進入小區,又不必知道小區居民的密碼,而且他的唯一權限就是送貨,其他需要密碼的場合,他都沒有權限?

二、授權機制的設計

於是,我設計了一套授權機制。

第一步,門禁系統的密碼輸入器下面,增加一個按鈕,叫做"獲取授權"。快遞員需要首先按這個按鈕,去申請授權。

第二步,他按下按鈕以後,屋主(也就是我)的手機就會跳出對話框:有人正在要求授權。系統還會顯示該快遞員的姓名、工號和所屬的快遞公司。

我確認請求屬實,就點擊按鈕,告訴門禁系統,我同意給予他進入小區的授權。

第三步,門禁系統得到我的確認以後,向快遞員顯示一個進入小區的令牌(access token)。令牌就是類似密碼的一串數字,只在短期內(比如七天)有效。

第四步,快遞員向門禁系統輸入令牌,進入小區。

有人可能會問,為什麼不是遠程為快遞員開門,而要為他單獨生成一個令牌?這是因為快遞員可能每天都會來送貨,第二天他還可以複用這個令牌。另外,有的小區有多重門禁,快遞員可以使用同一個令牌通過它們。

三、互聯網場景

我們把上面的例子搬到互聯網,就是 OAuth 的設計了。

首先,居民小區就是儲存用戶數據的網絡服務。比如,微信儲存了我的好友信息,獲取這些信息,就必須經過微信的"門禁系統"。

其次,快遞員(或者說快遞公司)就是第三方應用,想要穿過門禁系統,進入小區。

最後,我就是用戶本人,同意授權第三方應用進入小區,獲取我的數據。

簡單說,OAuth 就是一種授權機制。數據的所有者告訴系統,同意授權第三方應用進入系統,獲取這些數據。系統從而產生一個短期的進入令牌(token),用來代替密碼,供第三方應用使用。

四、令牌與密碼

令牌(token)與密碼(password)的作用是一樣的,都可以進入系統,但是有三點差異。

(1)令牌是短期的,到期會自動失效,用戶自己無法修改。密碼一般長期有效,用戶不修改,就不會發生變化。

(2)令牌可以被數據所有者撤銷,會立即失效。以上例而言,屋主可以隨時取消快遞員的令牌。密碼一般不允許被他人撤銷。

(3)令牌有權限範圍(scope),比如只能進小區的二號門。對於網絡服務來說,只讀令牌就比讀寫令牌更安全。密碼一般是完整權限。

上面這些設計,保證了令牌既可以讓第三方應用獲得權限,同時又隨時可控,不會危及系統安全。這就是 OAuth 2.0 的優點。

注意,只要知道了令牌,就能進入系統。系統一般不會再次確認身份,所以令牌必須保密,洩漏令牌與洩漏密碼的後果是一樣的。 這也是為什麼令牌的有效期,一般都設置得很短的原因。

OAuth 2.0 對於如何頒發令牌的細節,規定得非常詳細。具體來說,一共分成四種授權類型(authorization grant),即四種頒發令牌的方式,適用於不同的互聯網場景。下一篇文章,我就來介紹這四種類型,並給出代碼實例。

(完)