其实这里可以告诉大家，OAuth2密码模式废了，OAuth2 安全指南[1]相关的章节。以后新的OAuth2实现基本不太会可能积极去适配这个模式了。诸如Auth0、JIRA等知名产品都已经在产品中移除了该模式。好好的为什么要移除呢?胖哥找了一些资料，大致上有几点。
OAuth2是一个授权框架
OAuth2本身是一个授权框架，它并没有对用户的认证流程做出定义。它的初衷是解决不同服务之间的授权访问问题，它无法明确你认为正确的接收者就是那个接收者。目前只有OAuth2的扩展协议OIDC 1.0才具有用户认证功能。
密码模式更像一种兼容性的协议
密码模式诞生的时候，像React、Vue这种单页应用还没有兴起，甚至连框架都还没有呢。它更像一种为了解决遗留问题而采用的过渡方案。在传统应用中，用户习惯了把密码直接交给客户端换取资源访问权限，而不是跳来跳去去拉授权、确认授权。OAuth2诞生之时为了让用户从传统思维中慢慢转变过来就设计了这种模式。
这种模式好用，但它打破了委托授权的模式，降低了OAuth2的安全性。
它的流程非常像“网络钓鱼攻击”，想象一下应用程序随意的让你在一个平台的登录页面中输入另一个平台的密码，如果两个平台都是可信的，这样做也无可厚非。但是它真的可信吗?没人敢打包票。
对于安全而言，这扩大了密码暴露的面积，密码总是被提示小心保管避免泄露，这妥妥是一种反密码模式。用户密码可能有意无意就在这个链路中泄露出去了。而且用户无法控制授权的范围，虽然用户限制了scope，但是客户端程序依然提供了编程机会来打破用户的scope。如果在公共OAuth2客户端上使用密码模式，你的令牌端点也可能会被嗅探到，进而被暴力穷举。
因此在OAuth2最佳实践[2]中已经明确要求不能使用这种模式，甚至在声明中用了MUST NOT BE这个字眼。
替代品是什么?
在OAuth2.1中，已经仅仅只有这三种：
- Authorization Code+ PKCE 如果你需要安全授权请使用这种模式。
- Client Credentials 如果你的客户端需要同其它客户端进行资源交互请使用这种模式。
- Device Code 如果你正在开发的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/
本文转载自微信公众号「码农小胖哥」，可以通过以下二维码关注。转载本文请联系码农小胖哥公众号。
