OAuth2.0协议(二) - 密码类型、隐式许可类型、客户端类型、PKCE

前提是在理解的OAuth2.0授权码许可流程（最完整的授权流程）后，再来理解其他的授权许可类型和每种类型的使用场景。

资源拥有者凭据许可类型

    资源拥有者凭据许可类型虽然名字比较拗口，但确是我们最熟悉的使用 用户名密码直接换取token的流程。与授权码许可流程相比，这里减少了获取授权码的流程和两次重定向的过程，之前我们也分析过增加授权码流程就是为了增加安全性和用户体验，但前提是三方服务本身并不被信任。    但是如果都是本公司不同团队（甚至是同一团队）开发的三方服务，比如电商系统与配送系统（京东到家和达达就是这个关系），并且配送服务即可以支持自己的电商系统也可以通过开放平台支持其他外部三方。此时再使用完整的授权码许可流程，可以，但是并没有太多必要，资源拥有者凭据许可流程如下：

客户端凭据许可类型

    客户端凭据许可类型与 用户无关和三方的前端无关，只是三方服务的服务端直接调用授权服务端和受保护资源服务端。比如有个场景，京东想要开放自己的商城Logo图，但是肯定不能让任何人都能进行调用，前提肯定还是在京东开放平台进行注册过的用户，此时只需要在需要展示Logo时，三方的服务器端直接调用获取token，就可以去下载京东logo了，流程如下图：

隐式许可类型

    几年前在开发项目时就遇到需要开发一个没有服务端的App，或者Web页面没有服务器端（单页SPA），此时只能将 app_id、app_secret存储在前端，调用服务时直接传递，但是这样安全性比较差。流程如下：

     我们知道如果要上传图片数据的话，会有自己的图片服务器。当然如果对安全要求没那么严格的数据，比如商品图片，本身也是要通过app展示给用户看的。此时比如我们使用阿里云的oss存储，要上传图片有两种方式，一种就是前段直接将图片以流的形式，使用Http表单提交到后端再去调用oss的java sdk。 当然阿里云也提供了一个 js的sdk，此时可能就是使用的隐士许可流程，我不是特别确定，欢迎大家解疑或者讨论。阿里云的官网提供的js sdk代码如下：

     基于安全性的考虑，一般不推荐使用隐式许可流程，替代的方案下面的就是PKCE协议。

PKCE补充协议

    PKCE的全称是Proof Key for Code Exchange by OAuth Public Clients，PKCE的诞生于2015 年 9 月增补了 PKCE 协议，也就是官方的 RFC 7636，而OAuth 2.0 的正式授权协议框架于2012 年 10 月 ，也就是官方的 RFC 6749 被正式发布。中间相差了三年正是互联网蓬勃发展的时间，为的就是更好的解决类似于隐式许可流程这样的应用场景。

    PKCE允许客户端自己生成一个随机的 43~128位的随机字符串作为 code_verifier，再根据一定的算法 计算出一个挑战码code_chanllenge。OAuth2.0规定了两种生成挑战码的加密算法：

• plain ：code_verifier和code_chanllenge的值相同
• S256：code_chanllenge = base64（SHA256（ASCII（code_verifier）））； 即使用code_verifier进行ASCII 编码，再将值使用sha256进行加密，最后再使用base64转码

授权码许可流程中有两步进行替换：

1、获取授权码阶段：此时传入code_challenge_method（plain或s256）和code_chanllenge的值

2、获取令牌阶段：传入code_verifier，此时授权服务可以通过第二个获取到的code_verifier值，使用第一次获取的code_challenge_method进行加密，查看是否于code_chanllenge值相等即可。一般推荐使用PKCE替代隐式许可流程的场景。