最近一直有同学问为什么SpringSecurity中没有实现OAuth2密码模式，甚至新的SpringAuthorizationServer也没有这个东西。其实这里可以告诉大家，OAuth2密码模式废除了，OAuth2SecurityGuide[1]相关章节。未来新的OAuth2实现不太可能主动适应这种模式。Auth0和JIRA等知名产品已经从他们的产品中去除了这种模式。好的，为什么要删除它？胖哥找了一些资料，大致有这么几点。OAuth2是一个授权框架OAuth2本身就是一个授权框架，它没有定义用户认证过程。它的初衷是为了解决不同服务之间授权访问的问题，并不能明确你认为的接收者就是正确的。目前只有OAuth2的扩展协议OIDC1.0具有用户认证功能。密码模式更像是一种兼容协议。密码模式诞生的时候，像React、Vue这样的单页应用还没有出现，甚至还没有框架。它更像是解决遗留问题的过渡解决方案。在传统应用中，用户习惯于直接将密码交给客户端来换取资源访问权限，而不是跳来跳去地请求授权和确认授权。OAuth2诞生的时候，这个模型就是为了让用户从传统的思维中慢慢转变而来的。这种模式使用方便，但破坏了委托授权模式，降低了OAuth2的安全性。其过程非常类似于“网络钓鱼攻击”。想象一下，应用程序随机要求您在一个平台的登录页面输入另一个平台的密码。如果两个平台都是可信的，那么这样做就没有错。但这真的可信吗？没有人确定。在安全方面，这扩大了密码的暴露区域，时刻提醒密码小心保管，以免泄露。这是一种反密码模式。用户密码可能有意或无意通过此链接泄露。而且，用户无法控制授权范围。虽然用户限制了范围，但客户端程序仍然提供了打破用户范围的编程机会。如果您在公共OAuth2客户端上使用密码模式，您的令牌端点也可能被嗅探和暴力破解。因此，在OAuth2[2]的最佳实践中，明确要求不能使用这种模式，甚至在声明中使用了MUSTNOTBE这个词。有哪些选择？在OAuth2.1中，只有这三种：AuthorizationCode+PKCE如果需要安全授权，请使用这种方式。客户端凭据如果您的客户端需要与其他客户端交互以获取资源，请使用此模式。DeviceCode如果你开发的物联网应用想使用OAuth2，可以考虑这种模式。相比之下，OAuth2.1更加注重安全性，目前处于起草阶段。如果我还需要进行用户认证怎么办？目前只有OIDC1.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]OIDC1.0:https://openid.net/本文转载自微信公众号“码农小胖哥”，可通过以下二维码关注。转载本文请联系码农小胖公众号。
