把我老式的脑袋绕在OAuth周围。。。。
除了请求/响应机制和授权/身份验证往返（我认为我支持不足）之外，我正在努力将我的MyUser对象（无论其中可能包含什么）映射到OAuth令牌，如果（当时实际上是，而不是如果）用户杀死了我可能在浏览器上丢弃的任何cookie（加密或其他）。
我在最初的登录时得到了MyUser的信息（称之为我网站的"注册"），但现在MyUser回来了，所有的cookie都不见了，所以他只是"用户"。公平地说，用户必须再次进行OAuth登录，但现在我无法将新的Token/Secret与MyUser数据关联起来。
我错过了什么？
---编辑：2012年8月2日----
让我重申一下（我很确定我对此很敏感，但我想这就是为什么）：
正如Replies中所指出的，每个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。
现在英雄离开了，出于某种原因杀死了他的饼干，然后又回到了我们身边
现在他决定登录Twitter。我没有饼干，所以我不知道他是谁，我们再次经历这个过程。
对我来说，他看起来像一个新用户，所以一旦推特给我发了一个代币，我就开始问他注册问题，这显然是不对的。
事实证明，推特没有回复电子邮件地址，所以我无法匹配，即使他们回复了（我想几乎其他人都回复了），Hero likley也有不止一封电子邮件。
在我看来，我在两次（或多次）登录之间唯一的联系是我设置的任何未删除的cookie。
我们是说整个OAuth2.0机制都依赖于此吗？我不敢相信这是对的，但别想别的办法，所以我一定错过了什么，是吗？
如果您也使用OAuth作为登录机制，那么请确保与您交谈的任何提供商都有某种方式为用户返回稳定的ID。该ID是您在数据库中查找用户时使用的密钥。
不同的提供商有不同的方法来做到这一点。对于谷歌，这里有关于如何使用OAuth 2.0进行身份验证的详细信息。对于Twitter，他们使用OAuth 1.0，并在将代码交换为访问令牌时返回用户ID。脸书也有自己的做法。