有没有办法在微服务面前实现SSO？

Question

最近，我有一个项目，可以根据SSO(Single-Sign-On)为多个Web应用程序实施Beego Framework。最受欢迎的SSO项目是CAS，它需要中心的CAS服务器，以及每个Web应用程序之前的CAS客户端。不幸的是，似乎没有任何用Golang编写的官方CAS客户端，除了go-cas/cas和adanteng/cas，它们支持Beego。

但是CAS的工作流程有点复杂：重定向过多，CAS，Web应用程序和用户浏览器之间传输的票证太多。我无法弄清楚为什么人们将认证服务部署在所有网络应用程序的中心，而不是前面，如下图所示：

在此图中，首先在Authenticate Service中强制处理所有请求，如果成功通过身份验证，则生成会话ID，保存在cookie中，Redis由其他微服务共享。根本没有任何重定向或票证，只请求传输。

这个图表是可能的，还是我忽略了一些关键问题？

更新0

会话共享方式确实不具有可扩展性和模块性Nadh建议。如何在身份验证服务和下游服务之间的请求标题中传输用户信息，如姓名，电子邮件等，如Heipei在nginx-sso的创意工作？是否有可能使其作为SSO网关工作，如Sam Newman在书中分享Building Microservices？

更新1

更详细的图表如下所示，为了更清楚地描述我幼稚的想法，希望Heipei和Sam Newman没有太多的误解。

不是处理如此多的重定向和握手，而是首先在身份验证服务中处理所有请求，将来自MySQL的用户信息写入Redis作为会话提供程序，并将HTTP标头发送到下游服务，如果请求已成功通过验证。

通过这种方式，用户信息通过HTTP标头而不是上面的共享Redis作为Nadh警告传输，Redis可以使用auth服务解复，或仅在auth实例之间共享。

更新2

Cookie和Session似乎是老派技术人员。 cookie的跨域问题以及会话的共享问题是现代Web应用程序的可伸缩性和灵活性的主要障碍。幸运的是，通过将用户信息（可能是id足够）存储从服务器端移动到客户端，JSON Web Token成为当今多个轻量级服务的最佳单点登录解决方案，并且仅在必要时传输。 p>

Answer 1

  

但是CAS的工作流程有点复杂：重定向过多，CAS，Web应用程序和用户浏览器之间传输的票证太多。我无法弄清楚为什么人们将认证服务部署在所有网络应用程序的中心，而不是前面，如下图所示。

您正在考虑采用传统方式，这就是为什么建筑师过去曾提出过如下解决方案，例如将门户网站服务器用于Web应用程序，会话共享集群以及许多其他容易出错的容易出错的系统解决方案cpu，内存或带宽，在第一次真实测试之前你无法预测。

CAS解决方案在第一步中可能看起来很复杂，但您可以预测系统将生成多少登录，流量和同步数据，并与“旧解决方案”进行比较，您的系统对用户负载将提升线性而非指数。