sso

以AppA接入sso为例说明接入过程和服务器的交互逻辑。

AppA对应的域名为appa.sankuai.com

SSO对应的域名为sso.sankuai.com

涉及的角色有三个，分别是客户端（即图中的谷歌浏览器），AppA服务器，SSO服务器。

图中绿色线对应request，红色线对应response，交互过程分4个阶段，分别用对应① ② ③ ④

 

 

1. 交互过程

1.1. 阶段① ，客户端访问appa.sankuai.com

客户端发出GET请求，GET appa.sankuai.com HTTP/1.1

AppA服务器收到后检查①中request中是否携带了ssoid这样的cookie：

如果有则调用http://api.sso-in.sankuai.com/api/session/ssoid获取user信息(需要加ba认证)，如果user有效（返回是json,user各个字段值不为null判定为有效，否则无效）则认为已经登录，则①中的response为appa.sankuai.com对应的页面；

如果没有携带ssoid或者虽然携带了ssoid但是拿到的user无效，则①中的response为302，location为https://sso.sankuai.com/auth?service=http://appa.sankuai.com。注意这里是https://sso,service=xxx,xxx部分要写http://,即http://sso.sankuai.com/auth?service=appa.sankuai.com是错误的，第一不是https，第二service部分没有写http://

现在假设请求中没有ssoid或者包含了无效的ssoid，即需要登录,这样进入阶段②

1.2. 阶段②，客户端请求sso的登录页面

上一个阶段已经假设AppA服务器给客户端了一个302响应，location为https://sso.sankuai.com/auth?service=http://appa.sankuai.com，现在客户端发起GET请求，GET sso.sankuai.com/auth?service=https://appa.sankuai.com HTTP/1.1，SSO服务器收到之后保存service这个参数，同时给客户端返回sso登录界面，这个过程比较简单，就是拿到sso登陆页面。

 

1.3. 阶段③ ，客户端POST mis账号和密码给sso

用户点击登陆之后账号密码就发给了SSO服务器，对应阶段③ 的request，SSO服务器收到之后对账号密码做验证，登陆成功则返回给客户端一个隐藏表单，即阶段③的response是一个自动提交的隐藏表单，这个隐藏表单会自动提交到appa.sankuai.com，表单中包含了sid,time,sign三个参数

下面是我某次测试对应的隐藏表单，当时是localhost:8999这个应用接入了sso,所以最终提交的目标地址就是图中所示的。

 

1.4. 阶段④，客户端自动提交了一个表单到AppA服务器

上一个阶段客户端收到了一个自动提交的隐藏表单,表单包含sid,time,sign三个参数，表单自动提交到AppA服务器，提交过程对应阶段④的request，AppA服务器收到这个POST之后需要做如下判断：md5(SID + time + salt).toHex()==sign?登录成功:登录失败，注意：java语言接入sso引入我们的sdk之后这些逻辑都封装好了，里面有salt这个值，非java系统接入的时候需要说明，我们会提供salt

如果登录失败，AppA服务器需要给客户端302，location=https://sso.sankuai.com/auth?service=http://appa.sankuai.com，让客户端重新去sso登录。

如果登录成功，AppA服务器应该给阶段④的response中添加key=ssoid，value=sid的cookie,然后返回appa.sankuai.com页面给客户端。这样客户端通过登录之后看到了appa的页面，同时客户端的appa域下也有了ssoid这样的cookie.以后客户端访问appa应用其他页面时都会带上这个cookie,AppA服务器则在每个请求到来的时候做阶段① 的检查

以上就是接入sso的过程，sso/upm的sdk就是对这个过程用java语言实现了一遍，并使其能方便的嵌入到spring+maven构建的web项目中。

非java语言需要在理解上面的交互逻辑的基础上自己实现登录认证过程。