除了Implicit和Authorization Code,Oauth2.0还有Resource Owner Password Credentials授权方式和Client Credentials授权方式。
这两种简称 Password 方式和 Client 方式吧,都只适用于应用是受信任的场景。一个典型的例子是同一个企业内部的不同产品要使用本企业的 Oauth2.0 体系。在有些情况下,产品希望能够定制化授权页面。由于是同个企业,不需要向用户展示“xxx将获取以下权限”等字样并询问用户的授权意向,而只需进行用户的身份认证即可。这个时候,由具体的产品团队开发定制化的授权界面,接收用户输入账号密码,并直接传递给鉴权服务器进行授权即可。

有一点需要特别注意的是,在 2 这一步,鉴权服务器需要对应用方的身份进行验证,确保是受信任的应用方。
如果信任关系再进一步,或者调用者是一个后端的模块,没有用户界面的时候,可以使用 Client 方式。鉴权服务器直接对应用方进行身份验证,验证通过后,返回 token。

这两种方式在 Oauth2.0 协议中是不推荐使用的。只要条件允许,就应该使用 Authorization Code 方式。
若有疑问,可以直接进以下公众号提问。也可以直接发送 oauth2.0 获取设计指南和伪代码:

本文详细介绍了OAuth2.0中的ResourceOwnerPasswordCredentials和ClientCredentials授权方式,这两种方式适用于受信任的应用场景,如企业内部产品间的授权。文章还探讨了在特定场景下如何使用这些授权方式,并强调了其在协议中的不推荐地位。
:另外的两种授权方式&spm=1001.2101.3001.5002&articleId=104553602&d=1&t=3&u=30f343a250e74da096a95022b4abf4c3)
1807

被折叠的 条评论
为什么被折叠?



