了解在三方OAuth会话中使用用户标识吗？

Question

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

我见过的大多数示例代码似乎围绕使用用户标识和OAuth服务器的使用者密钥来管理OAuth“会​​话”的概念（在引号中，因为我没有试图将该术语与一个浏览器“会话”）。例如，我见过的数据库示例代码根据用户标识和消费者键字段值存储和检索涉及的标记和其他信息。

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

1）如果我的OAuth的会议细节记录或“OAuth的店”查找的理解是正确的，通过消费者密钥和用户ID字段，那么是否并非要求我为使用与OAuth服务器连接的应用程序的每个用户拥有完全不同的用户ID？

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

3）令我困扰的是，我已经阅读了一些OAuth服务器，它们在请求未授权令牌期间不允许传递动态指定的回调URL，从而使用户密钥和用户ID回传给自己不可能。相反，当您注册为开发人员/消费者时指定回调URL，就是这样。幸运的是，我正在处理的OAuth服务器确实允许使用该功能，但是如果我正在处理那个不支持的功能，那么这不会引发巨大的猴子扳机来使用使用消费者密钥和用户ID对的整个想法索引OAuth会话详细信息？

Answer 1

我试图告诉我的观点上，你提出的，并希望将清除的东西一点点问题...

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

如果您在OAuth服务器后面的API上没有用户帐户或数据，那么为什么消费者应用程序想要使用您的服务 - 将从您那里获得什么？话虽如此，我无法想象一个场景，你有一个OAuth服务器，并且你没有用户帐号。

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

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

的一般流程是：

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

我不认为你可以没有本地用户在你身边，如果你是一个提供者。

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

当提供者在数据库中有一个静态定义的回调URL，与消费者连接时，它被认为是更安全的方法，因为最终用户不能被重定向到“假”回调URL。例如，如果一个邪恶的人窃取了GreatApp的消费者密钥，那么他可以让自己成为消费者EvilApp，它可以模仿原始的GreatApp并将请求发送到OAuth服务器，因为它是原始的。但是，如果OAuth服务器仅允许静态（预定义）回调URL，则EvilApp的请求将始终在GreatApp回调URL处结束，EvilApp将无法获得访问令牌。

Answer 2

这是一个答案the question by Lode：

是不是正确的，不仅是供应商需要有用户ID（这听起来逻辑），而且客户端？因此，客户端（使用OAuth作为登录系统）需要先创建一个用户（带有ID），然后才能通过OAuth服务器成功进行身份验证。当身份验证失败或未授予访问权时，使您拥有大量空的用户帐户。

它可以使用为用户认证的OAuth没有在消费者应用程序有本地户口，但你必须有某种会话机制（饼干/获取PARAMS），以便有一些内部会议上表示你将在其中存储oauth_token。例如，如果有人登录到您的Web应用程序，并且您的应用程序是某个OAuth提供程序的使用者，则必须在您的站点为最终用户创建本地会话：例如使用cookie。然后，将最终用户发送给OAuth提供者以授权令牌，以便您的应用程序可以从提供者处获得受保护的资源。目前你对用户一无所知，你不关心他的身份。你只是想使用提供者提供的一些受保护的信息。

当用户成功授权后，来自于供应商回来，带回的oauth_token，您现在可以存储此令牌，您先前为用户创建会话。只要你保持你的会话（如果进一步请求资源需要这个令牌），你可以认为最终用户已经登录了。在你删除他的会话或令牌到期的那一刻，你可以考虑他不再登录。这样您就不必制作自己的用户数据库表或存储机制。

但是，如果您需要在应用程序中拥有关于用户的一些持久性信息，该信息将在用户会话（登录）之间使用，则必须维护自己的用户以便知道与哪个用户关联信息。

至于的OpenID和OAuth之间的区别 - 从本地账户的角度来看，没有什么区别。全部都是一样。所不同的仅仅是与OpenID的同时通过OAuth您收到一个令牌，你立即获得一些基本的用户信息（电子邮件等），你必须做出一个更请求来获取用户的基本信息（电子邮件等）

但是，如果您打算使用OpenID或OAuth，则与本地帐户无关。