为什么共享会话实施SSO不好？我正在学习SSO系统。
考虑这个场景：
假设所有对业务服务的http请求都需要登录，业务服务需要通过询问CAS或SAML中的SSO服务来验证请求是否登录。如果有10个业务服务，并且每个服务的请求都是1k req/s，那么SSO服务的请求是10k req/s。 SSO服务可以保留的图像很难。
因此，业务服务中可能存在用于验证登录令牌的缓存机制。但是当用户注销时，SSO服务需要删除验证信息，业务服务也需要删除缓存验证信息。我觉得这太复杂了。 SSO服务需要告诉业务服务有些人注销。那么为什么并非所有服务都共享登录令牌验证信息？让SSO服务写，和其他业务阅读。它提醒我sharing the session to implement SSO。我想如果我可以通过 redis分布式群集分享登录令牌验证信息。但我听说分享会不好？所以为什么？
答案 0 :(得分：0)
SSO服务器是否可以处理那么多请求取决于您的部署。 CAS的部署非常庞大，可处理数十万个请求。它有所不同。
通常，SSO会话与应用程序会话完全分开。一旦您通过SSO登录到应用程序，您就已经为该应用程序建立了一个会话，只要您将其配置为持续，该会话将持续。当它到期时，您的应用程序可能会决定再次对您的SSO服务器进行身份验证。如果SSO服务器仍有SSO会话，它将只重新发出相应的数据，您的应用程序将重新创建会话。如果没有，它将向用户挑战凭证，无论他们是什么，并重做相同的。
应用程序的会话问题完全属于您和应用程序的问题。 SSO服务器永远不应该参与其中。如果您的应用程序需要共享会话，因为它是群集的，那么您应该共享会话。没有人说这是个坏主意。但是，您通常希望确保应用程序尽可能无状态，因为这将使集群部署更容易。
当您从应用程序注销时，您的应用会话已消失，但SSO会话可能仍然存在。因此，您将重新进入应用程序，因为无需提供凭据。如果您愿意，可以退出应用程序和您的SSO服务器。
如果您通过SSO登录了所有其他应用程序，并且您希望通过注销一个来注销，则称为SLO。您的SSO服务器需要联系其为其创建故障单的每个应用程序，并与他们联系以进行注销。或者，您可以销毁所有应用程序的共享会话，假设它们都属于同一套件。