最近始终有同学在问，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 获取更多资讯
集体博客：https://felord.cn