单点登录在当今的系统架构中广泛存在，他贯穿多个子系统的认证体系，实现在一个入口多处使用，但在构建单点登录时也出现了一些小问题，在不同的APP应用环境中存在不同的问题
和大家分享我遇到的应用环境和其中经历的各个阶段。 如果有不足的地方，希望大家不要吝惜地指导我。
一、会话共享
共享会话可以说是实现单点登录的最直接、最简单的方法。 将用户凭据存储在Session中(即，将存储在Session中的值作为用户证书)在单个站点中使用通常很容易实现，但在用户身份验证、用户信息管理和业务APP应用程序分离的情况下会出现单点登录问题如果APP应用程序体系简单，子系统较少，则可以通过Session共享的方式进行处理。
该体系结构使用了基于Redis的Session共享方案。 将Session保存到Redis中，并将整个系统的全局cookie域设置为顶级域名，以便可以在子系统之间共享SessionID。 分布式会话共享解决方案，这是推荐给大家的。
此方案存在严重的可扩展性问题。 首先，ASP.NET的Session存储必须是SessionStateItemCollection对象，并且存储结构必须经过序列化和加密。
另外，当用户访问APP应用程序时，他做的第一件事是检索存储容器中的所有内容，并将其反序列化为SessionStateItemCollection对象。
这决定了他有以下限制。
1.Session涉及的类型必须在子系统中共同拥有，程序集、类型都需要一致性。 因此，会话的使用受到很多限制；
2 .完全无法应对跨越顶级域的情况
二、基于OpenId的单点登录
该单点登录将用户的标识信息简化为OpenId并存储在客户端中，当用户登录到某个子系统时，将OpenId发送到服务端，服务端根据OpenId构建用户凭据，将C/S和b 过程如下。
从上图可以看出，该单点登录依赖于OpenId的发布，其验证的基础在于OpenId的存储和发送。
1 .用户首次登录时，将用户名密码发送到认证服务；
2 .认证服务将用户OpenId返回给客户机；
3 .客户端进行存储
4 .访问子系统时，向子系统发送OpenId；
5 .子系统向认证服务转发OpenId；
6 .认证服务将用户认证信息返回子系统；
7 .子系统构建用户凭据后，将批准的内容返回客户端。
该单点登录认证机制的主要问题是，他基于C/S架构将用户的OpenId存储在客户机上，并在子系统之间发送OpenId，但在B/S模式下这很困难。 为了处理这个问题，引出以下方式。 该方式解决了B/S模式下OpenId的存储、传输问题。
三.基于Cookie的OpenId存储方案
我们知道，Cookie的作用是充当在服务器端和浏览器端交换信息的信息载体，Cookie通常按域名划分。 例如，a.xxx.com和b.xxx.com上的Cookie不能相互访问，但子域名称可以访问顶级域名Cookie。 也就是说，a.xxx.com和b.xxx.com可以访问xxx.com下的Cookie，因此可以将顶级域的Cookie用作OpenId的载体。
验证步骤与前面的第二种方法非常相似。
1、登录提供认证服务的网站
2、将OpenId写入顶级域名Cookie；
3、访问子系统(Cookie中包含OpenId ) () ) ) ) ) )。
4、子系统提取OpenId并通过，向认证服务发送OpenId
5、返回用户认证信息
6、返回批准内容
在这两种方法中，OpenId都解决了诸如会话共享方案类型等问题，使用户凭据更加灵活，并表明子系统之间的身份验证是相互独立的。 但是，在第三种方法中，基于所有子系统都是相同的顶级域名的假设，实际操作环境中有多个域名是很正常的，必须考虑如何解决域间的问题。
四. B/S多域环境下的单点登录处理
对于多个顶级域名，您将无法共享每个子系统的OpenId。 要处理B/S环境中的跨域问题，首先应该考虑JSONP的方案。
验证步骤如下：
1、用户通过登录子系统进行用户注册；
2、用户注册子系统记录用户注册状态、OpenId等信息；
3、用户使用业务子系统
4、用户未登录业务子系统时，将用户跳转到用户登录子系统；
5、用户子系统通过JSONP接口将用户OpenId传递给业务子系统；
6、业务子系统通过OpenId调用认证服务；
7、验证服务
返回认证信息、业务子系统构造用户登录凭证；(此时用户客户端已经与子业务系统的验证信息已经一一对应)8、 将用户登录结果返回用户登录子系统，若成功登录则将用户跳转回业务子系统；
9、 将授权后的内容返回客户端；
五、安全问题
经过以上步骤，跨域情况下的单点登录问题已经可以得到解决。而在整个开发过程初期，我们采用用户表中纪录一个OpenId字段来保存用户OpenId，而这个机制下很明显存在一些安全性、扩展性问题。这个扩展性问题主要体现在一个方面：OpenId的安全性和用户体验的矛盾。
整个单点登录的机制决定了OpenId是会出现在客户端的，所以OpenId需要有过期机制，假如用户在一个终端登录的话可以选择在用户每次登录或者每次退出时刷新OpenId，而在多终端登录的情况下就会出现矛盾：当一个终端刷新了OpenId之后其他终端将无法正常授权。
而最终，我采用了单用户多OpenId的解决方案。每次用户通过用户名/密码登录时，产生一个OpenId保存在Redis里，并且设定过期时间，这样多个终端登录就会有多个OpenId与之对应，不再会存在一个OpenId失效所有终端验证都失效的情况。
关注公众号Java技术栈回复"面试"获取我整理的2020最全面试题及答案。
推荐去我的博客阅读更多：
觉得不错，别忘了点赞+转发哦！