2

今天经过真正的大脑弯曲会议后，我觉得我对 3-legged OAuth 身份验证非常了解。我仍然无法理解的是用户 ID 的使用。到目前为止，我所看到的示例似乎都只是在示例脚本的顶部任意分配了一个用户 ID，然后运行。这让我很困惑。

我看到的大多数示例代码似乎都围绕使用用户 ID 和 OAuth 服务器的消费者密钥来管理 OAuth“会​​话”的概念（在引号中，因为我不想将该术语与浏览器“会话”混为一谈”）。例如，我见过的数据库示例代码根据用户 ID 和消费者键字段值存储和检索令牌和其他相关信息。

我现在处于不确定状态，其中一些相互竞争的理解片段相互竞争和相互冲突：

1) 如果我通过消费者密钥和用户 ID 字段对 OAuth 会话详细信息记录或“OAuth 存储”查找的理解是正确的，那么这并不要求我为使用我的应用程序连接的每个用户都有一个不同的用户 ID使用 OAuth 服务器？

2）如果＃1是正确的，那么我如何避免为不同的用户创建自己的用户帐户，这是我试图避免的？我正在尝试编写充当启用 OAuth 的服务的前端的软件，因此我不需要拥有自己的用户记录和随之而来的维护难题。相反，我将让 OAuth 服务器处理难题的那一端。然而，似乎我的方法的缺点是我必须在每个会话中重新授权用户，因为没有我自己的持久用户帐户/ID，我无法查找以前授予的“可撤销”访问令牌，正确的？

3) 困扰我的是，我读到一些 OAuth 服务器不允许在请求未经授权的令牌期间传递动态指定的回调 URL，这使得将消费者密钥和用户 ID 传递回自己是不可能的。相反，您在注册为开发者/消费者时指定回调 URL，仅此而已。幸运的是，我正在处理的 OAuth 服务器确实允许该功能，但是，如果我正在处理一个不支持的 OAuth 服务器，那不会在使用消费者密钥和用户 ID 对的整个想法中抛出一个巨大的猴子扳手索引 OAuth 会话详细信息？

4

2 回答 2

2

这是Lode 对问题的回答：

不仅提供者需要有用户 ID（这听起来合乎逻辑）而且客户端也需要，这是否正确？因此，客户端（使用 OAuth 作为登录系统）需要创建一个用户（带有 ID），然后才能通过 OAuth 服务器成功验证他们。当身份验证失败或未授予访问权限时，使您有很多空用户帐户。

可以使用 OAuth 对用户进行身份验证，而无需在消费者应用程序中拥有本地帐户，但是您必须拥有某种会话机制（cookies/get params）才能拥有一些内部会话表示，您可以在其中存储oauth_token。

例如，如果有人登陆了您的 Web 应用程序，并且您的应用程序是某个 OAuth 提供者的消费者，您将必须在您的站点上为最终用户创建一个本地会话：例如使用 cookie。然后，您将最终用户发送给 OAuth 提供者以授权令牌，以便您的应用程序可以从提供者那里获得受保护的资源。目前您对用户一无所知，也不关心他的身份。您只想使用提供商提供的一些受保护信息。

当用户在成功授权后从提供者返回并带回 oauth_token 时，您现在必须将此令牌存储在您之前为用户创建的会话中。只要您保留会话（以及令牌，如果需要进一步请求资源），您就可以认为最终用户已登录。在您删除他的会话或令牌过期的那一刻，您可以考虑他不再登录。这样您就不必创建自己的用户数据库表或存储机制。

但是，如果您需要在应用程序中保留一些关于用户的持久信息，这些信息将在用户会话（登录）之间使用，您必须维护自己的用户才能知道与哪个用户关联这些信息。

至于openid和oauth的区别——从本地账户来看，没有区别。全部都是一样。不同之处仅在于，使用 openid 您会立即收到一些基本用户信息（电子邮件等），而使用 oauth 您会收到一个令牌，并且您必须再发出一个请求才能获取基本用户信息（电子邮件等）

但是，如果您要使用 OpenID 或 OAuth，则本地帐户没有区别。

于 2012-08-28T09:27:10.617 回答
1

我会试着谈谈我对你提出的问题的看法，并希望这能澄清一些事情……

首先，这个想法是 OAuth 服务器正在保护第三方应用程序（消费者）想要访问的一些 API 或数据。

如果您在 OAuth 服务器后面的 API 中没有用户帐户或数据，那么消费者应用程序为什么要使用您的服务 - 它会从您那里得到什么？话虽如此，我无法想象有一个 OAuth 服务器但背后没有用户帐户的场景。

如果您只想使用 OAuth 登录用户，而不通过 API 提供用户数据，那么最好使用 OpenID，但同样您必须拥有用户帐户。

您的观点是正确的，您通过消费者密钥和（您的）用户 ID 进行查找，这是因为协议设计。

一般流程是：

  1. OAuth 服务器（提供者）向消费者应用程序发出未经授权的请求令牌
  2. 消费者发送最终用户在 OAuth 服务器（提供者）授权请求令牌
  3. 最终用户授权令牌后，将颁发访问令牌并将其提供给消费者（我在这里跳过了一些细节和步骤，因为它们对于我想说的并不重要，例如消费者在结尾）
  4. 在授权步骤中，是您的 OAuth 服务器创建并保存为一对 - 哪个本地用户（提供者的本地用户）授权了哪个消费者（消费者密钥-用户 ID 对）。
  5. 之后，当消费者应用程序想要从 Provider 访问最终用户的 DATA 或 API 时，它只发送访问令牌，而不发送用户详细信息。
  6. 然后，OAuth 服务器（提供者）可以通过令牌进行检查，该令牌是在此之前已授权该令牌的本地 USER ID，以便将该用户的用户数据或 API 功能返回给消费者。

如果您是提供商，我认为您不能没有本地用户。

关于回调问题，我认为在如何使用消费者密钥和用户 ID 处理 OAuth 会话方面，您是否有动态或静态（注册时）回调 URL 没有区别。OAuth 规范本身并没有强制要求有一个回调 URL - 它是一个可选参数，每次发送都是可选的，或者在开始时只注册一次。OAuth 提供者决定哪个选项最适合他们使用，这就是为什么会有不同的实现。

当提供者在数据库中有一个静态定义的回调 URL 并与消费者连接时，它被认为是一种更安全的方法，因为最终用户不能被重定向到“假”回调 URL。

例如，如果一个邪恶的人窃取了 GreatApp 的消费者密钥，那么他可以使自己成为一个消费者 EvilApp，可以冒充原始 GreatApp 并向 OAuth 服务器发送请求，因为它是原始的。但是，如果 OAuth 服务器只允许静态（预定义）回调 URL，则 EvilApp 的请求将始终以 GreatApp 回调 URL 结束，EvilApp 将无法获取 Access Token。

于 2011-04-20T07:14:16.610 回答