Recently I have a project to implement SSO(Single-Sign-On) for multiple web applications based on Beego Framework. The most popular SSO project is CAS, which needs a CAS Server in the center, and a CAS Client before each web application. Unfortunately, it seems that there's not any offical CAS clients written in Golang, except go-cas/cas, and adanteng/cas, which supports Beego.
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:
In this diagram, all the requests are forced to be processed in the Authenticate Service first, if authenticated successfully, then generate a session ID, saved in the cookies and Redis which is shared by other microservices. There's not any redirections or tickets at all, only requests transmittion.
So is this diagram possible, or some critical problems I ignored?
Update 0
The session-sharing way is indeed not scalable and modular as Nadh counsels. How about transmitting user information, like name, email, etc., in the headers of requests between the auth service and downstream services, like the creative work of Heipei at nginx-sso? Is it possible to make it work as an SSO Gateway as Sam Newman sharing in the book Building Microservices?
Update 1
A more detailed diagram is shown as follows, in order to describe my childish idea a little bit clearly, hoping that there is not much misunderstanding from Heipei and Sam Newman.
Rather than handling so many redirections and handshakes, all the requests are processed in the authentication service firstly, which writes user info from MySQL, into the Redis as the session provider, and the HTTP header to transmit to the downstream services, if the request is authenticated successfully.
In this way, the user info is transmitted via HTTP header instead of the above shared-Redis as Nadh warning, and Redis can be depolyed with the auth service, or shared among auth instances only.
Update 2
It seems that Cookie and Session are old-school techs. The cross-domain problem of cookie, and the sharing problem of session are the primary barrier to the scalability and flexibility of the modern web applications. Fortunately, JSON Web Token comes to be the best Single Sign-on solution for multiple lightweight services nowadays, by moving the user info(maybe id is enough) storage from the server side to the client side, and transmitted only if necessary.
