OAuth 2.1 帶來了哪些變化

xiangzhihong 發(fā)布于2021-11-24 09:39 / 2876人閱讀

摘要：使用時不應(yīng)該通過傳遞使用時不應(yīng)該通過傳遞根據(jù)安全最佳實踐章節(jié)在使用時您不應(yīng)該把放到中第一瀏覽器地址欄本來就是暴露的第二可以查看瀏覽記錄，找到。

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

? 推薦使用 Authorization Code + PKCE

根據(jù) OAuth 2.0 安全最佳實踐(Security Best Current Practices) 2.1.1 章節(jié)

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

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

根據(jù) OAuth 2.0 安全最佳實踐(Security Best Current Practices) 2.1.2 章節(jié)

在 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, 同時這種也是不安全的。

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

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

根據(jù) OAuth 2.0 安全最佳實踐(Security Best Current Practices) 2.4 章節(jié)

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

試想一下, 在你手機(jī)上有一個網(wǎng)易云音樂的APP, 現(xiàn)在要使用qq賬號登錄, 這時網(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è)計的，為了讓第三方應(yīng)用使用授權(quán), 它不是為身份驗證而設(shè)計的, 而 OpenID Connect（建立在 OAuth 之上）是專為身份驗證而設(shè)計, 所以, 在使用 OAuth 授權(quán)協(xié)議時, 你需要知道你使用的客戶端是第三方應(yīng)用程序還是第一方應(yīng)用，這很重要！因為 OAuth 2.1 已經(jīng)不支持第一方應(yīng)用授權(quán)！

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

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

根據(jù) OAuth 2.0 安全最佳實踐(Security Best Current Practices) 4.3.2 章節(jié)

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

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

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

根據(jù) OAuth 2.0 安全最佳實踐(Security Best Current Practices) 4.13.2 章節(jié)

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

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

根據(jù) OAuth 2.0 安全最佳實踐(Security Best Current Practices) 4.1.3 章節(jié)

在 OAuth 2.0 的授權(quán)碼流程中, 需要設(shè)置一個回調(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

假如有三個不同的客戶端

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

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