SSO后期补充理解
sso系统的提出:
为什么会产生sso系统呢?它的作用是什么?这跟普通的登录系统有什么区别?
我们先来说说session的实现原理:session跟cookie都是用户的会话跟踪技术,为什么登录成功后,信息写入session,下次就知道是该用户呢?原理是什么?
其实session的原理:当我们登录成功后,将用户的信息写入session,这时候会自动产生一个sessionId,而这个sessionId保存在客户端的cookie中,所以访问的时候先从cookie中读取sessionId,然后根据id到服务端查询用户的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跨域:
这样就是实现了一次登录,各个系统免登录。