为 Web 应用程序使用自己的 API - 使用 OAuth2 的身份验证过程

Question

概述

我目前正在为一个图像共享应用程序创建一个 API，该应用程序将在网络上运行，并且将来某个时候在移动设备上运行。我了解 API 构建的逻辑部分，但我仍在努力满足自己对身份验证部分的要求。

因此，我的 API 必须可供全世界访问：具有访客访问权限的用户（例如，未登录的人可以上传）以及注册用户。因此，当注册用户上传时，我显然希望用户信息与请求一起发送，并通过我的数据库中的外键将该用户信息附加到上传的图像。

---

通过 OAuth2 进行身份验证 - 实现

我已经了解 OAuth2 是 API 身份验证的最佳选择，因此我将实施这一方法，但我真的很难解决如何处理 my em>情况。我想过使用client credentials 授权并为我的网络应用程序生成仅一个 凭据集，并让它使用client secret 向API 发送请求以获取访问令牌并让用户执行东西。用户注册过程本身将使用此授权处理。

但是当用户注册并登录时呢？我现在如何处理身份验证？这需要另一笔拨款来接管吗？我正在考虑在用户登录期间进行一些授权过程，以生成新的访问令牌。这种做法有错吗？

---

我需要什么帮助

我需要您就如何为我的案例正确处理身份验证流程提供意见。这种双向认证过程可能不是我需要的，但这是我理解的方式。非常感谢您的支持。

Answer 1

你的方法似乎可行。

Oauth2 有 4 个主要部分：

• 资源服务器（您的 API）
• 资源所有者（在资源服务器上拥有数据的最终用户）
• 授权服务器（获取授权并颁发令牌）
• 客户端（您的网络应用 - 以及未来的应用）

请记住Client Credentials 授权，您获得的令牌可能没有任何用户上下文。因此，如果您的 API 端点依赖于令牌中包含的用户标识符/资源所有者，那么您将需要围绕该类型的令牌编写代码。

如果您确实需要令牌来为您的 API 提供一些资源所有者上下文，并且您的 Web 应用程序恰好是您的身份提供者，那么您可以使用 resource owner password 授权，它将为您提供令牌和刷新令牌资源所有者/用户的上下文。

Authorization code 授权很好，前提是您未来的 API 使用者是 Web 应用程序（即在服务器上运行）。如果您计划允许移动/原生应用程序使用您的 API，那么您应该考虑在您的授权服务器中允许 Implicit 授予。

如果您的 API 没有最终用户，并且每个客户端对 API 的访问权限因应用程序的不同而不同，那么您可以使用客户端凭据授权并使用 scopes 来限制 API 访问权限。

编辑

所以我的 API 必须可以通过访客访问（非 例如，登录的人可以上传）和注册用户。所以 当注册用户上传时，我显然希望发送用户 连同请求并将该用户附加到上传的图像

要实现这一点，您的 API 上传端点可以处理 Oauth2.0 Bearer 令牌，但不依赖于它们。例如任何人都可以使用该端点，并且在标头中提供访问令牌的人将上传与 API 从令牌中获取的用户上下文相关联。 然后，如果需要，您可以使其他端点依赖于令牌。

基于 cmets 编辑

注册过程本身将使用客户端凭据授权， 对吗？

我认为注册过程本身不应该是受 Oauth 保护的资源。理想情况下，注册应由您的身份提供者（例如 google、facebook 或您自己的用户会员数据库）处理。 Oauth2.0 的优点之一是它不再需要 API 来执行用户管理工作。

Answer 2

您实际上并不需要 oauth 来对您自己的 API 进行身份验证。

如果您希望其他应用程序访问您的 API，OAuth2 非常有用。

让我稍微解释一下 OAuth2 的工作原理：

• 客户端（应用程序）想要使用您的 API，因此您向他提供客户端凭据（client_token 和 client_secret）。您在数据库中设置了一组客户端可以使用的重定向位置。
• 客户端需要用户授权才能代表用户使用您的 API。因此，客户端将用户发送到您网站上的 url（使用 client_token，客户端需要的范围 [您定义不同范围的含义]，重定向 uri 和 response_type [oauth2 定义了不同的 response_type，但让我们专注于'代码'])
• 用户登录到您的站点并接受代表用户访问您的 API 的客户端。当用户接受这一点时，您将生成一个授权（授权包含用户的信息、请求的凭据 [范围] 以及可以“声明”授予访问权限的客户端）。
• 然后用户被重定向到客户端请求的 redirect_uri（当客户端将用户发送到您的身份验证站点时），并且在 URL 参数中您将包含授权代码（它只是一个 id）。
• 在这个阶段，客户端将向您的 API 发出请求，提供授权代码、他自己的 client_token、他的 client_secret 和 grant_type (authorization_code)，他将得到以下响应：authorization_token、refresh_token、token_type (在这种情况下，Bearer)、expires_in（以秒为单位的过期时间）和范围。
• 在此之后，客户端将能够代表用户使用 access_token 向您的 API 发出请求，直到令牌过期。令牌过期后，客户端将不得不使用 refresh_token（而不是授权码）请求新的 access_token。

Answer 3

iandayman 的答案有很多很好的信息，但我认为更具体的答案可能会对您有所帮助。

所以对于初学者来说，客户端凭据授予不适合您。如果我们查看OAuth2 spec，客户端凭据授予是针对

当授权范围为 仅限于客户端控制下的受保护资源......当客户端代表自己行事时

这不适合您，原因有两个。
首先，您的客户控制下没有受保护的资源。您正在访问的所有资源要么未受保护（未登录的人上传），要么受最终用户的控制。此外，您不能在浏览器中保守秘密（例如客户端秘密）；您的应用程序的任何用户都可以使用浏览器的开发人员工具来查看和泄露机密。
其次，正如我所提到的，客户从不代表自己行事。它始终代表可能登录或未登录的用户。

您希望授予资源所有者密码凭据。
当用户未登录时（如您提到的上传），您没有授权。当用户登录时，您将他们的凭据发送到授权服务器。如果密码与用户名匹配，授权服务器会生成一个令牌，并保留从该令牌到用户的映射并返回该令牌。然后，每次您的客户端向已登录用户发出另一个请求时，您将该令牌放入 Authorization 标头中。在后端你说“如果授权标头中有一个令牌，找出它对应的用户，并将他们与这个上传相关联（或检查他们是否被允许上传）”。

用户注册如何运作？很简单，你发布一些用户对象，比如

name: jim beam
username: jimb
password: correct horse battery staple

到您的用户创建端点（POST /users 或其他东西）。您生成盐并对密码进行哈希处理，然后将用户信息与盐和哈希一起存储在数据库中。此端点上没有任何授权。

希望这是您正在寻找的更多内容。