单点登录（SSO）

什么是单点登录？

单点登录（Single Sign On，简称SSO）

背景：
以前的时候，一般我们就单系统，所有的功能都在同一个系统上。
后来，我们为了合理利用资源和降低耦合性，于是把单系统拆分成多个子系统。比如阿里系的淘宝和天猫，很明显地我们可以知道这是两个系统，但是你在使用的时候，登录了天猫，淘宝也会自动登录。

如图所示，图中有4个系统，分别是Application1、Application2、Application3、和SSO。Application1、Application2、Application3没有登录模块，而SSO只有登录模块，没有其他的业务模块，当Application1、Application2、Application3需要登录时，将跳到SSO系统，SSO系统完成登录，其他的应用系统也就随之登录了。这完全符合我们对单点登录（SSO）的定义。

简单来说，单点登录就是在多个系统中，用户只需一次登录，各个系统即可感知该用户已经登录。

单点登录的来源

1、早期web单系统应用

早期web单系统应用，用户的登录以及权限就显得十分简单，当浏览器向服务器发送登录请求时，验证通过之后，会将用户信息存入seesion中，然后服务器会生成一个sessionId放入cookie中，随后返回给浏览器。

验证登录的这个会话就是session,维护了用户状态,也就是所谓的HTTP有状态协议,我们经常可以在浏览器中看到JSESSIONID,这个就是用来维持这个关系的key。

2、分布式集群部署

由于网站的访问量越来也大，单机部署已经是巨大瓶颈，所以才有了后来的分布式集群部署。如果引入集群的概念,单应用可能重新部署在3台tomcat以上服务器,使用nginx来实现反向代理。

但是增加新的服务器之后，不同的服务器之间的sessionId是不一样的，可能在A服务器上已经登录成功了，能从服务器的session中获取用户信息，但是在B服务器上却查不到session信息，只好退出来继续登录，结果A服务器中的session因为超时失效，登录之后又被强制退出来要求重新登录。

所以不得不考虑多服务器之间的session数据一致的问题，这就是单点登录的最早来源。

单点登录技术实现

单点登录的本质就是在多个应用系统中共享登录状态，如果用户的登录状态是记录在 Session 中的，要实现共享登录状态，就要先共享 Session。

所以实现单点登录的关键在于，如何让 Session ID（或 Token）在多个域中共享。

1、同域下的单点登录

一个企业一般情况下只有一个域名，通过二级域名区分不同的系统。比如我们有个域名叫做：a.com，同时有两个业务系统分别为：app1.a.com和app2.a.com。我们要做单点登录（SSO），需要一个登录系统，叫做：sso.a.com。

实现方式：
在sso.a.com中登录了，其实是在sso.a.com的服务端的session中记录了登录状态，同时在浏览器端（Browser）的sso.a.com下写入了Cookie。那么我们怎么才能让app1.a.com和app2.a.com登录呢？这里有两个问题：

• Cookie是不能跨域的，我们Cookie的domain属性是sso.a.com，在给app1.a.com和app2.a.com发送请求是带不上的。
• sso、app1和app2是不同的应用，它们的session存在自己的应用内，是不共享的。

那么我们如何解决这两个问题呢？

• sso登录以后，可以将Cookie的 domian 域设置为顶域，即.a.com，这样所有子域的系统都可以访问到顶域的Cookie。在设置Cookie时，只能设置顶域和自己的域，不能设置其他的域。
• 把3个系统的Session共享，共享Session的解决方案有很多，例如：Spring-Session

2、跨域下的单点登录

如果是不同域呢？不同域之间Cookie是不共享的，怎么办？

这里我们就要说一说CAS流程了，这个流程是单点登录的标准流程。

具体流程如下：

1）用户访问app系统，app系统是需要登录的，但用户现在没有登录。
2）跳转到CAS server，即SSO登录系统，以后图中的CAS Server我们统一叫做SSO系统。 SSO系统也没有登录，弹出用户登录页。
3）用户填写用户名、密码，SSO系统进行认证后，将登录状态写入SSO的session，浏览器（Browser）中写入SSO域下的Cookie。
4）SSO系统登录完成后会生成一个ST（Service Ticket），然后跳转到app系统，同时将ST作为参数传递给app系统。
5）app系统拿到ST后，从后台向SSO发送请求，验证ST是否有效。
6）验证通过后，app系统将登录状态写入session并设置app域下的Cookie。

至此，跨域单点登录就完成了。以后我们再访问app系统时，app就是登录的。接下来，我们再看看访问app2系统时的流程。

