SSO单点登录浅析

SSO(Single Sign On)单点登录

一、先讲一讲 Token 和 Cookies 的区别

1
  • 基于Cookies的认证程序

    1. 用户带着账号密码等信息登录

    2. 服务器验证登录信息正确后,创建一个会话,设置为登录状态, 返回会话的ID, 同时自己把这个会话储存在自己的数据库中。

      HttpSession session = request.getSession();
      session.setAttribute("isLogin",true);
      
    3. 浏览器设置一个cookie,以key/value的形式储存下这个会话ID 如图中 Cookie: session=.....

    4. 后续请求中,服务器根据这个会话ID,在自己数据库里面查询,看该会话是否为登录状态

      HttpSession session = request.getSession();
      session.setAttribute("isLogin",true);
      
    5. 用户退出网站时,浏览器和服务器同时销毁这个会话

二、多系统的复杂性

上面的那个cookie机制应该很好理解,早期服务器确实也是用那种机制,像Tomcat. 但是web系统早已经从久远的单系统发展成如今多系统组成的应用群。

2

面对这么多的系统,用户总不可能一个个登录,再一个个注销吧。实际上复杂性应该由系统内部承担,对于用户而言,系统看上去就是一个整体,和单系统一样,登录/注销只需要一次就行.

3

单系统登录解决方案的核心是cookie,cookie携带会话id在浏览器与服务器之间维护会话状态。但cookie是有限制的,这个限制就是cookie的域(通常对应网站的域名),浏览器发送http请求时会自动携带与该域匹配的cookie,而不是所有cookie

4

域,你就简单理解成后面用 . 分割的东西吧。(一个域名是由几部分,有可能只是一部分,也许是两部分,三部分...)组成的简单结构,它被点分隔,并需要从右到左阅读。)比如. com,.org就是顶级域名,然后顶级域名前面的就是二级域名。比如 mozilla.org, 然后后面还可以接developer.mozilla.org

需要特别注意的是:images.google.com与www.google.com同属于google,但是他们的域名不一样,二者同样也不能操作彼此的Cookie,浏览器在访问的时候,会根据访问地址自动携带相关域名的cookie过去。

所以你发现如果跨域访问的话是不是很麻烦,又要登录一次。例如像阿里巴巴这样的网站,在网站的背后是成百上千的子系统,用户一次操作或交易可能涉及到几十个子系统的协作,如果每个子系统都需要用户认证,不仅用户会疯掉,各子系统也会为这种重复认证授权的逻辑搞疯掉。

既然这样,为什么不将web应用群中所有子系统的域名统一在一个顶级域名下,如“.baidu.com”,然后将它们的cookie域设置为“baidu.com”,这种做法理论上是可以的,甚至早期很多多系统登录就采用这种同域名共享cookie的方式。

然而,可行并不代表好,共享cookie的方式存在众多局限。首先,应用群域名得统一;其次,应用群各系统使用的技术(至少是web服务器)要相同,不然cookie的key值(tomcat为JSESSIONID)不同,无法维持会话,共享cookie的方式是无法实现跨语言技术平台登录的,比如java、php、.net系统之间;第三,cookie本身不安全。

那这时候你会不会想,不如引入第三方服务器,帮我们管理登录认证,就像签发SSL证书那样。嗯,确实,这就是后来的发展出的单点登录。

三、单点登录

什么是单点登录?单点登录全称Single Sign On(以下简称SSO),是指在多系统应用群中登录一个系统,便可在其他所有系统中得到授权而无需再次登录,包括单点登录与单点注销两部分。

例如访问在网易账号中心(http://reg.163.com/ )登录之后 访问以下站点都是登录状态

  • 网易直播 http://v.163.com

  • 网易博客 http://blog.163.com

  • 网易花田 http://love.163.com

  • 网易考拉 https://www.kaola.com

  • 网易Lofter http://www.lofter.com

    注意到他们跨域了对不对,二级域名不一样

业务逻辑一般是这个样子

5
  • 数据库是用于储存用户账户信息

  • Redis储存登录信息,通常是将UserId,UserName缓存起来

现在,假设你在主域名那里登录,具体情况就是这样的。

6

这里注意下域名是 test.com,Cookie 就认准了是这个域名. (domian=test.com) 但是跨域访问的时候Cookie不能跨域,这时候SSO中心签发的 AuthToken是全局通用的,这时候也叫创建的全局会话。下面会讲区别

后期你要获取受保护的资源,登录信息的验证就是这样的

7

然后重点来了,假设你在主域名站点那里刚登录过,然后你跨域访问 testX.com 这个域名

这里就开始发挥SSO的作用了

8
  • 为什么一开始不能从Cookie中获取AuthToken? 因为此Cookie非彼Cookie 这时候的Cookie的domian=testX.com. 而之前我们在主域名站点登录保存的Cookie的domian=test.com.

  • 后面几部发现浏览器把 AuthToken(全局有效的令牌)放在了 domian=testX.com的Cookie中,这时候就创建了局部会话

然后是单点登出,我们介绍一种复杂点的情况,就是在子系统中跨域登出

9

你会发现,你在子系统中登出,会先把你重定向到主域名的站点那里,然后把Cookie里面的AuthToken弄过期,同时清除Redis里面登录信息的缓存。

那个全局通用的令牌过期后,其他子系统对应的Cookie中储存的AuthToken就也没用了,因为本来就是同一个嘛。最后一步就是给你重定向到最初的登录页面去。

所以,可以得出结论

  • 局部会话存在,全局会话一定存在

  • 全局会话存在,局部会话不一定存在

  • 全局会话销毁,局部会话必须销毁

  • 在一个子系统中注销,所有子系统的会话都会被注销

以上是一般的SSO原理。

然后特别要提一下的是耶鲁大学研发的CAS框架:CAS(Central Authentication Service)是基于Kerberos票据方式实现SSO单点登录的框架。 和我上面讲的原理略有些不同,比较麻烦

具体想了解实现细节的请参考

https://blog.csdn.net/readiay/article/details/52856510

因为我之前在云平台爬学生照片的时候就碰到这种登录机制。 当时用最简单的模拟表单登录一直拿不到Cookie。 像这样

10

一堆的302重定向

[
11

]

看那个网址里面的cas,就是CAS实现的单点登录

12

这是其中一个重定向后获取的参数。 Cookies是键值对的储存形式,就像go语言里面的map。根据CAS机制,重定向后得到TGC啥的放在Cookies里面,所以Cookies里面好几个键值对。

不过还好GO语言有一个叫做CookieJar的包,可以模拟浏览器行为,自动重定向并且记下每一个网站给个Cookies. 不过我没试过,后来老板给了我教程,我爬珍爱网去了,,,

最后图的出处和相关内容引用有

  • Cookies vs Tokens 权威指导:https://dzone.com/articles/cookies-vs-tokens-the-definitive-guide 是一篇英文文章,讲Cookies和Token的区别优劣,讲的很好很详细,里面的单词也不难

  • https://cloud.tencent.com/developer/article/1166255 两篇SSO原理相关文章

  • https://cloud.tencent.com/developer/article/1333892

侵删

你可能感兴趣的:(SSO单点登录浅析)