客户端凭据许可类型的关键流程，就如下两大步：
- 三方软件xx通过后端服务请求授权服务，
grant_type = client_credentials，通知授权服务使用三方软件凭据方式去请求访问。
- 在验证
app_id和app_secret后，生成access_token返回。
适用场景
在获取一种不属任何第三方用户的数据时，无需类似我这样的高级用户参与。
3 隐式许可
适用场景
若我使用的xx软件没有后端服务呢，就是在浏览器执行，比如纯甄的JS应用。可理解为三方软件直接嵌入浏览器。
这时的xx软件对浏览器已无任何秘密可言，也无需应用密钥app_secret，更无需再通过授权码code换取访问令牌access_token。因为使用授权码的目的之一，就是把浏览器和三方软件的信息隔离，确保浏览器看不到三方软件最重要的访问令牌access_token。
因此，隐式许可授权流程安全性降低很多。在授权流程中，没有服务端的xx相当于嵌入浏览器，访问浏览器的过程相当于接触了xx的全部。
- 用户通过浏览器访问三方软件xx。此时，三方软件xx实际上是嵌入浏览器中执行的应用程序
- 该流程和授权码类似，只是response_type值变成token，告诉授权服务直接返回access_token值。
隐式许可是唯一在前端通信中要求返回access_token的流程。
- 生成acccess_token的值，通过前端通信返回给第三方软件小兔。
授权类型的选型
参考
- https://iot.mi.com/new/doc/cloud-development/miot-access/oauth
- 除了授权码许可类型，OAuth 2.0还支持什么授权流程？
- OAuth2 RFC6749中文翻译
