将我老式的头脑包裹在OAuth周围......
除了请求/响应机制和授权/身份验证往返（我认为我还没有考虑），我正在努力将我的MyUser对象（无论可能包含哪些内容）映射到OAuth令牌，如果（实际上当，而不是）用户杀死我在浏览器上丢弃的任何cookie（加密或其他）。
我在原始登录时收到MyUser信息（称为我的网站'注册'），但现在MyUser回来了，所有的cookie都消失了，所以他只是'用户'。很公平，用户必须再次进行OAuth登录，但现在我无法将新的令牌/密钥与MyUser数据相关联。
我错过了什么？
---编辑2012年8月2日-----
让我重申一下（我很确定我对此很感兴趣，但我猜这是为了什么）：
正如回复中所指出的，每个OAuth提供商都有自己的机制。我们可以浏览这些并返回用户的访问令牌。
让我们说Hero使用Facebook在我的网站上注册。 FB返回他的FB用户ID和名称以及访问令牌。我们很聪明，可以请求并获取他的FB电子邮件，我们会在让他进入之前向他询问其他一些注册问题。然后我们将其保存在我们的数据存储区中（链接到我们自己的用户记录）：
OurUserId : 1234
oAuthProviderName : Facebook
oAUthProviderUserId: xxxxx
oAuthProviderUserEmail: hero@mlb.com
oAuthProviderUserName: iBeHero
oAuthToken: entracingly-unique-string-of-goop
oAuthSecret: moredata
.... etc.
并设置一个cookie以将他识别为我们的用户＃1234。
现在Hero离开了，出于某种原因杀了他的饼干，然后回到我们身边。
现在他决定用Twitter登录。我没有饼干所以我不知道他是谁，我们再次经历这个过程。
对我来说，他看起来像一个新用户，所以一旦Twitter发给我一个令牌，我就开始问他注册问题，显然不对。
原来Twitter没有返回电子邮件地址所以我无法与之匹配，即使他们这样做（我认为几乎所有人都这样做），Hero likley有多个电子邮件地址。
在我看来，两次（或多次）登录之间的唯一联系是我设置的尚未删除的cookie。
我们是说整个OAuth2.0机制都挂起了吗？我不能相信这是正确的，但是看不到另一种方式，所以我必须遗漏一些东西，是吗？
答案 0 :(得分：3)
如果您也使用OAuth作为登录机制，那么请确保您正在与之交谈的任何提供商都有某种方式为用户返回稳定的ID。该ID是您在数据库中查找用户时使用的密钥。
不同的提供商有不同的方法。对于Google，有关如何使用OAuth 2.0进行身份验证的详细信息为here。对于Twitter，他们使用OAuth 1.0并在交换访问令牌的代码时返回用户ID。 Facebook也有自己的方式。