最近一直有同學在問，OAuth2密碼模式為啥Spring Security還沒有實現，就連新的Spring Authorization Server也沒有這個玩意兒。
其實這裡可以告訴大家，OAuth2密碼模式廢了，OAuth2 安全指南相關的章節。以後新的OAuth2實現基本不太會可能積極去適配這個模式了。諸如Auth0、JIRA等知名產品都已經在產品中移除了該模式。用的好好的為什麼要移除呢？胖哥找了一些資料，大致上有幾點。
OAuth2是一個授權框架
OAuth2本身是一個授權框架，它並沒有對使用者的認證流程做出定義。它的初衷是解決不同服務之間的授權訪問問題，它無法明確你認為正確的接收者就是那個接收者。目前只有OAuth2的擴充套件協議OIDC 1.0才具有使用者認證功能。
密碼模式更像一種相容性的協議
密碼模式誕生的時候，像React、Vue這種單頁應用還沒有興起，甚至連框架都還沒有呢。它更像一種為了解決遺留問題而採用的過渡方案。在傳統應用中，使用者習慣了把密碼直接交給客戶端換取資源訪問許可權，而不是跳來跳去拉授權、確認授權。OAuth2誕生之時為了讓使用者從傳統思維中慢慢轉變過來就設計了這種模式。
這種模式好用，但它打破了委託授權的模式，降低了OAuth2的安全性。
它的流程非常像“網路釣魚攻擊”，想象一下應用程式隨意的讓你在一個平臺的登入頁面中輸入另一個平臺的密碼，如果兩個平臺都是可信的，這樣做也無可厚非。但是它真的可信嗎？沒人敢打包票。
對於安全而言，這擴大了密碼暴露的面積，密碼總是被提示小心保管避免洩露，這妥妥是一種反密碼模式。使用者密碼可能有意無意就在這個鏈路中洩露出去了。而且使用者無法控制授權的範圍，雖然使用者限制了scope，但是客戶端程式依然提供了程式設計機會來打破使用者的scope。如果在公共OAuth2客戶端上使用密碼模式，你的令牌端點也可能會被嗅探到，進而被暴力窮舉。
因此在OAuth2最佳實踐中已經明確要求不能使用這種模式，甚至在宣告中用了MUST NOT BE這個字眼。
替代品是什麼？
在OAuth2.1中，已經僅僅只有這三種
- Authorization Code+ PKCE 如果你需要安全授權請使用這種模式。
- Client Credentials 如果你的客戶端需要同其它客戶端進行資源互動請使用這種模式
- Device Code 如果你正在開發的IoT應用想使用OAuth2，可以考慮這種模式。
相比較而言，OAuth2.1更加註重安全性，目前正在起草階段。
那如果我還是需要進行使用者認證呢？目前只有OIDC 1.0可選了。所以各位同學，未來的方向應該明確了吧，密碼模式是應該被放棄的時候了。
關注公眾號：Felordcn 獲取更多資訊