授权码许可最为完备，但有时过于复杂，难以实现。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的值并返回给三方软件。
适用场景
软件是官方发行即可。