• 登录时生成会话令牌。
• 将该会话令牌存储在数据库中。
• 验证时检查有效的会话令牌。

你所拥有的差不多。只需考虑您是否想一次拥有多个有效会话以及如何处理到期会话。

编辑下面的疯狂评论线程

虽然可以向客户端提供由第二台服务器验证的令牌，而无需与第一台服务器通信，但这很丑陋并且涉及大量工作。这种情况不允许使会话无效，除非客户端处理它。还需要一定的令牌传递时间窗口，令牌的时间戳，第二系统对令牌的跟踪，令牌传递中的签名或HMAC等。除非这两个系统在互联网上不能互相看到，否则避免完全是一团糟。

我收集到两个系统都可以访问同一个数据库，但是如果由于某种原因他们不能访问，那么将 API 暴露给可以远程验证的第二个系统也是合适的（secret.page?checkUser=token... 或这样的）。

如果没有 SSL，您将无法通过 Firesheep / MITM 攻击来防止会话劫持。

我的建议是用于主要用户身份验证的单个 Web 应用程序。

注意：由于 cookie 的性质，此方法仅在 web 应用程序共享一个公共域时才有效。（即 appone.example.com 和 apptwo.example.com）
openid 做了类似的事情，但绕过了 cookie 问题，你可能想看看。

这将如何工作。

1. 用户将他的浏览器指向应用程序 A。应用程序 A 检查有效的 cookie/会话/任何内容。
   1. 它首先检查它自己的会话/cookie 信息。
   2. 如果找不到自己的 cookie，它会查找 Auth App 的“传输”cookie。
      1. 如果找到，则为该应用创建一个新会话。用户刚刚登录。
2. 当它发现这无效或丢失时，它会将页面转发给 Auth App。
3. Auth App 在结束时检查有效会话。
   1. 当它发现这个缺失时，它会弹出一个登录屏幕等。
4. 一旦它有一个有效的会话，Auth App 就会为该应用程序设置一个特定的“传输”cookie，并将此人重定向回 App A。

您应该在此传输 cookie 中添加额外信息，例如 -

1. 用户名
2. 授权时间
3. IP地址。
4. 随机数。

请参阅以下示例。 https://www.login.mtu.edu/docs/public/mtuiso/howitworks2.html

从用户的角度来看，这几乎是无懈可击的。 例如。

1. 用户将浏览器指向应用程序 A。
2. 应用 A 是否与 Auth App 进行身份验证。（需要用户登录等）
3. 用户单击转发到应用 B 的链接。
4. App B 使用 Auth App 进行身份验证。（这一次，Auth 应用程序本身已经有一个 cookie。）
   1. App B 转发给 Auth App。
   2. Auth App 找到 cookie，然后立即创建传输 cookie 并转发给 App B。
   3. 用户甚至没有注意到这一点，并立即发现自己在 App B 中。

四种选择，第一种是最高成本（金钱和性能两者），第三种是最便宜的

1. 部署 Siteminder、Novell、Tivoli 等解决方案

2. 在数据库中维护会话状态。为此。这种方法的问题是很难跟踪注销、会话到期和在两个应用程序之间传播此信息。因为在每个请求之前查询数据库会非常昂贵

3. 使用第三个应用程序只是为了管理会话状态。此应用程序不向最终用户公开，仅限制在网络内，只能访问两个应用程序它将所有用户的状态存储在应用程序上下文中，两个应用程序向该应用程序发送请求

   登录事件 注销事件 处理任何请求以检查会话有效性之前的会话到期事件

4. 使用 cookie（假设两个应用程序共享相同的父域）

   创建一个包含用户名 + salt/ecret 密钥的 cookie，并且这个加密的密钥和加密密钥都与两个应用程序一起使用 来自用户的任何请求都将携带这个 cookie（cookie 路径设置为 /）所以如果 cookie 包含用户名，其他应用程序信任用户已登录其他应用程序