我的公司已经用ForgeLock实现了SSO。我们已经集成了两个应用程序(比如app1和app2)登录，应用程序的数量将不断增长。关于预期工作的查询：
登录行为：
- 用户登录app1并开始在其中执行某些操作
- 打开新的选项卡/窗口，点击URLapp2URL
因此，与其再次要求app2的登录凭据，他应该直接登录到app2的主页。正确的但如果发生这种情况，点击app2将如何将哪个用户已登录app1的信息传递回app2？是通过浏览器的cookie读取还是通过该系统/计算机的登录用户？如果是，我们如何读取登录用户，如果应用程序暴露在外部给互联网用户怎么办？互联网用户可以访问它吗？在这种情况下，读取登录用户可能没有意义，我们的一些应用程序暴露在互联网上。
注销行为：
如果用户完成了他在app1上的工作并单击注销，但正在进行他在app2上的工作(例如，表单提交或任何多步骤活动)，那么将他从app2注销对他来说也是不公平的，因为他可能会失去迄今为止所做的工作。但这就是预期的工作方式吗？
从一个应用程序注销用户是否应该将其从集成了同一SSO的所有应用程序注销？如果是这样的话，这意味着应用程序端的会话不会失效，也会向SSO服务器发送注销请求。但这也意味着所有应用程序都需要检查每个请求，如果用户已经注销？我觉得要求太高了。对于已登录用户的每个请求，我还需要检查他是否已从SSO注销？它应该是这样工作的吗？
经过大量研究，我终于发现：
登录行为：
对！如果用户登录到app1，然后在同一浏览器的另一个选项卡/窗口中点击app2的url(非专用模式)，则他应该已经登录到app2。app2不需要单独登录。
app2如何知道登录哪个用户
这是通过所有与SSO集成的应用程序读取cookie来完成的。SSO实现将在用户的浏览器窗口中为应用程序可用的特定域设置cookie。这个cookie会告诉应用程序哪个用户已经登录。现在应用程序知道谁是经过身份验证的用户，应用程序可以做自己的特定事情，比如检查授权和其他常见的事情。但是，如果用户使用不同的浏览器，比如app1-chrome和app2-firefox，那么由于cookie无法共享，在这种情况下，用户必须再次通过身份验证过程。无论应用程序是否暴露在互联网上，这种行为都将保持不变。
注销行为：
有不同的口味可供选择。没有硬性规定。如果你想从一个应用程序注销也意味着从所有其他应用程序注销，那么是的，这是可以做到的。一种方法是在所有请求中传递浏览器cookie中SSO实现设置的"令牌">。如果在应用程序端接收到有效的令牌，则完成该请求，否则将其注销。
此外，如果您可以在一个应用程序已注销的情况下处理其他应用程序，那么您不需要在每个请求中传递令牌，并且注销只能在应用程序级别完成无需请求SSO注销。