互联网用户登录模式变迁史(一)

单体架构

在单体服务的时候，登录和注册是很常见的一个功能。

大家都知道，HTTP 是无状态的协议，那么服务器无法确认用户的信息，也就是说服务器不知道客户端谁是谁，这个问题难不倒聪明的人类，W3C 就提出了：给每一个用户都发一个通行证，无论谁访问的时候都需要携带通行证，这样服务器就可以从通行证上确认用户的信息。通行证就是Cookie。

只有客户端带着通行证Cookie，服务器也是一脸蒙啊，于是服务器就使用Session,服务器向用户浏览器发送了一个 SESSION_ID 的 Cookie，它的值是 Session 的 id 值。其实 Session 是依据 Cookie 来识别是否是同一个用户。

也就是说，服务器和每个客户端会建立一个 session,然后返回这个 session 的 id,当做 Cookie,当用户使用浏览器再次请求服务器的时候，服务器会检查这个 cookie，也就是会去服务器查找是否存在这个 session 的 Id。Session 本身也需要配合 cookie 来使用的。

所以，一般我们单体服务系统实现登录会这样做：

登录：将用户信息保存在 Session 对象中
如果在 Session 对象中能查到，说明已经登录
如果在 Session 对象中查不到，说明没登录（或者已经退出了登录）
注销：从 Session 中删除用户的信息
记住我 关闭掉浏览器后，重新打开浏览器还能保持登录状态

001

从上图可以看到，早期的时候 2 个系统，session 是不共享的，如何解决这个问题？

解决方案：

后端集群 Session 全局复制。集群内每个后端服务的 session 都完全同步。（集群性能不高，不建议）
根据 Ip 进行 Hash 映射，也就是说同一个 ip 会一直映射到一个服务器上。（如果服务器宕机，丢失 session 数据，不建议）
把 session 放到 redis 中。

单点登录 SSO

SSO=Single Sign On，在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。

同域名下的单点登录

002

sso 登录以后，可以将 Cookie 的域设置为顶域，即:go-edu.cn。
把 seesion 放到一个共享的地方。

不同域名下的单点登录

下面是标准的单点登录的标准流程。

第一个应用完整流程

2061660533865_.pic

（图 1）

用户想要访问 app。
Get 请求 https://app.example.com/
App 发现用户没有登录，需要登录，使用 302 状态码重定向到 CAS Server，并把 app.example.com 当成参数。
Get 请求https://acs.example.com/cas/login?service=https://app.example.com到CAS Server.
CAS Server 返回一个登录的表单。
填写用户名和密码，提交表单。
Post https://cas.example.com/cas/login?service=https://app.example.com/,携带用户名和密码。
CAS Server 验证用户名和密码。
验证用户通过，设置 Cookie CASTGC=TGT-2345678,并跳转https://app.example.com/?ticket=ST-123456
Get 请求 https://app.example.com/?ticket=ST-123456
app.example.com 接收到请求后，发送给 CAS Server https://cas.example.com/serviceValidate?service=http://app.example.com/&ticket=ST-12345678
CAS Server 验证通过，返回 200
app.example.com 设置 Cookie JSESSIONID=ABC1234567,重定向到 app.example.
请求 app.example.com 携带 Cookie JSESSIONID=ABC1234567
验证 Session Cookie
返回请求资源
显示资源