【OAuth2.0】我该如何选择使用的模式呢？

最新推荐文章于 2023-12-31 01:32:42 发布

愿做无知一猿

最新推荐文章于 2023-12-31 01:32:42 发布

阅读量168

点赞数

文章标签： oauth2 oauth

本文链接：https://blog.csdn.net/qq_38397501/article/details/115623954

版权

翻译自：这里

OAuth2.0术语

资源所有者：可以授予受保护资源的最终用户。
客户端：代表资源所有者请求访问受保护资源的应用程序。
资源服务器：持有受保护资源的服务，也就是你要访问的api接口。
授权服务器：认证资源所有者以及在获得正确的认证之后颁发access_token的服务。
用户代理：是一种被资源所有者去和客户端产生交互的代理（例如浏览器）。

客户端是资源所有者吗？

第一个决定点是需要访问资源的一方是否是一台机器。在机器对机器授权的情况下，客户端也是资源所有者，因此不需要最终用户授权。一个例子是使用API将信息导入数据库的cron作业。在本例中，cron作业是客户端和资源所有者，因为它保存客户端ID和客户端秘密，并使用它们从授权服务器获取访问令牌。
这种情况下通常使用Client Credentials Flow。

客户端是在服务器上执行的web应用程序吗？

如果你的客户端是一个单独运行的服务，那么Authorization Code Flow就是最好的。
使用此方法，客户端可以检索访问令牌，也可以检索刷新令牌。它被认为是最安全的选择，因为访问令牌直接传递给承载客户端的Web服务器，而不需要冒着暴露的风险经过用户的Web浏览器。

客户端是否完全信任用户凭据？

如果完全信任，那么Resource Owner Password Flow就是一个选择。
在这个流程中，最终用户被要求填写凭据(用户名/密码)，通常使用交互式表单。此信息被发送到后端，并从后端发送到Auth0。因此，必须绝对信任客户端提供这些信息。
这种形式只能用在基于重定向的流的形式无法实现时。

客户端是单页应用程序吗？

如果客户端是单页应用程序(SPA)，这是使用JavaScript等脚本语言在浏览器中运行的应用程序，则有两个授予选项：Authorization Code Flow with PKCE和Implicit Flow。
在大多数情况下，我们建议在PKCE中使用授权代码流，因为访问令牌没有在客户端公开，而且这个流可以返回刷新令牌。
Single-Page App SDK为在Spas中使用PKCE实现授权代码流提供了高级API。Auth0 Single-Page App SDK
如果SPA不需要访问令牌，则可以使用表单POST的Implicit Flow。