前言

Node公共服务之通用SSO能力设计。

将该层能力集合到loginVerify中间件，以及本身不需要鉴权的/ssoCheckCode回调api，/logout退出登陆api

SSO设计

1. 鉴权请求

浏览器访问已接入的前端site

如果不需要鉴权【config00】，直接透传 next() ；
如果需要鉴权：
- 验证票据 checkTicket 【config01】
  - ticket有效，直接next()
  - ticket 无效，返回错误

checkTicket具体实例

2. 鉴权未通过 - 返回错误

验证票据 checkTicket 【config01】【config06】

ticket 有效，直接next()，重设redis缓存（_sso_ticket）
ticket 无效，返回错误
- api错误：status401 或者200+前端跳转
- page错误： status302 或者200+前端跳转

3. 跳转至的登陆界面

302 携带appid + jumpto 直接跳转登陆界面【config01】【config03】
401 重新鉴权

为什么只有page会302？ 从前端页面的设计角度考虑，一定是先进资源，再进api。

page hash怎么处理？毕竟携带不到服务中。 跟page约定，将hash转义放到header或者query中，发送给服务。服务redirect 前会把hash解出来，直接拼上。

4. 完成登陆操作

SSO系统完成登陆验证后，会执行callback

5. 携带token302跳转至登记的回调地址

callback会直接获取当前appid登记的ssoCheckCode地址，拼接参数code（token）以及jumpto进行请求，请求到node公共服务

6. 请求回调地址api传递token

ssoCheckCode接收到code和jumpto。
- 向SSO服务验证code有效【config05】【config02】【config01】【config07】
  - 有效：
    - header中直接set-cookie（token、用户信息等）返回前端，302重定向
    - redis缓存登陆信息，redisKey为用户维度，_sso_ticket为数组，支持多组票据
  - 无效：
    - 302重定向登陆界面【config03】

7. setcookie并302跳转至前端页面（jumpto）

将有效票据写到cookie指定字段中
重新定向，鉴权请求

8. 鉴权请求

上述302发起请求

9. 鉴权通过，返回数据

验证 checkTicket通过，执行next()，返回数据【config01】【config06】

通用SSO配置化设计

关键的几项配置

/**
 * @description SSO配置模版
 */
export interface SSOConfig {
  // 【config00】sso开关
  ssoFlag?: boolean  
  // 【config01】sso分配的应用id
  appId?: string
  // 【config02】应用key值
  appKey?: string
  // 【config03】统一登陆地址
  loginUrl?: string
  // 【config04】统一退出地址
  logoutUrl?: string
  // 【config05】校验code接口
  checkCode?: string
  // 【config06】校验ticket接口
  checkTicket?: string
  // 【config07】获取用信息户接口
  getUserUrl?: string
}

其他鉴权形式

Auth：
给服务统一加公参

单点登录

misAuth为公共认证中心

当第一次登陆成功时，misAuth会先调用callback，此时往认证中心域名写cookie

的同时，再携带code，302去调用服务登记的ssoCheckCode接口。

当访问其他共同SSO的系统的时候，由于当前域名没有ticket，所以服务会先验证ticket失败，302到登录界面

302的URL访问会携带之前写入的cookie访问misAuth服务，

- cookie无效，misAuth登录界面。
- cookie有效，直接302到ssoCheckCode验证code并进入 当前系统

【EasyServer】Node公共服务设计—SSO

前言