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

Question

最近有一个项目要实现SSO(Single-Sign-On)用于基于 Beego Framework 的多个 Web 应用程序.最受欢迎的 SSO 项目是 CAS ，它需要在中心有一个 CAS Server，在每个 Web 应用程序之前需要一个 CAS Client。不幸的是，似乎没有任何用 Golang 编写的官方 CAS 客户端，除了 go-cas/cas。 , 和 adanteng/cas , 支持 Beego。

但 CAS 的工作流程有点复杂:重定向太多，在 CAS、Web 应用程序和用户浏览器之间传输的票证太多。我不明白为什么人们将身份验证服务部署在所有 Web 应用程序的中心，而不是前端，如下图所示:

在这个图中，所有的请求都强制先在Authenticate Service中进行处理，如果认证成功，则生成一个session ID，保存在cookies和Redis中，供其他微服务共享。根本没有任何重定向或票证，只有请求传输。

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

更新0

session 共享方式确实不像Nadh那样可扩展和模块化。辅导员。如何在授权服务和下游服务之间的请求 header 中传输用户信息，如姓名、电子邮件等，如黑培的创意作品 nginx-sso ？是否可以像 Sam Newman 在书中分享的那样使其作为 SSO 网关工作 Building Microservices ？

更新1

更详细的图如下，为了把我幼稚的想法说清楚一点，希望黑皮和Sam Newman不要误会。

与其处理这么多的重定向和握手，所有请求首先在认证服务中处理，认证服务将用户信息从 MySQL 写入作为 session 提供者的 Redis，以及传输到下游服务的 HTTP header ，如果请求认证成功。

通过这种方式，用户信息通过 HTTP header 传输，而不是上面的 shared-Redis 作为 Nadh警告，Redis 可以与 auth 服务分离，或者仅在 auth 实例之间共享。

更新2

Cookie 和 Session 似乎是老派技术。 cookie的跨域问题和session的共享问题是现代web应用的可扩展性和灵 active 的主要障碍。幸运的是，JSON Web Token 通过将用户信息(也许 id 就足够)存储从服务器端移动到客户端，并仅在必要时传输，成为当今多种轻量级服务的最佳单点登录解决方案。

Answer 1

But the workflow of CAS is a little bit complicated: too many redirections, too many tickets transmitted among the CAS, web apps, and the user browser. I can't figure out why people deploy the Authentication Services in the center of all the web apps, rather than the front, like the following diagram.

你在用老式的方式思考，这就是为什么架构师在过去想出了解决方案，比如将 portlet 服务器用于 web 应用程序、 session 共享集群，以及许多其他容易出错的系统解决方案，这些解决方案吞噬了你cpu、内存或带宽的方式在第一次真实生活测试之前是您永远无法预测的。

CAS 解决方案乍一看可能看起来很复杂，但您可以预测您的系统将产生多少登录、流量和同步数据，并且与“旧解决方案”相比，您的系统对用户的负载将呈线性增长，不是指数级的。