1）用户访问app2系统，app2系统没有登录，跳转到SSO。
2）由于SSO已经登录了，不需要重新登录认证。
3）SSO生成ST，浏览器跳转到app2系统，并将ST作为参数传递给app2。
4）app2拿到ST，后台访问SSO，验证ST是否有效。
5）验证成功后，app2将登录状态写入session，并在app2域下写入Cookie。

这样，app2系统不需要走登录流程，就已经是登录了。SSO，app和app2在不同的域，它们之间的session不共享也是没问题的。

Cookie的属性详细介绍

• name 名称，一旦创建，名称便不可更改
• value 值，如果值为Unicode字符，需要为字符编码。如果值为二进制数据，则需要使用BASE64编码
• maxAge 失效的时间，单位秒。正数，则该Cookie在maxAge秒之后失效。如果为负数，该Cookie为临时Cookie，关闭浏览器即失效，浏览器也不会以任何形式保存该Cookie。如果为0，表示删除该Cookie。默认为-1。
• signed 所请求的cookie应该被签名
• expires cookie 过期的 Date
• path cookie 路径, 如果设置为“/sessionWeb/”，则只有contextPath为“/sessionWeb”的程序可以访问该Cookie。如果设置为“/”，则本域名下contextPath都可以访问该Cookie。注意最后一个字符必须为“/”。默认是’/’，
• domain cookie 域名。如果设置为“.google.com”，则所有以“google.com”结尾的域名都可以访问该Cookie。注意第一个字符必须为“.”。
• secure 是否仅被使用安全协议传输。安全协议。安全协议有HTTPS，SSL等，在网络上传输数据之前先将数据加密。默认为false。
• httpOnly 设置为true，则服务器可访问 cookie, 浏览器js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击。默认是 true
• overwrite 一个布尔值，表示是否覆盖以前设置的同名的 cookie (默认是 false). 如果是 true, 在同一个请求中设置相同名称的所有 Cookie（不管路径或域）是否在设置此Cookie 时从 Set-Cookie 消息头中过滤掉。
• comment 用处说明

更多开发细节说明

• 从客户端读取Cookie时，包括maxAge在内的其他属性都是不可读的，也不会被提交。浏览器提交Cookie时只会提交name与value属性。maxAge属性只被浏览器用来判断Cookie是否过期。

• Cookie的修改、删除

  Cookie并不提供修改、删除操作。如果要修改某个Cookie，只需要新建一个同名的Cookie，添加到response中覆盖原来的Cookie。

  注意：修改、删除Cookie时，新建的Cookie除value、maxAge之外的所有属性，例如name、path、domain等，都要与原Cookie完全一样。否则，浏览器将视为两个不同的Cookie不予覆盖，导致修改、删除失败。

Koa Cookie 的设置与获取

1、Koa 设置 Cookie

ctx.cookies.set(name, value, [options])

eg：以刷新’/'自动设置一个 Cookie 为例：./routes/index.js：

const router = require('koa-router')()

router.get('/', async (ctx, next) => {
  ctx.cookies.set('mycookie', Math.random())
  await ctx.render('index', {
    title: 'Hello Koa 2!'
  })
})

module.exports = router

eg：设置domain域名

2、Koa 获取 Cookie

ctx.cookies.get(name, [options])

eg：以刷新’/json’自动获取 Cookie 为例：./routes/index.js：

const router = require('koa-router')()

router.get('/json', async (ctx, next) => {
  ctx.body = {
    title: 'koa2 json',
    cookie: ctx.cookies.get('mycookie')
  }
})

module.exports = router

利用Node.js koa异步中间件——用户登录验证拦截器

// 用户信息认证中间件
const authMiddleware = async (ctx, next) => {
    const headers = ctx.headers
    const id = ctx.cookies.get('userId')
    const param = ctx.request.query

    // 是否已登录
    if (id !== undefined) {
        return next()
    }

    // 如果是同步请求，并且携带了ticket（是单点登录跳转过来）
    if (!headers['is-xhr'] && param.ticket) {
        await new Promise((resolve, reject) => {
            http.get(`http://www.sso.com/authTicket?ticket=${param.ticket}`, function (data) {
                let str = "";
                data.on("data", function (chunk) {
                    str += chunk; // 监听数据响应，拼接数据片段
                })
                data.on("end", function () {
                    const res = JSON.parse(str)
                    if (res.code === 200) {
                        ctx.cookies.set('userId', 1)
                        ctx.response.status = 302
                        ctx.response.set({
                            Location: `http://${ctx.request.header.host}`
                        })
                        resolve()
                    }
                })
            })
        })
    }

    ctx.response.body = {
        code: 302,
        data: {
            url: `http://www.sso.com?service=${ctx.request.header.host}${ctx.request.url}`
        }
    };
}
app.use(authMiddleware)