3

我正在构建一个非常典型的网络应用产品。未来它可能会有相应的移动应用程序。我正在使用 REST API 从头开始​​构建它，该 API 使用 OAuth2 进行保护。我已经让 OAuth2 正常工作，并且能够使用各种授权类型成功连接。

我有点困惑的是用于实际网络应用程序的授权类型。这是我的想法：

公共 API 访问

在用户登录 Web 应用程序之前，用户注册和密码重置等操作需要一些 API 访问权限。我正在考虑使用client_credientials授权类型。一个简单的客户端 ID 和秘密验证，以换取访问令牌。

但是，似乎完全没有必要为每个公共请求甚至每个会话请求访问令牌。只生成一个我的网络应用程序将始终使用的访问令牌似乎更有意义。

然而，这似乎与 OAuth 的工作原理背道而驰。例如，访问令牌过期。这样做的正确方法是什么？

私有用户 API 访问

接下来，为了让用户登录到我计划使用password授权类型（资源所有者密码凭据）的网络应用程序。这种方法允许我user_id使用访问令牌保存 - 所以我知道哪个用户登录了。此外，通过使用范围，我可以限制 API 内的访问。

我计划将访问令牌保存在 PHP 会话中。只要 PHP 会话处于活动状态，它们就会保持登录到 Web 应用程序。

这是适合用户登录的设计吗？

4

1 回答 1

4

对于公共 API 访问：

一种方法是一起跳过令牌，只使用基本 HTTP 身份验证进行 API 访问。您可以为此接受客户端凭据，并限制客户端可以使用客户端特定范围执行的操作。Github为所有 API 调用提供使用用户凭据的HTTP Basic 身份验证。

对于私人用户 API 访问：

Authentication这是一个有趣的问题，因为它开始突破和之间的界限Authorization。OAuth 用于Authorization，因此登录用户变得很危险。例如，会话管理是 OAuth2.0 规范未涵盖的内容。

但是，无论如何，这都是 OAuth2.0 的常见用途。您可以使用password授权类型或任何其他授权类型来获取访问令牌。一个主要的缺点是他们必须使用他们的密码信任您的应用程序（对于您自己的应用程序来说没什么大不了的，但对于第 3 方来说不是那么重要）。此外，在一个地方登录并不一定意味着在其他地方登录（而不是 SSO，您有“链接帐户”，因此会话是单独管理的）。解决此问题的一种方法是始终将用户发送到 oauth 授权端点，如果他们的会话在 OAuth2.0 提供者端处于活动状态，则使用访问令牌或授权代码将它们重新路由回客户端应用程序。这样，如果会话与 OAuth2.0 提供程序处于活动状态，客户端可以立即将它们登录。

于 2013-09-04T17:07:49.637 回答