OAUTH 2 资助类型的澄清

Question

一直在阅读一些有关 OAUTH2 的内容。

所以...

• 授权代码授予：适用于想要通过第三方应用程序访问我的应用程序/API 的用户。示例：用户希望通过 Flicker 访问“我的照片打印 API”。在这种情况下，Flicker 将使用我的服务器执行所有重定向和 OAUTH2 流程。提供访问令牌，第三方应用程序可以根据需要使用我的 API。应用程序开发人员需要注册才能获取客户端 ID 和客户端密钥。

• 隐式： 与上面相同，只是移动/应用程序没有后端服务器来保护客户端机密。移动应用程序将处理重定向和 OAUTH2 流。提供访问令牌，第三方应用程序可以根据需要使用我的 API。不支持刷新令牌。应用程序开发人员需要注册才能获取客户端 ID。

• 资源所有者密码凭据授予：在本例中，这是我的移动/网络应用程序，我通过典型的 iTunes/Play 商店分发给我的用户。用户严格使用我的应用程序来完成日常工作。我的移动/网络应用程序将询问用户用户名/密码并将其发布到我的后端，在那里它将进行身份验证，然后提供回访问令牌。

• 客户端凭据授予：此案例用于应用程序执行内部机器对机器的操作。即：我的 App1 访问了我的 App2，位于后端某处。

目前我预计不会与第三方共享我的 API，我的用户将通过 iTunes/google play 安装我的应用程序。我认为密码凭证现在对我有好处。最终，如果我想向世界其他地方开放我的 API，我将必须实施授权代码授予

当我搜索这个主题时，我发现了这个链接：https://alexbilbie.com/guide-to-oauth-2-grants/，它有一个很好的决策流程。

Answer 1

当您想要授权/委托客户端（第三方应用程序）访问您的资源时，使用 OAuth2。

至少有4位演员：

• 授权服务器
• 客户
• 资源所有者
• 资源服务器

应用程序/API是资源服务器。它存储和管理资源所有者的所有资源。

客户是想要访问这些资源的一方。 授权服务器是通过颁发访问令牌来授权客户端访问资源的服务器。

• 授权代码授予专为机密客户而设计（能够保证其凭证的安全）。
• 隐式授予是为公共客户端（而不是机密客户端）设计的，尤其是脚本语言应用程序（JS...）
• 资源所有者密码凭据授予专为任何类型的客户端而设计，但假设客户端知道资源所有者的密码凭据。一般来说，这种授权类型仅专用于受信任的客户。
• 客户端凭据授予允许客户端访问自己的资源（在这种情况下，资源所有者是客户端）。

应避免使用资源所有者密码凭证授予，但是对于遗留应用程序，并且如果客户端、授权服务器和资源服务器之间存在可信关系，它仍然是一个很好的解决方案。