基于Session的单点登录(SSO)流程

一.背景

做项目过程中遇到了所做的系统需要和用户的门户还有app联通，并且支持单点登录的问题，本身自己的系统身份验证采用了基于token的验证方式。

二.方案比较

用户在登录的时候需要输入用户名和密码等服务器知道的信息来确认用户身份进行身份验证，常见的身份验证方式有两种：

• 基于session的验证
  Session 方案中，登录成功后，服务端将用户的身份信息存储在 Session 里，并且服务端会存储session，并将 Session ID 通过 Cookie 传递给客户端。后续的数据请求都会带上 Cookie，服务端根据 Cookie 中携带的 Session ID 来得辨别用户身份。在session方案的单点登录中，考虑如何同步 Session 和共享 Cookie，所有应用都从身份验证服务同步 Session。注销的时候只要删掉session中对应的记录就可以，这样的操作在客户端几乎是无感知的。
• 基于token的验证
  Token 方案中，服务端根据用户身份信息生成 Token，发放给客户端，客户端收到之后，将 Token 存放到 LocalStorage/SessionStorage中，之后请求数据时，将 Token 塞到请求头的Authentication字段里带到服务端，服务端接到请求后校验并解析 Token 得出用户身份，验证token的合法性，在有效期内都具有合法性。在token方案的单点登录中，考虑如何共享 Token，可以在进入平级应用的时候通过 URL 带上 Token。注销的时候需要删除token，并且发出去的 Token 在自动过期之前都是合法的，服务端仅通过验证 Token 无法区分合法 Token 与已经作废的Token。
  综上在单点登录的中两方案有以下差别：

基于Session	基于Token
服务端存储	客户端存储
同步session共享cookie	共享Token
可以服务器删除	不能单方面失效
客户端无感知	客户端需要进行存储删除传输操作

三.据需求方案落地

虽然我们本身的系统采取了基于token的身份验证方式，但是由于需求中的单点登录是需要和客户的门户网站以及企业移动APP共同使用，根据方案比较，采取基于Session的单点登录。

• 具体实施：本身系统在保持token身份验证不变的同时，接收cookie中的ltpaToken用做单点登录，同时在单点登录的时候需要验证自身token的合法性，当ltpaToken失效的时候，自身token也要失效，但是自身token失效的情况下，ltpaToken可不失效，只需重新登录自身系统即可。
• 方案实现
  获取和设置cookie

methods: {
      setCookie(cname, cvalue) {//设置cookie
        return new Promise((resolve,reject)=>{
          document.cookie = cname + "=" + cvalue + "; ";
          resolve({
            isData:true
          })
        })
      },
      getCookie: function (cname) {//获取cookie
        let name = cname + "=";
        let ca = document.cookie.split(';');
        for (let i = 0; i < ca.length; i++) {
          let c = ca[i];
          while (c.charAt(0) === '') c = c.substring(1);
          if (c.indexOf(name) !== -1) return c.substring(name.length, c.length);
        }
        return "";
      },
    },

根据获得的cookie判断跳转页面

mounted() {
      this.getCookie('LtpaToken');//获取单点登录的token
      if( this.getCookie('LtpaToken')===''){
        this.$router.pushPage({
          name: 'login'
        });
      }else{
        this.$router.pushPage({
          name: 'home'
        });
      } 
    }

四.总结
登录流程可依据自己的具体业务场景去实现，在这里我选择session的原因是在app中此系统相当于一个子应用的存在，所以只需要在token失效时重新登录即可，不会影响其他。