OAuth 2.1 是 OAuth 2.0 的下一個(gè)版本, OAuth 2.1 根據(jù)最佳安全實(shí)踐(BCP), 目前是第18個(gè)版本，對 OAuth 2.0 協(xié)議進(jìn)行整合和精簡, 移除不安全的授權(quán)流程, 并發(fā)布了 OAuth 2.1 規(guī)范草案, 下面列出了和 OAuth 2.0 相比的主要區(qū)別。

? 推薦使用 Authorization Code + PKCE

根據(jù) OAuth 2.0 安全最佳實(shí)踐(Security Best Current Practices) 2.1.1 章節(jié)^[1]

授權(quán)碼 (Authorization Code) 模式大家都很熟悉了,也是最安全的授權(quán)流程, 那 PKCE 又是什么呢? PKCE 全稱是 Proof Key for Code Exchange, 在 2015 年發(fā)布為 RFC 7636, 我們知道, 授權(quán)碼模式雖好, 但是它不能給公開的客戶端用, 因?yàn)楣_的客戶端沒有能力保存好秘鑰(client_secret), 所以在此之前, 對于公開的客戶端, 只能使用隱式模式和密碼模式, PKCE 就是為了解決這個(gè)問題而出現(xiàn)的, 另外它也可以防范授權(quán)碼攔截攻擊, 實(shí)際上它的原理是客戶端提供一個(gè)自創(chuàng)建的證明給授權(quán)服務(wù)器， 授權(quán)服務(wù)器通過它來驗(yàn)證客戶端，把訪問令牌(access_token) 頒發(fā)給真實(shí)的客戶端而不是偽造的，下邊是 Authorization Code + PKCE 的授權(quán)流程圖。

?隱式授權(quán)（ Implicit Grant）已棄用

根據(jù) OAuth 2.0 安全最佳實(shí)踐(Security Best Current Practices) 2.1.2 章節(jié)^[2]

在 OAuth 2.1 規(guī)范草案中, 授權(quán)模式中已經(jīng)找不到隱式授權(quán)(Implicit Grant), 我們知道, 隱式授權(quán)是 OAuth 2.0 中的授權(quán)模式, 是授權(quán)碼模式的簡化版本, 用戶同意授權(quán)后, 直接就能返回訪問令牌 access_token, 同時(shí)這種也是不安全的。

現(xiàn)在您可以考慮替換為 Authorization Code + PKCE 的授權(quán)模式。

? 密碼授權(quán) （Resource Owner Password Credentials Grant）已棄用

根據(jù) OAuth 2.0 安全最佳實(shí)踐(Security Best Current Practices) 2.4 章節(jié)^[3]

在 OAuth 2.1 規(guī)范草案中, 密碼授權(quán)也被移除, 實(shí)際上這種授權(quán)模式在 OAuth 2.0中都是不推薦使用的, 密碼授權(quán)的流程是, 用戶把賬號密碼告訴客戶端, 然后客戶端再去申請?jiān)L問令牌, 這種模式只在用戶和客戶端高度信任的情況下才使用。

試想一下, 在你手機(jī)上有一個(gè)網(wǎng)易云音樂的APP, 現(xiàn)在要使用qq賬號登錄, 這時(shí)網(wǎng)易云音樂說, 你把qq賬號密碼告訴我就行了, 我拿著你的賬號密碼去QQ那邊登錄, 這就很離譜了!

正確的做法是, 用戶在網(wǎng)易云音樂要使用qq登錄, 如果用戶也安裝了qq 的客戶端, 應(yīng)該喚起qq應(yīng)用, 在qq頁面完成授權(quán)操作, 然后返回到網(wǎng)易云音樂。如果用戶沒有安裝qq客戶端應(yīng)用, 喚起瀏覽器, 引導(dǎo)用戶去qq的授權(quán)頁面, 用戶授權(quán)完成后, 返回到網(wǎng)易云音樂。

請注意, OAuth 是專門為委托授權(quán)而設(shè)計(jì)的，為了讓第三方應(yīng)用使用授權(quán), 它不是為身份驗(yàn)證而設(shè)計(jì)的, 而 OpenID Connect（建立在 OAuth 之上）是專為身份驗(yàn)證而設(shè)計(jì), 所以, 在使用 OAuth 授權(quán)協(xié)議時(shí), 你需要知道你使用的客戶端是第三方應(yīng)用程序還是第一方應(yīng)用，這很重要！因?yàn)?OAuth 2.1 已經(jīng)不支持第一方應(yīng)用授權(quán)！

現(xiàn)在您可以考慮使用 Authorization Code + PKCE 替換之前的密碼授權(quán)模式。

? 使用 access_token 時(shí), 不應(yīng)該通過 URL 傳遞 token

根據(jù) OAuth 2.0 安全最佳實(shí)踐(Security Best Current Practices) 4.3.2 章節(jié)^[4]

在使用 access_token 時(shí), 您不應(yīng)該把token放到URL中, 第一, 瀏覽器地址欄本來就是暴露的, 第二, 可以查看瀏覽記錄，找到 access_token。

正確的做法是, 把 access_token 放到 Http header 或者是 POST body 中。

? 刷新令牌 (Refresh Token) 應(yīng)該是一次性的

根據(jù) OAuth 2.0 安全最佳實(shí)踐(Security Best Current Practices) 4.13.2 章節(jié)^[5]

access_token 訪問令牌, refresh_token 刷新令牌, 刷新令牌可以在一段時(shí)間內(nèi)獲取訪問令牌, 平衡了用戶體驗(yàn)和安全性, 在 OAuth 2.1 中, refresh_token 應(yīng)該是一次性的, 用過后失效, 使用 refresh_token 獲取access_token時(shí), 還可以返回一個(gè)新的 refresh_token。

? 回調(diào)地址（Redirect URI）應(yīng)該精確匹配

根據(jù) OAuth 2.0 安全最佳實(shí)踐(Security Best Current Practices) 4.1.3 章節(jié)^[6]

在 OAuth 2.0 的授權(quán)碼流程中, 需要設(shè)置一個(gè)回調(diào)地址 redirect_uri, 如下

https://www.authorization-server.com/oauth2/authorize?response_type=code&client_id=s6BhdRkqt3&scope=user&state=8b815ab1d177f5c8e &redirect_uri=https://www.client.com/callback

假如有三個(gè)不同的客戶端

?a.client.com?b.client.com?c.client.com

這時(shí)可能會(huì)使用一個(gè)通配符的 redirect_uri, 比如 *.client.com, 這樣會(huì)有什么風(fēng)險(xiǎn)呢? 實(shí)際上, 惡意程序有機(jī)會(huì)篡改 redirect_uri, 假設(shè)惡意程序的域名是 https://attacker.com, 然后把 redirect_uri 改成 https://attacker.com/.client.com, 這樣授權(quán)碼就發(fā)送給了惡意程序。

References

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的OAuth 2.1 带来了哪些变化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。