OAuth 2.0 资源所有者访问令牌实现

OAuth 2.0 resource owner access token implementation

我已经通读了 RFC6749 的 OAuth 2.0 以及相当多的 SO 问题和博客文章，但我仍然不清楚如何实现其中的一些内容。

目前，用户通过网页上的表单登录，并使用调用数据库的应用程序来获取和操作资源。目标是从应用程序中抽象出资源。

在 OAuth 2.0 的上下文中，我发现：

我还了解 OAuth 2.0 通过授权授予和访问令牌（至少）工作。我想在我的授权服务器中支持密码和客户端凭据授权类型。我们还假设我的 Web 应用程序是唯一授权访问 API.

的应用程序

关于使用资源所有者授权授予类型实施的问题：

  1. 是否每个用户都会收到自己的访问令牌？我假设是，因为我需要区分不同的用户以用于其他目的（例如授权）
  2. 一个用户可以接收多个访问令牌吗？ （例如，如果他们登录应用程序的时间超过 1 user-agent/computer）
  3. 我在 Authorization HTTP header 中向授权服务器发送什么？ （记住我只有一个客户）
  4. 如何从访问令牌中获取用户的身份？ （例如用户 ID/username）
  5. 在 Web 应用程序的 $_SESSION 中存储访问令牌和刷新令牌是否安全？

我的总体意见是，您不应使用资源所有者密码凭据授予来实现您想要的，而应使用授权码授予。这将允许您独立于客户端（应用程序）升级您的身份验证方式并实现 SSO。

  1. 接收访问令牌的不是用户（资源所有者），而是客户端（您的网络应用程序）。当使用资源所有者密码授予或授权代码授予时，您的客户会收到每个用户的访问令牌。使用客户端凭据授予时，最合乎逻辑的做法是获取访问令牌，以便所有具有相同令牌的用户在特权模式下运行。

  2. 通常不会，因为在 OAuth 2.0 中，用户不会登录应用程序。除非使用资源所有者密码凭证流程，否则它们会这样做。在这种情况下，应用程序应该注意到该用户已有一个访问令牌，并且不会请求一个新的访问令牌。

  3. 这似乎混淆了 Authorization header 中针对资源服务器的访问令牌的使用与针对授权服务器的客户端或资源所有者的身份验证。在后一种情况下，不需要 HTTP 基本身份验证，这只是 Client/Resource 所有者身份验证的选项之一。

  4. 如果要对用户进行身份验证，则需要应用 OpenID Connect，这是一种建立在 OAuth 2.0 之上的用户身份验证协议。另请参阅 Q2 中的先前 link。如果您想要有关在早些时候向客户提供访问令牌的用户的信息，那么您可以针对 API 使用访问令牌，它会为您提供该信息，或者您可以将其嵌入访问令牌中（例如在 JWT 访问令牌中）。

  5. 这是一种常见的做事方式，与您的 PHP 安装一样安全，请参阅：Security of $_SESSION array