我正在为我的网站构建一个扩展的登录/注册区域，其中包括 OpenID、OAuth (Twitter) 和 OAuth 2.0 (Facebook) 登录选项。
一旦用户成功通过身份验证并且我已经将他们的访问令牌存储在我的数据库中并编写了一个将用户链接到他们的登录状态的 cookie，我应该使用什么最佳实践来确定用户的访问令牌仍然有效？似乎必须为对我网站的每个请求调用身份验证提供程序会减慢用户的速度，我无法想象其他网站正在这样做。
我的猜测是我应该存储一个仅对当前浏览器会话有效的 cookie，因此当用户关闭浏览器时该 cookie 将过期，从而强制在下一个请求时生成一个新的访问令牌（以及一个新的 cookie 匹配）。如果用户明确注销，我也会提前使 cookie 过期。
我唯一的问题当然是，例如，如果用户在一个选项卡中打开我的网站，然后他们在另一个选项卡中打开他们的身份验证提供程序并退出该网站，但继续浏览我的网站，他们不会退出我的网站，即使从技术上讲，他们应该能够使用第三方提供商退出。
这是那些“无关紧要”的场景之一，还是我以错误的方式处理整个事情？
服务提供商绝对不希望您对进入您服务的每个请求都 ping 他们的服务。甚至谷歌也不愿想到这一点。您可以设置某种超时以每 5 分钟检查一次，但我认为您对会话 cookie 的想法是理想的。但是，是的，这取决于您要达到的目标。
如果您只是使用这些服务来登录用户，仅此而已，那么在您验证用户已登录并设置您自己的会话或持久 cookie 后立即丢弃您拥有的访问令牌。您不再需要他们的访问令牌。
如果您确实想访问这些服务上的用户数据，那么当然要保留访问令牌。但是您可能仍然应该保持自己的用户是否登录的概念。如果我没记错的话，这些访问令牌通常是长期存在的（无论如何在 OAuth 1.0a 中）并且当用户返回以确定是否用户就是他们所说的那个人，除非您有自己的 cookie 或者您再次通过登录服务发送给他们。
如果您只是将 OAuth / OpenId 用于登录目的，我认为您不必担心这些。您应该担心的是您的用户是否是他们所说的（OAuth/OpenId 提供者）用户。
如果您的网站打算与 Twitter 和 Facebook 交互，那是另一回事，但它仍然可以自行解决。当您尝试与 FB 交互时，当您的用户已从那里注销时，FB 将提示您的用户再次登录。
归根结底，我认为这真的不是问题。