本文转载自微信公众号「mikechen的互联网架构」，作者mikechen。转载本文请联系mikechen的互联网架构公众号。
为什么需要单点登录
单点登录SSO(Single Sign On)说得简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。
单点登录在大型网站里使用得非常频繁，例如，阿里旗下有淘宝、天猫等网站，还有背后的成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会为这种重复认证授权的逻辑搞疯掉。
所以，单点登录要解决的就是，用户只需要登录一次就可以访问所有相互信任的应用系统。
单点登录的来源
1.早期web单系统应用
早期我们开发web应用都是所有的包放在一起打成一个war包放入tomcat容器来运行的,所有的功能,所有的业务,后台管理,门户界面,都是由这一个war来支持的,这样的单应用,也称之为巨石应用,因为十分不好扩展和拆分。
在巨石应用下，用户的登录以及权限就显得十分简单，当浏览器向服务器发送登录请求时，验证通过之后，会将用户信息存入seesion中，然后服务器会生成一个sessionId放入cookie中，随后返回给浏览器。
大致可以用下图来表示:
验证登录的这个会话就是session,维护了用户状态,也就是所谓的HTTP有状态协议,我们经常可以在浏览器中看到JSESSIONID,这个就是用来维持这个关系的key。
2.分布式集群部署
由于网站的访问量越来也大，单机部署已经是巨大瓶颈，所以才有了后来的分布式集群部署。
例如：如果引入集群的概念,单应用可能重新部署在3台tomcat以上服务器,使用nginx来实现反向代理。
但是增加新的服务器之后，不同的服务器之间的sessionId是不一样的，可能在A服务器上已经登录成功了，能从服务器的session中获取用户信息，但是在B服务器上却查不到session信息，只好退出来继续登录，结果A服务器中的session因为超时失效，登录之后又被强制退出来要求重新登录。
所以不得不考虑多服务器之间的session数据一致的问题，这就是单点登录的最早来源。
单点登录的实现方式
单点登录的本质就是在多个应用系统中共享登录状态，如果用户的登录状态是记录在 Session 中的，要实现共享登录状态，就要先共享 Session。
所以实现单点登录的关键在于，如何让 Session ID(或 Token)在多个域中共享。
1.同域下的单点登录
一个企业一般情况下只有一个域名，通过二级域名区分不同的系统。
比如我有个域名：mikechen.cc，同时有两个业务系统分别为：
- blog.mikechen.cc
- video.mikechen.cc
我们要做单点登录(SSO)，需要一个登录系统，叫做：sso.mikechen.cc。
我们只要在sso.mikechen.cc登录，blog.mikechen.cc和video.mikechen.cc也登录了。
实现方式：其实这里就是利用了 二级域名 写 一级域名的 Cookie 。
sso.mikechen.cc登录以后，可以将Cookie的域设置为顶域，即.mikechen.cc，这样所有子域blog.mikechen.cc和video.mikechen.cc的系统都可以访问到顶域的Cookie。
此种实现方式比较简单，但不支持跨主域名,局限性限于一级域名是一样的。
2.不同域下的单点登录
同域下的单点登录是巧用了Cookie顶域的特性,如果是不同域呢，比如：下面三个是不同域的
- mikechen1.cc
- mikechen2.cc
- mikechen3.cc
实现方式：我们可以部署一个SSO认证中心,认证中心就是一个专门负责处理登录请求。
所有的请求(登录、退出、获取用户信息、当前用户状态)都请求sso 系统，sso 系统维护用户信息。
此种实现方式相对复杂，支持跨域，扩展性好。
基于SSO认证中心的开源项目代表:CAS，其中 CAS是Central Authentication Service，即中央认证服务，下图是CAS的基本过程：
以上就是基于单点登录的介绍!
