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

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

这两种方式在 Oauth2.0 协议中是不推荐使用的。只要条件允许,就应该使用 Authorization Code 方式。
本文深入探讨了OAuth2.0协议中的Password方式和Client方式,这两种方式适用于受信任的内部应用场景,如企业内部产品间的授权。文章详细解释了这两种方式的工作流程,包括定制化授权页面的开发和后端模块的身份验证过程。同时,强调了这两种方式的安全考虑及为何在条件允许的情况下,推荐使用AuthorizationCode方式。
:Resource Owner Password Credentials 授权和 Client Credentials 授权&spm=1001.2101.3001.5002&articleId=101618657&d=1&t=3&u=8be85e9d73f144e69085861d60211656)
1013

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



