最近我有一个项目要为基于Beego 框架的多个 Web 应用程序实现SSO（单点登录）。最流行的 SSO 项目是CAS，它在中心需要一个 CAS 服务器，在每个 Web 应用程序之前需要一个 CAS 客户端。不幸的是，除了支持 Beego的 go-cas/cas和adanteng/cas之外，似乎没有任何用 Golang 编写的官方 CAS 客户端。
但是 CAS 的工作流程有点复杂：重定向太多，在 CAS、Web 应用程序和用户浏览器之间传输的票证太多。我不明白为什么人们将身份验证服务部署在所有 Web 应用程序的中心，而不是前端，如下图所示：
在这个图中，所有的请求都被强制先在 Authenticate Service 中处理，如果认证成功，则生成一个 session ID，保存在 cookie 和 Redis 中，供其他微服务共享。根本没有任何重定向或票证，只有请求传输。
那么这个图表是否可能，或者我忽略了一些关键问题？
更新 0
会话共享方式确实不像Nadh建议的那样可扩展和模块化。在 auth 服务和下游服务之间的请求头中传输用户信息，如姓名、电子邮件等，如何，如 Heipei 在nginx-sso的创造性工作？是否可以像 Sam Newman 在Building Microservices一书中分享的那样，让它作为 SSO 网关工作？
更新 1
更详细的图如下，为了把我幼稚的想法描述的更清楚一点，希望黑培和山姆纽曼不要有太多的误会。
与其处理那么多重定向和握手，不如先在认证服务中处理所有请求，认证服务将来自 MySQL 的用户信息写入 Redis 作为会话提供者，如果请求是，则将 HTTP 标头传输给下游服务认证成功。
这样，用户信息通过HTTP头而不是上面的共享Redis作为Nadh警告传输，并且Redis可以与auth服务分离，或者仅在auth实例之间共享。
更新 2
似乎 Cookie 和 Session 是老派技术。cookie 的跨域问题和 session 的共享问题是现代 Web 应用程序扩展性和灵活性的主要障碍。幸运的是，JSON Web Token 成为当今多个轻量级服务的最佳单点登录解决方案，通过将用户信息（也许 id 就足够了）存储从服务器端移动到客户端，并仅在必要时传输。