将我的老式头脑包裹在 OAuth 周围......
除了请求/响应机制和 Authorize / Authenticate 往返行程（我想我理解）之外，我还在努力将我的 MyUser 对象（可能包含的任何内容）映射到 OAuth 令牌，如果（实际上是何时，而不是如果）用户杀死我可能在浏览器上放置的任何 cookie（加密或其他方式）。
我在原始登录中获得了 MyUser 信息（将其称为我的网站的“注册”），但现在 MyUser 回来了，所有 cookie 都消失了，所以他只是“用户”。很公平，用户必须再次进行 OAuth 登录，但现在我无法将新的 Token / Secret 与 MyUser 数据相关联。
我错过了什么？
--- 2012 年 8 月 2 日编辑 -----
让我重申一下（我很确定我对此很敏感，但我猜这就是这里的目的）：
正如回复中所指出的，每个 OAuth 提供者都有自己的机制。我们可以导航这些并为用户取回访问令牌。
假设 Hero 使用 Facebook 在我的网站上注册。FB 返回他的 FB 用户 ID 和名称以及访问令牌。我们足够聪明地请求并获取他的 FB 电子邮件，并在让他进入之前询问他一些其他注册 q。然后我们将其保存在我们的数据存储中（链接到我们自己的用户记录）：
OurUserId : 1234
oAuthProviderName : Facebook
oAUthProviderUserId: xxxxx
oAuthProviderUserEmail: hero@mlb.com
oAuthProviderUserName: iBeHero
oAuthToken: entracingly-unique-string-of-goop
oAuthSecret: moredata
.... etc.
并设置一个cookie来识别他是我们的用户#1234。
现在英雄走了，出于某种原因杀死了他的饼干，然后又回到了我们身边。
现在他决定用 Twitter 登录。我没有饼干，所以我不知道他是谁，我们再次经历这个过程。
对我来说，他看起来像一个新用户，所以一旦 Twitter 给我发了一个令牌，我就开始问他注册问题，显然不对。
结果 Twitter 没有返回电子邮件地址，所以我无法匹配，即使他们这样做了（我想几乎其他所有人都这样做了）Hero likley 有不止一个电子邮件。
在我看来，我在两次（或多次）登录之间唯一的联系是我设置的任何未删除的 cookie。
我们是说整个 OAuth2.0 机制都依赖于此吗？我不敢相信这是对的，但看不到另一种方式，所以我一定错过了什么，是吗？