2.用户在页面登录或是APP调接口登录，传入用户名和密码，请求到后台专用sso server passport.xxx.com处理，验证用户信息，完成登录。如果用户在各个应用或终端被sso拦截器拦截要求登录，就直接返回passport.xxx.com登录页面或APP登录界面（实际使用远程接口登录）。在登验证过程中，passport.xxx.com调用jwt服务生成token，一并返回给客户端，客户端种在cookie里或APP本地存储缓存中，并设置过期时间。
下次访问应用请求url时，cookie会因为应用都共同上一级域名yhd.com而带到应用服务端，或者token存储在本地h5对象里或终端设备本地存储缓存介质里，先取出然后通过请求header头部设置Authrozation:bare+jwt传递给服务端，应用或终端APP的sso拦截器会调用passport.xxx.com远程服务接口（也可能是front-user-rpc-server接口应用）校验jwt里的用户等验证确实登录并返回用户信息，应用系统或APP允许访问资源并返回需要数据,包括用户信息。
这里，网站应用的单点登录与APP的登录分开，不需要网站登录和APP登录强一致。
核心要点：
1.用户一次单点页面登陆，Tc票据回写所有应用共享cookie，访问任何应用，应用都可验证tc。
2.用户登录数据无需服务端存储，登录状态和用户信息在服务端无存储和共享，都在发放给客户端的jwt里。
缺点：
1.jwt一旦发放，不能主动销毁，过期自动无效。
2.非敏感信息安全问题，不要携带。
3.cookie存储，跨站伪造请求攻击,referer。加密技术、过期技术。退出，主动删除携带jwt的cookie。最好不经过cookie就不会有此问题。访问需要登陆的url，必须传递jwt。Jwt暂存哪里好呢,app缓存本地、页面呢，使用html5本地存储？还是cookie还是页面请求url带上jwt参数。Cookie应该比较多。
4>CAS SSO企业级单点登陆常用开源组件。
CAS SSO单点部署: 企业级够用.
CAS SSO集群部署: 需要改造，st、tgt和session的单独缓存。客户端集群，session同步或单独存储，或service携带jsessionid退出本地应用集群时负载到特定的服务器销毁session。
Cas-client.jar：客户端拦截器配置，拦截请求，还有验证service ticket的请求sevlet，对request的包装用户信息的处理。客户端集群每个节点都是session同步的或共享的，一个登录session集群共享。
Cas-server war：
cas-client拦截器判断请求如果没有serviceticket票据或通过service 和service ticket请求cas server验证st失败，就认为没有登陆，重定向到cas-server页面携带service returnUrl,在页面登录，cas-server验证用户信息正确性，登录成功。然后将生产的tgc通过response种到cas-server域下的cookie里，tgc的生命周期就是用户登录的生命周期。最后通过重定向到service returnUrl并携带了cas server随机生成的service ticket,本地应用的Cas-cient拦截器通过returnUrl和service ticket再次发起http请求cas-server获取用户名等信息包装在request对象里，可以读取并记入本地应用session标记登录上，并继续完成请求。在cas-server中没有session只有tgt，tgc种在cookie中。
eg:Map<app.service,st> tcCache。再次请求第二个资源应用时，被cas-client拦截，没有serviceticket,重定向到cas server，cas server域下的tgc cookie被获取验证没失效，则返回service ticket并重定向到returnUrl，本地应用cas-client会通过service ticket和returnUrl service获取用户名并继续完成请求，如果失效，则继续返回cas server的登录页面登录重复以上流程。
service ticket 也种在本应用的cookie里，在cas server缓存<app,st>，服务端st有过期时间。每一个应用就一个自己的ticket即可，是本应用登录的凭证。
在本地应用里的cas server的登出链接，携带service(代表应用)，会销毁cas server服务器里缓存的st，应该包括所有本地应用的st缓存，并销毁cas server域名下的用户tgc cookie，并重定向到本地应用的service地址。tgt存储在tgc里，可以从tgt中找到多个services,并循环调用各个service，cas –client拦截后销毁session。本地应用session共享或同步。多客户端应用，都是集群，消灭各个集群的用户登录session。不集群问题也不大，干掉了tgc，
与CAS server的交互采用HTTPS协议，保证service ticket和tgc cookie的安全。
cas client与cas server使用http请求交互，且对用户是透明的。
图-2 CAS SSO登录认证核心流程
安全保护：passport.xxx.com采用服务器端https认证连接，保证数据传输安全。
Tomcat单向ssl证书，向机构申请证书，配置到服务器端，看nginx，haproxy代理需要配置么。
1.4. 分布式微服务下的用户服务架构设计分析。
用户服务，写少读多。
数据量：单库mysql oracle，一主多备，读写分离
大的话，取余分表，甚至分库分表。
用户接口服务化，支持业务。
单点登录、注册、退出、找回密码等功能专用pool
联合登录（qq、微信、微博、小程序等）
登录时人机识别，防机器人，防泄露用户敏感信息、防非本人非法篡改登录用户系统、防撞库等机制
用户密码加密存储
用户登录监控
黑名单
用户行为日志记录统计分析，比如用户平均登录时长，活跃用户、高等级用户、老客户等等挖掘。
用户级别
新用户
用户交易次数小字段小功能等。
1.5. 第三方账号联合登录（auth2.0实战）
本网站在第三方平台注册帐号，得到appid，appSecrect, 绑定openid或uniqueId，获取授权码，再获取访问token，使用token就可以访问资源。Auth2.0认证。用户在本网站选择使用qq帐号登陆时，点击的是qq开放平台的账号连接，此时，用户需要先登陆qq下，然后获取用户信息后，将获取的openid和本网站的用户信息邦定起来（用户强制绑定）。
点击联合登陆链接，转到第三方平台，授权把资源接口权限开通给本网站，在页面同意授权给本网站，此时如果没有在第三方平台（qq）登陆，需要先登陆，再授权给本网站，跳回本网站，返回授权码，本网站获取到openid等信息并在本网站的用户信息表里存储openid和用户信息绑定，下次登陆，直接根据绑定，即可完成登陆。如果在本网站已有帐号，需要强制绑定，如果没有，也可以根据qq帐号昵称等为用户在本网站创建一个新帐号，用于购物等。
1.6. 企业级 cas实战、cookie同域实战、中小电商jwt sso实战。
CAS /JWT sso前面已讲解。
Cookie同顶级域，用户名密码，session在服务器端必须独立存储，如果应用本地缓存，那么用户访问必须粘连访问特定tomcat session或者session同步到集群整个应用节点，插件session-memcached或session-redis。分布式session服务器集群，客户端spring session+redis。
1.7. 大型电商sso跨域实战。
1.JD的跨域SSO系统流程：单点登录，jsonp跨域种cookie；单点登出，jsonp跨域销毁cookie，cookie或登录票据会自动过期失效。
2.Yhd的sso系统流程：参见文档。
3.从淘宝跳转到天猫，获取用户名，使用ajax发起了跨域jsonp请求获取cookie中的用户名。
4.jsonp跨域请求种cookie的原理：Jsonp跨域请求将cookietc/jwt/openid信息获取或种到其他所有业务子系统应用的cookie中，一处登录，处处种登录凭证，处处即已登录。第一次sso登录生成的tc就jsonp跨域请求种到其他应用域名下的cookie里。登录退出时，也是jsonp跨域请求销毁所有子应用域名下的cookie凭证tc。App等终端可以获取登录tc或openid表示登录。用户凭证在后端存储还是openid，或jwt在客户端存储。openid存储在redis中，一个终端一个openid。其实这里JWT与openid机制还是有区别的。
5.同源策略，浏览器不允许跨网站域名访问其他网站的资源。跨域请求，利用script、 link、 img等标签跨域请求js\css\img数据的特性可以发起跨域请求。jsonp也是Ajax异步跨域请求的一种方式。服务器端设置特性：cross-orignial-domain设置。比如flash跨域必须配置cross类的配置文件。此方面的知识百度，不展开。另外,一个域名下的cookie也只允许本域名网站访问，除非有相同的顶级域名，cookie可以共享。
6.整个单点登录的机制决定了OpenId是会出现在客户端的，所以OpenId需要有过期机制、安全机制、可能携带用户信息、认证权限信息等敏感信息机制，假如用户在一个终端登录的话可以选择在用户每次登录或者每次退出时刷新OpenId，而在多终端登录的情况下就会出现矛盾：当一个终端刷新了OpenId之后其他终端将无法正常授权或认证。而最终，采用了单用户多OpenId的解决方案。
每次用户通过用户名/密码登录时，产生一个OpenId保存在Redis里，并且设定过期时间，这样多个终端登录就会有多个OpenId与之对应，不再会存在一个OpenId失效所有终端验证都失效的情况。Openid传递给其他子系统终端实现多终端登陆： 1、 用户通过登录子系统进行用户登录；
2、 用户登录子系统记录了用户的登录状态、OpenId等信息；这个和jwt的机制有差别，使用了服务器缓存用户多端登录票据。
尾声
以薪资待遇为基础，以发展为最终目标，要在高薪资的地方，谋求最好的发展！
下面是有几位Android行业大佬对应上方技术点整理的一些进阶资料。有**Android架构视频+BATJ面试专题PDF+核心笔记等资料。希望能够帮助到大家提升技术。如果大家想要获取的话，可以私信我【666】免费获取哦**
