Single Sign On 一处登陆、处处可用
0、前置概念:
1)、单点登录业务介绍
早期单一服务器,用户认证。
缺点:单点性能压力,无法扩展 分布式,
SSO(single sign on)模式
解决 :
用户身份信息独立管理,更好的分布式管理。
可以自己扩展安全策略
跨域不是问题
缺点:
认证服务器访问压力较大。
2)、几个基本概念
2.1 什么是跨域 Web SSO
域名通过“.”号切分后,从右往左看,不包含“.”的是顶级域名,包含一个“.”的是一级域名, 包含两个“.”的是二级域名,以此类推。
例如对网址 http://www.cnblogs.com/baibaomen,域名部分是 www.cnblogs.com。 用“.”拆分后从右往左看:
cookie.setDomain(“.cnblogs.com”);//最多设置到本域的一级域名这里
cookie.setDomain(“.baidu.com”);//最多设置到本域的一级域名这里
”com”不包含“.”,是顶级域名; “cnblogs.com”包含一个“.”,是一级域名;
www.cnblogs.com 包含两个“.”,是二级域名。
blog.cnblogs.com
news.cnblogs.com
跨域 Web SSO 指的是针对 Web 站点,各级域名不同都能处理的单点登录方案。
2.2 浏览器读写 cookie 的安全性限制
浏览器读写 cookie 的安全性限制:一级或顶级域名不同的网站, 无法读到彼此写的 cookie。
所以 baidu.com 无法读到 cnblogs.com 写的 cookie。 一级域名相同,只是二级或更高级域名不同的站点,可以通过设置 domain 参数共享 cookie
读写。这种场景可以选择不跨域的 SSO 方案。 域名相同,只是 https 和 http 协议不同的 URL,默认 cookie 可以共享。知道这一点对处 理 SSO 服务中心要登出
2.3 http 协议是无状态协议
浏览器访问服务器时,要让服务器知道 你是谁,只有两种方式:
方式一:把“你是谁”写入 cookie。它会随每次 HTTP 请求带到服务端;
方式二:在 URL、表单数据中带上你的用户信息(也可能在 HTTP 头部)。这种方式依赖 于从特定的网页入口进入,因为只有走特定的入口,才有机会拼装出相应的信息,提交到服 务端。
大部分 SSO 需求都希望不依赖特定的网页入口(集成门户除外),所以后一种方式有局限 性。适应性强的方式是第一种,即在浏览器通过 cookie 保存用户信息相关凭据,随每次请 求传递到服务端。我们采用的方案是第一种。
1、Cookie 接入方式
2、Token 接入方式
类似社交登陆
3、有状态登录
为了保证客户端 cookie 的安全性,服务端需要记录每次会话的客户端信息,从而识别客户 端身份,根据用户身份进行请求的处理,典型的设计如 tomcat 中的 session。
例如登录:用户登录后,我们把登录者的信息保存在服务端session中,并且给用户一个cookie值,记录对应的 session。然后下次请求,用户携带 cookie 值来,我们就能识别到对应 session, 从而找到用户的信息。
缺点是什么?
- 服务端保存大量数据,增加服务端压力
- 服务端保存用户状态,无法进行水平扩展
- 客户端请求依赖服务端,多次请求必须访问同一台服务器
即使使用 redis 保存用户的信息,也会损耗服务器资源。
4、无状态登录
微服务集群中的每个服务,对外提供的都是 Rest 风格的接口。而 Rest 风格的一个最重要的 规范就是:服务的无状态性,即:
- 服务端不保存任何客户端请求者信息
- 客户端的每次请求必须具备自描述信息,通过这些信息识别客户端身份 带来的好处是什么呢?
- 客户端请求不依赖服务端的信息,任何多次请求不需要必须访问到同一台服务
- 服务端的集群和状态对客户端透明
- 服务端可以任意的迁移和伸缩
- 减小服务端存储压力
5、集成社交登陆
1)、用户点击不同的社交登陆按钮,先来我们自己的服务器
https://passport.csdn.net/v1/register/authorization?authType=qq /sina
2)、命令浏览器重定向到用户授权页
用户确认授权
https://graph.qq.com/oauth2.0/authorize
3)、qq 返回的响应,会命令用户重定向到指定位置
4)、服务器的这个位置就可以收到我们的 code 码
收到 code 码,服务器自己用 code 交换 access_token 令牌,并获取到用户的信息。给浏览器 只给用户的信息即可;
access_token=UUID
浏览器访问带 UUID_token 而不是 access_token;