图文+代码讲解带你攻克OAuth 2.0授权流程的三座大山（下）

客户端凭据许可类型的关键流程，就如下两大步：

1. 三方软件xx通过后端服务请求授权服务，

   grant_type = client_credentials

   ，通知授权服务使用三方软件凭据方式去请求访问。

1. 在验证

   app_id

   和

   app_secret

   后，生成

   access_token

   返回。

适用场景

在获取一种不属任何第三方用户的数据时，无需类似我这样的高级用户参与。

3 隐式许可

若我使用的xx软件没有后端服务呢，就是在浏览器执行，比如纯甄的JS应用。可理解为三方软件直接嵌入浏览器。

这时的xx软件对浏览器已无任何秘密可言，也无需应用密钥app_secret，更无需再通过授权码code换取访问令牌access_token。因为使用授权码的目的之一，就是把浏览器和三方软件的信息隔离，确保浏览器看不到三方软件最重要的访问令牌access_token。

因此，隐式许可授权流程安全性降低很多。在授权流程中，没有服务端的xx相当于嵌入浏览器，访问浏览器的过程相当于接触了xx的全部。

1. 用户通过浏览器访问三方软件xx。此时，三方软件xx实际上是嵌入浏览器中执行的应用程序
2. 该流程和授权码类似，只是response_type值变成token，告诉授权服务直接返回access_token值。

隐式许可是唯一在前端通信中要求返回access_token的流程。

1. 生成acccess_token的值，通过前端通信返回给第三方软件小兔。

授权类型的选型

参考

• https://iot.mi.com/new/doc/cloud-development/miot-access/oauth
• 除了授权码许可类型，OAuth 2.0还支持什么授权流程？
• OAuth2 RFC6749中文翻译