最近一直有同學(xué)在問(wèn)，OAuth2密碼模式為啥Spring Security還沒(méi)有實(shí)現(xiàn)，就連新的Spring Authorization Server也沒(méi)有這個(gè)玩意兒。

其實(shí)這里可以告訴大家，OAuth2密碼模式廢了，OAuth2 安全指南[1]相關(guān)的章節(jié)。以后新的OAuth2實(shí)現(xiàn)基本不太會(huì)可能積極去適配這個(gè)模式了。諸如Auth0、JIRA等知名產(chǎn)品都已經(jīng)在產(chǎn)品中移除了該模式。好好的為什么要移除呢?胖哥找了一些資料，大致上有幾點(diǎn)。

OAuth2是一個(gè)授權(quán)框架

OAuth2本身是一個(gè)授權(quán)框架，它并沒(méi)有對(duì)用戶的認(rèn)證流程做出定義。它的初衷是解決不同服務(wù)之間的授權(quán)訪問(wèn)問(wèn)題，它無(wú)法明確你認(rèn)為正確的接收者就是那個(gè)接收者。目前只有OAuth2的擴(kuò)展協(xié)議OIDC 1.0才具有用戶認(rèn)證功能。

密碼模式更像一種兼容性的協(xié)議

密碼模式誕生的時(shí)候，像React、Vue這種單頁(yè)應(yīng)用還沒(méi)有興起，甚至連框架都還沒(méi)有呢。它更像一種為了解決遺留問(wèn)題而采用的過(guò)渡方案。在傳統(tǒng)應(yīng)用中，用戶習(xí)慣了把密碼直接交給客戶端換取資源訪問(wèn)權(quán)限，而不是跳來(lái)跳去去拉授權(quán)、確認(rèn)授權(quán)。OAuth2誕生之時(shí)為了讓用戶從傳統(tǒng)思維中慢慢轉(zhuǎn)變過(guò)來(lái)就設(shè)計(jì)了這種模式。

這種模式好用，但它打破了委托授權(quán)的模式，降低了OAuth2的安全性。

它的流程非常像“網(wǎng)絡(luò)釣魚(yú)攻擊”，想象一下應(yīng)用程序隨意的讓你在一個(gè)平臺(tái)的登錄頁(yè)面中輸入另一個(gè)平臺(tái)的密碼，如果兩個(gè)平臺(tái)都是可信的，這樣做也無(wú)可厚非。但是它真的可信嗎?沒(méi)人敢打包票。

對(duì)于安全而言，這擴(kuò)大了密碼暴露的面積，密碼總是被提示小心保管避免泄露，這妥妥是一種反密碼模式。用戶密碼可能有意無(wú)意就在這個(gè)鏈路中泄露出去了。而且用戶無(wú)法控制授權(quán)的范圍，雖然用戶限制了scope，但是客戶端程序依然提供了編程機(jī)會(huì)來(lái)打破用戶的scope。如果在公共OAuth2客戶端上使用密碼模式，你的令牌端點(diǎn)也可能會(huì)被嗅探到，進(jìn)而被暴力窮舉。

因此在OAuth2最佳實(shí)踐[2]中已經(jīng)明確要求不能使用這種模式，甚至在聲明中用了MUST NOT BE這個(gè)字眼。

替代品是什么?

在OAuth2.1中，已經(jīng)僅僅只有這三種：

• Authorization Code+ PKCE 如果你需要安全授權(quán)請(qǐng)使用這種模式。
• Client Credentials 如果你的客戶端需要同其它客戶端進(jìn)行資源交互請(qǐng)使用這種模式。
• Device Code 如果你正在開(kāi)發(fā)的IoT應(yīng)用想使用OAuth2，可以考慮這種模式。

相比較而言，OAuth2.1更加注重安全性，目前正在起草階段。

那如果我還是需要進(jìn)行用戶認(rèn)證呢?目前只有OIDC 1.0[3]可選了。所以各位同學(xué)，未來(lái)的方向應(yīng)該明確了吧，密碼模式是應(yīng)該被放棄的時(shí)候了。

參考資料

[1]OAuth2 安全指南: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13#section-3.4

[2]最佳實(shí)踐: https://oauth.net/2/oauth-best-practice/

[3]OIDC 1.0: https://openid.net/

本文轉(zhuǎn)載自微信公眾號(hào)「碼農(nóng)小胖哥」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系碼農(nóng)小胖哥公眾號(hào)。