授权码许可最为完备，但有时过于复杂，难以实现。OAuth 提供了其他三种更方便实现的方案。
比如，xx软件是公众号官方开发的一款软件，那么使用xx就没必要再走一遍授权码许可类型流程。授权码许可通过授权码这种临时中间值，让用户参与，从而让xx和公众号之间建立联系，进而让xx代表我访问在公众号里的文章数据。
1 资源拥有者凭据许可
自己平台的肯定是被公众号信赖的，不是三方软件。我也是公众号的号主，即软件和号主都是公众号的所属。就没必要再使用授权码许可。但xx依然要访问文章数据API，提供为我排版功能。为保护这种场景下的 API，OAuth 2.0 提供了资源拥有者凭据许可类型。
资源拥有者的凭据，即用户的凭据：用户名和密码。这么简陋方案，咋敢用的？xx现在是公众号官方开发的软件，我也是其号主，那么我其实可以使用用户名和密码直接使用xx。因为这里无三方。
但若每次xx都拿我的用户名和密码来通过调用 API 访问我号里的文章数据，甚至其他敏感信息，无疑增加用户名和密码被攻击风险。若用token代替这些敏感信息，就能保护敏感信息，xx只需使用一次用户名和密码数据来换回一个token，进而通过token来访问我的号里数据，以后就不会再使用用户名和密码了。
该许可类型的时序图
- 当我访问第三方软件xx时，会提示输入用户名和密码。索要用户名和密码，就是资源拥有者凭据许可类型的特点
- 这里的grant_type的值为password，告诉授权服务使用资源拥有者凭据许可凭据的方式去请求访问。
- 授权服务在验证用户名和密码之后，生成access_token的值并返回给三方软件。
适用场景
软件是官方发行即可。
2 客户端凭据许可
若无明确资源拥有者，即xx访问了一个无需用户me授权的数据，比如
- 获取公众号LOGO的地址，该数据不属任何第三方用户
- 三方软件访问平台提供的省份信息，省份信息也不属任何一个第三方用户
此时的授权流程无需资源拥有者。这时其实第三方软件就变成资源拥有者了。这即是客户端凭据许可场景：第三方软件直接使用注册时的app_id和app_secret换取访问令牌access_token的值。
授权过程没有资源拥有者me的参与，小兔软件的后端服务可随时发access_token请求，所以无需刷新令牌。
