建站
咨詢
售后
建站咨詢
新聞中心
其實這里可以告訴大家，OAuth2密碼模式廢了，OAuth2 安全指南[1]相關的章節(jié)。以后新的OAuth2實現(xiàn)基本不太會可能積極去適配這個模式了。諸如Auth0、JIRA等知名產(chǎn)品都已經(jīng)在產(chǎn)品中移除了該模式。好好的為什么要移除呢?胖哥找了一些資料，大致上有幾點。
我們提供的服務有：成都網(wǎng)站設計、成都做網(wǎng)站、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、石城ssl等。為近千家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的石城網(wǎng)站制作公司
OAuth2是一個授權框架
OAuth2本身是一個授權框架，它并沒有對用戶的認證流程做出定義。它的初衷是解決不同服務之間的授權訪問問題，它無法明確你認為正確的接收者就是那個接收者。目前只有OAuth2的擴展協(xié)議OIDC 1.0才具有用戶認證功能。
密碼模式更像一種兼容性的協(xié)議
密碼模式誕生的時候，像React、Vue這種單頁應用還沒有興起，甚至連框架都還沒有呢。它更像一種為了解決遺留問題而采用的過渡方案。在傳統(tǒng)應用中，用戶習慣了把密碼直接交給客戶端換取資源訪問權限，而不是跳來跳去去拉授權、確認授權。OAuth2誕生之時為了讓用戶從傳統(tǒng)思維中慢慢轉(zhuǎn)變過來就設計了這種模式。
這種模式好用，但它打破了委托授權的模式，降低了OAuth2的安全性。
它的流程非常像“網(wǎng)絡釣魚攻擊”，想象一下應用程序隨意的讓你在一個平臺的登錄頁面中輸入另一個平臺的密碼，如果兩個平臺都是可信的，這樣做也無可厚非。但是它真的可信嗎?沒人敢打包票。
對于安全而言，這擴大了密碼暴露的面積，密碼總是被提示小心保管避免泄露，這妥妥是一種反密碼模式。用戶密碼可能有意無意就在這個鏈路中泄露出去了。而且用戶無法控制授權的范圍，雖然用戶限制了scope，但是客戶端程序依然提供了編程機會來打破用戶的scope。如果在公共OAuth2客戶端上使用密碼模式，你的令牌端點也可能會被嗅探到，進而被暴力窮舉。
因此在OAuth2最佳實踐[2]中已經(jīng)明確要求不能使用這種模式，甚至在聲明中用了MUST NOT BE這個字眼。
替代品是什么?
在OAuth2.1中，已經(jīng)僅僅只有這三種：
- Authorization Code+ PKCE 如果你需要安全授權請使用這種模式。
- Client Credentials 如果你的客戶端需要同其它客戶端進行資源交互請使用這種模式。
- Device Code 如果你正在開發(fā)的IoT應用想使用OAuth2，可以考慮這種模式。
相比較而言，OAuth2.1更加注重安全性，目前正在起草階段。
那如果我還是需要進行用戶認證呢?目前只有OIDC 1.0[3]可選了。所以各位同學，未來的方向應該明確了吧，密碼模式是應該被放棄的時候了。
參考資料
[1]OAuth2 安全指南: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13#section-3.4
[2]最佳實踐: https://oauth.net/2/oauth-best-practice/
[3]OIDC 1.0: https://openid.net/
本文轉(zhuǎn)載自微信公眾號「碼農(nóng)小胖哥」，可以通過以下二維碼關注。轉(zhuǎn)載本文請聯(lián)系碼農(nóng)小胖哥公眾號。
文章名稱：OAuth2.0密碼模式廢了，停止使用吧！
轉(zhuǎn)載注明：http://www.5511xx.com/article/cogjphg.html
