为什么共享 session 来实现SSO不好？我正在学习SSO系统。
思考这个场景:
假设所有对业务服务的http请求都需要登录，业务服务需要通过CAS或SAML中的SSO服务来验证请求是否登录。如果有10个业务服务，每个服务的请求为1k req/s，那么SSO服务的请求为10k req/s。很难想象 SSO 服务能够坚持下去。
SO，业务服务中可能存在缓存机制来验证登录 token 。但是当用户注销时，SSO服务需要删除验证信息，并且业务服务也需要删除缓存验证信息。我认为这太复杂了。 SSO 服务需要告诉业务服务有些人已注销。那么为什么不是所有共享登录 token 的服务都验证信息呢？让SSO服务写，其他业务读。它提醒我共享 session 以实现 SSO。我想是否可以通过redis分布式集群共享登录 token 验证信息。但我听说分享会不好？所以为什么？
最佳答案
SSO 服务器是否可以处理那么多请求取决于您的部署。 CAS 的部署规模非常大，可以处理数十万个请求。它有所不同。
一般来说，SSO session 与您的应用程序 session 完全分开。通过 SSO 登录到应用程序后，您就为该应用程序建立了一个 session ，该 session 将持续到您将其配置为持续的时间。当它过期时，您的应用程序可能会决定再次针对您的 SSO 服务器进行身份验证。如果 SSO 服务器仍有 SSO session ，它将简单地重新发出适当的数据，并且您的应用程序将重新创建 session 。如果没有，它将向用户询问凭据，无论他们是什么，然后重做同样的事情。
应用程序的 session 问题完全是您和应用程序的问题。 SSO 服务器永远不应该参与其中。如果您的应用程序需要共享 session ，因为它是集群的，那么您应该共享 session 。没有人说这是一个坏主意。但是，您通常希望确保您的应用程序尽可能无状态，因为这将使集群部署更容易。
当您从应用程序注销时，您的应用程序 session 消失，但 SSO session 可能仍然存在。因此，您将立即返回应用程序，因为无需提供凭据。如果您愿意，您可以注销应用程序和 SSO 服务器。
如果您通过 SSO 登录了所有其他应用程序，并且您希望通过注销其中一个应用程序来注销所有应用程序，这称为 SLO。您的 SSO 服务器将需要联系已为其创建票证的每个应用程序并联系它们以注销。或者，您可以销毁所有应用程序的共享 session ，假设它们都属于同一套件。
关于session - 为什么共享 session 来实现SSO不好？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/36246071/