了解用户 ID 在 3 足 OAuth 会话中的使用？
经过今天一次真正的绞尽脑汁的会议后，我觉得我对三足 OAuth 身份验证了解得相当好。我仍然无法理解的是用户 ID 的使用。到目前为止我看到的例子似乎都只是在示例脚本的顶部任意分配一个用户 ID 并运行。这让我很困惑。
我看到的大多数示例代码似乎都围绕使用用户 ID 和 OAuth 服务器的消费者密钥来管理 OAuth“会话”的概念（用引号引起来，因为我不想将该术语与浏览器“会话”混为一谈） ”）。例如，我见过的数据库示例代码根据用户 ID 和消费者关键字段值来存储和检索令牌以及涉及的其他信息。
我现在处于不确定的状态，其中一些相互竞争的理解片段相互竞争和冲突：
1）如果我通过消费者密钥和用户 ID 字段对 OAuth 会话详细信息记录或“OAuth 存储”查找的理解是正确的，那么这是否要求我为使用与 OAuth 服务器连接的应用程序的每个用户拥有不同的用户 ID？
2）如果#1是正确的，那么我如何避免为不同的用户创建自己的用户帐户，这是我试图避免的？我正在尝试编写充当启用 OAuth 的服务的前端的软件，因此我不需要拥有自己的用户记录和随之而来的维护麻烦。相反，我将让 OAuth 服务器来处理这个难题。然而，我的方法的缺点似乎是我必须在每个会话中重新授权用户，因为没有我自己的持久用户帐户/ID，我无法查找先前授予的“好撤销”访问令牌，正确的？
3）令我困扰的是，我读到一些 OAuth 服务器不允许在请求未经授权的令牌期间传递动态指定的回调 URL，从而无法将消费者密钥和用户 ID 传递回自己。相反，您在注册为开发者/消费者时指定回调 URL，仅此而已。幸运的是，我正在处理的 OAuth 服务器确实允许该功能，但是，如果我正在处理不支持该功能的 OAuth 服务器，那么使用消费者密钥和用户 ID 对的整个想法是否会受到影响？索引 OAuth 会话详细信息？
After a real brain bending session today I feel like I understand 3-legged OAuth authentication fairly well. What I'm still having trouble understanding is the use of the User ID. The examples I have seen so far all seem to just arbitrarily assign a user ID at the top of the sample script and go. That confuses me.
Most of the sample code I have seen seems to center around the concept of using a user ID and the OAuth server's consumer key for managing an OAuth "session" (in quotes because I'm not trying to conflate the term with a browser "session"). For example, the database sample code I've seen stores and retrieves the tokens and other information involved based on the user ID and consumer key field values.
I am now in that state of uncertainty where a few competing fragments of understanding are competing and conflicting:
1) If my understanding of the OAuth session details record or "OAuth store" lookups is correct, via the consumer key and user ID fields, then doesn't that mandate that I have a disparate user ID for each user using my application that connects with an OAuth server?
2) If #1 is correct, then how do I avoid having to create my own user accounts for different users, something I am trying to avoid? I am trying to write software that acts as a front end for an OAuth enabled service, so I don't need to have my own user records and the concomitant maintenance headaches. Instead I'll just let the OAuth server handle that end of the puzzle. However, it seems to follow that the downside of my approach would be that I'd have to reauthorize the user every session, since without my own persistent user account/ID I could not lookup a previously granted "good to revoked" access token, correct?
3) What bothers me is that I have read about some OAuth servers not permitting the passing of a dynamically specified callback URL during the requesting of the unauthorized token, making the passing of a consumer key and a user ID back to yourself impossible. Instead you specify the callback URL when you register as a developer/consumer and that's that. Fortunately the OAuth server I'm dealing with does allow that feature, but still, if I was dealing with one that wasn't, wouldn't that throw a giant monkey wrench into the whole idea of using the consumer key and user id pair to index the OAuth session details?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是Lode的问题：
可以使用 OAuth 对用户进行身份验证，而无需在消费者应用程序中拥有本地帐户，但是您必须拥有某种会话机制（cookies/get params），以便拥有一些内部会话表示形式，您可以在其中存储oauth_token。
例如，如果有人登陆您的 Web 应用程序，并且您的应用程序是某个 OAuth 提供商的使用者，您将必须在您的站点上为最终用户创建本地会话：例如使用 cookie。然后，您将最终用户发送到 OAuth 提供程序以获取令牌授权，以便您的应用程序可以从提供程序获取受保护的资源。目前你对用户一无所知，也不关心他的身份。您只想使用提供商提供的一些受保护的信息。
当用户成功授权后从提供商处返回并带回 oauth_token 时，您现在必须将此令牌存储在您之前为用户创建的会话中。只要您保留会话（以及令牌，如果需要进一步请求资源），您就可以认为最终用户已登录。在您删除他的会话或令牌过期的那一刻，您可以考虑他不再登录。这样您就不必制作自己的用户数据库表或存储机制。
但是，如果您需要在应用程序中拥有一些有关用户的持久信息，并将在用户会话（登录）之间使用这些信息，则您必须维护自己的用户，以便知道与哪个用户关联该信息。
至于openid和oauth的区别——从本地账户的角度来看，没有区别。都是一样的。 ，使用 openid 时，您会立即收到一些基本用户信息（电子邮件等），而使用 oauth 时，您会收到一个令牌，并且必须再发出一个请求才能获取基本用户信息（电子邮件等）。
区别仅在于 但是，如果您要使用 OpenID 或 OAuth，则本地帐户会有所不同。
This is an answer to the question by Lode:
It's possible to use OAuth for authentication of users without having local accounts at the consumer application, but you've got to have some kind of session mechanism (cookies/get params) in order to have some internal session representation in which you would store the oauth_token.
For example, if someone has landed to your web application, and your application is a consumer of some OAuth provider, you will have to create a local session at your site for the end-user: for example with a cookie. Then you send the end-user to the OAuth provider for authorization of a token, so that your application can get protected resources from the provider. Currently you know nothing about the user and you don't care about his identity. You just want to use some protected information from the provider.
When the user comes back from the provider after successful authorization and brings back the oauth_token, you now have to store this token in the session that you previously created for the user. As long as you keep your session (and the token if it's needed for further requests for resources), you can consider that the end-user is logged in. In the moment that you delete his session or the token expires, you can consider him no more logged-in. This way you don't have to make your own users DB table or storage mechanism.
However, if you need to have some persistent information about the users in your application, that will be used between user sessions (logins), you have to maintain your own users in order to know with which user to associate the information.
As for the difference between openid and oauth - from the perspective of local accounts, there is no difference. It's all the same. The difference is only that with openid you receive immediately some basic user info (email, etc.) while with oauth you receive a token and you have to make one more request to get the basic user info (email, etc.)
There is no difference however in regard to local accounts, if you're going to use OpenID or OAuth.
我将尝试讲述我对您提出的问题的看法，并希望这能够澄清一些问题...
首先，这个想法是 OAuth 服务器正在保护第三方应用程序（消费者）希望保护的某些 API 或数据使用权。
如果您在 OAuth 服务器后面的 API 上没有用户帐户或数据，那么为什么消费者应用程序想要使用您的服务 - 它将从您那里得到什么？话虽这么说，我无法想象这样一个场景：您有一个 OAuth 服务器，但它背后没有用户帐户。
如果您只想使用 OAuth 进行用户登录，而不通过 API 提供用户数据，那么最好使用 OpenID，但同样您必须拥有用户帐户。
您的观点是正确的，您通过消费者密钥和（您的）用户 ID 进行查找，这是因为协议设计。
一般流程为：
我认为，如果您是提供商，就不能没有本地用户在您身边。
关于回调问题，我认为如果您有动态或静态（注册时）回调 URL，那么在如何使用消费者密钥和用户 ID 处理 OAuth 会话方面没有区别。 OAuth 规范本身根本不强制要求有回调 URL - 它是一个可选参数，可以选择每次发送，也可以选择在开始时仅注册一次。 OAuth 提供商决定最适合他们使用的选项，这就是存在不同实现的原因。
当提供者在数据库中有一个静态定义的回调 URL 并与消费者连接时，它被认为是一种更安全的方法，因为最终用户无法重定向到“错误”回调 URL。
例如，如果一个邪恶的人窃取了 GreatApp 的消费者密钥，那么他可以使自己成为一个消费者 EvilApp，可以模仿原始 GreatApp 并向 OAuth 服务器发送请求，因为它是原始的。但是，如果 OAuth 服务器仅允许静态（预定义）回调 URL，则 EvilApp 的请求将始终以 GreatApp 回调 URL 结束，并且 EvilApp 将无法获取 Access Token。
I will try to tell my view on the issues that you raised and hope that will clear things a little bit...
First, the idea is that the OAuth server is protecting some API or DATA, which third party applications (consumers) want to access.
If you do not have user accounts or data at your API behind the OAuth server, then why would a consumer application want to use your service - what is it going to get from you? That being said, I can't imagine a scenario, where you have an OAuth server and you don't have user accounts behind it.
If you just want to use OAuth for login of users, without providing user data through API, then it's better to use OpenID, but again you will have to have user accounts at your side.
Your point is correct that you make lookups via Consumer Key and (Your) User ID, and that is because of the protocol design.
The general flow is:
I don't think that you can go without local users at your side, if you are a provider.
About the callback question, I think there's no difference if you have dynamic or static (on registration) callback URL in regard to how you handle OAuth sessions with consumer keys and user id. The OAuth specification itself, does not mandate to have a callback URL at all - it's an optional parameter to have, optional to send every time, or optional to register it only once in the beginning. The OAuth providers decide which option is best for them to use, and that's why there are different implementations.
When the provider has a static defined callback URL in the database, connected with a consumer, it is considered a more secure approach, because the end-user cannot be redirected to a 'false' callback URL.
For example, if an evil man steals the consumer key of a GreatApp, then he can make himself a consumer EvilApp that can impersonate the original GreatApp and send requests to the OAuth server as it was the original. However, if the OAuth server only allows static (predefined) callback URL, the requests of the EvilApp will always end at the GreatApp callback URL, and the EvilApp will not be able to get Access Token.