SSO后期补充理解

sso系统的提出：

为什么会产生sso系统呢？它的作用是什么？这跟普通的登录系统有什么区别？

我们先来说说session的实现原理：session跟cookie都是用户的会话跟踪技术，为什么登录成功后，信息写入session，下次就知道是该用户呢？原理是什么？

其实session的原理：当我们登录成功后，将用户的信息写入session，这时候会自动产生一个sessionId，而这个sessionId保存在客户端的cookie中，所以访问的时候先从cookie中读取sessionId，然后根据ｉｄ到服务端查询用户的session信息，这样就查找到了对应的用户。

那么sso系统的提出与session有什么渊源呢？

sso系统的提出其实就是因为session的共享问题引出的，我们知道session的信息是存储在服务端的，比如我们服务器使用的tomcat，那么我们的session就存储在服务端，可是现在的系统是分布式的系统，每个独立的系统都有一个独立的tomcat，那么每个session对应每个tomcat，但是这些工程是逻辑上统一，物理上独立。那么为了支撑起这整个系统，必须如果session共享，那么每个系统都有独立的session，用户登录一个session后，其他的工程都不知道，都需要再次登录。这就是session不共享导致的问题。

那么session存在这个问题，难道他们不会自己想办法解决吗？的确，他们提出了一个方案，就是将session在个tomcat中复制，也就是说10个tomcat需要复制10次，那么100呢，复制100次，再多呢，可见效率是多么的低？所以接着又提出了一个新的方案：sso

利用sso来实现这个session共享的问题。

那么，到底sso是如何来实现这个session共享呢？为什么分布式系统，为什么用户在这个工程登录了，其他工程也知道了这个消息，就出现了一次登录，其他系统免登录呢。

后面博客我们有写到sso的实现session共享的几种方案：

这里我们看下本次商城项目是如何实现的：

首先看下分布式系统的架构：

那么我们具体是如何实现这个sso系统呢，流程图如何，原理如何？接下来分享：

其实关键点就是这个token，通过cookie的共享域，共享了token，也就实现了session的共享。

那么其他系统如何来查询调用这个系统呢，这里使用了拦截器的作用，对用户进行拦截验证放行。

其实redis中存储的是token和用户信息，token存在则用户存在，token不存在，则用户不存在。

其实这就是sso系统的登录原理：

cookie顶级域共享，整个系统共享cookie，将token写入cookie，也就是实现了token共享

登录成功后的token写入redis，并设置过期时间。

然后其他系统访问的时候，根据cookie中的token调用sso服务即可进行验证用户是否登录。

这里客户端调用sso的时候还用的jsonp跨域：

这样就是实现了一次登录，各个系统免登录。