Before SSO: Session, Cookie, Token

Before SSO: Session, Cookie, Token

在单点登录这种设计出现之前，人们如何保证打开浏览器登录网站（如博客园）一次之后，新建标签页再次打开网站而不用登录了呢？

Cookie-Based Authentication

HTTP是无状态的网络协议，在服务端我们开辟一块叫做 Session 的内存/ 磁盘/ 数据库来记录这次连接的一些信息，这就保持了请求的状态。

a 用户登录博客园，在服务器端我们为 a 用户开辟一块叫做 a_session 内存来记录 a 用户的一些信息，同时把这个 a_session 的 id 通过 Cookie 返回给浏览器，浏览器会记录下这个 Cookie 放入自己的一个空间里，这个空间里存放了各类网站的 cookies 。

当 a 用户再次请求博客园网站的地址时，浏览器在 cookie 所属的空间（域）里包含了该网址（域），则这次 HTTP 请求 会带上 cookie 信息 a_session_id。服务端的过滤器 Filter 拿 session_id 和这个 id 是刚刚用户登录产生并且有效的，则直接返回资源给浏览器，而不是再次进行登录。

优点：

• 设置 http-only 属性，js 脚本将无法获取，可以避免 XSS 攻击。
• 客户端不用编写额外代码。

缺点：

• 开销问题，因为通过 session 来维持连接的状态，每个用户都要新建一个 session

• 扩展性不好，session 不能共享。

• 不能跨域（可以通过反向代理实现）。

  • 易受 XSRF/CSRF 攻击。

• 每个请求都会带有 cookie ，即使访问不需要登录的资源（固定，通用）也必须验证。

Token-Based Authentication

Token 和 sessionId 类似，由服务端生成但是服务端并不保存，交由 Redis 或 MongoDB ，并返回给浏览器并保存在某个位置（localStorage, sessionStorage, cookie）。当下次请求时，客户端代码把 token 加入 http 请求，服务端去验证本次请求中的 token 的有效性。

优点：

• 可以选择自己需要授权的请求去完成身份验证。
• 对 XSRF 免疫。
• 可以跨域。

缺点：

• 必须找个自己在浏览器找个地方保存。

  • localStorage（浏览器关闭后依然存在）
  • sessionStorage（浏览器关闭后丢弃）
  • cookie（每次请求都发，如果不是 http-only 易受 XSS 攻击）。

• 更易受 XSS 攻击（通过脚本获取 token ，被标记未 http-only 的 cookie 依然能发出授权请求。