点击上方“JavaEdge”，关注公众号

设为“星标”，好文章不错过！

授权码许可最为完备，但有时过于复杂，难以实现。OAuth 提供了其他三种更方便实现的方案。

比如，xx软件是公众号官方开发的一款软件，那么使用xx就没必要再走一遍授权码许可类型流程。授权码许可通过授权码这种临时中间值，让用户参与，从而让xx和公众号之间建立联系，进而让xx代表我访问在公众号里的文章数据。

1 资源拥有者凭据许可

自己平台的肯定是被公众号信赖的，不是三方软件。我也是公众号的号主，即软件和号主都是公众号的所属。就没必要再使用授权码许可。但xx依然要访问文章数据API，提供为我排版功能。为保护这种场景下的 API，OAuth 2.0 提供了资源拥有者凭据许可类型。

但若每次xx都拿我的用户名和密码来通过调用 API 访问我号里的文章数据，甚至其他敏感信息，无疑增加用户名和密码被攻击风险。若用token代替这些敏感信息，就能保护敏感信息，xx只需使用一次用户名和密码数据来换回一个token，进而通过token来访问我的号里数据，以后就不会再使用用户名和密码了。

该许可类型的时序图

1. 当我访问第三方软件xx时，会提示输入用户名和密码。索要用户名和密码，就是资源拥有者凭据许可类型的特点

2. 这里的grant_type的值为password，告诉授权服务使用资源拥有者凭据许可凭据的方式去请求访问。

   

3. 授权服务在验证用户名和密码之后，生成access_token的值并返回给三方软件。

   

适用场景

软件是官方发行即可。

2 客户端凭据许可

若无明确资源拥有者，即xx访问了一个无需用户me授权的数据，比如

• 获取公众号LOGO的地址，该数据不属任何第三方用户

• 三方软件访问平台提供的省份信息，省份信息也不属任何一个第三方用户

此时的授权流程无需资源拥有者。这时其实第三方软件就变成资源拥有者了。这即是客户端凭据许可场景：第三方软件直接使用注册时的app_id和app_secret换取访问令牌access_token的值。

授权过程没有资源拥有者me的参与，小兔软件的后端服务可随时发access_token请求，所以无需刷新令牌。

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

1. 三方软件xx通过后端服务请求授权服务，grant_type = client_credentials，通知授权服务使用三方软件凭据方式去请求访问。

   

2. 在验证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中文翻译

往期推荐

目前交流群已有 800+人，旨在促进技术交流，可关注公众号添加笔者微信邀请进群

喜欢文章，点个“在看、点赞、分享”素质三连支持一下~