疫情过后，想找工作的你还不看这份资料就晚了！！史上最强总结
1.注册、退出、编辑用户信息、逻辑删除、登录、找回密码、日志、用户存储、信息查询、密码加密、密保问题、安全保障。
2.身份信息、短信、邮箱、电话号码绑定、多重认证机制、扫码登录、小程序 qq 微信微博等联合登录、地址、验证码等。
3.人机交互、安全插件、键盘和鼠标监听、进程安全监控、按键输入等特性监控，反机器人登录，反撞库（单位时间内登录错误次数，锁定不允许登录）。
4. 信息生成、传输、存储，需要考虑加密设计、过期失效设计、服务端存储设计可靠性等机制。HTTPSSSL 协议 CA、对称加密、密码加密、主动或被动过期等。
1.3 ?http basic auth、auth2.0、jwt、cas、sso 跨域、cookie 同域分析对比。
1> restful api 每次调用传输用户名和密码做认证，容易暴露敏感信息，已经不在生产环境使用。
2>auth2.0 第一次使用在开放平台网站注册（使用账户和密码注册）时平台生成给的 appId,appSecrect 信息（appSecrect 生成算法，注册唯一用户名、密码、appId 采用 AES\DES 等对称或非对称加密处理，appId 随机分配唯一即可）到授权服务器获取授权码，再采用授权码从认证服务器处获取访问钥匙 token，最后调用开放 api 接口时携带 token,先由认证服务器对 token 进行认证，验证通过由资源服务器处理接口请求，返回用户在开放平台上的私有信息，比如用户昵称、照片、发表的文章等。优势：可以不用知道用户密码等敏感信息就可以访问用户资源，更加安全。优化：负责 token 生产和认证的服务可以和资源服务器合并作为内部服务接口。授权服务器呢？是否可以省略授权码这一阶段，直接获取 token，简化流程。
另外，客户端可以第一次获取 token 后（是否先获取授权码，再次获取 token，或者直接获取 token）就缓存起来，每次调用 openapi 接口直接从本地缓存获取，优化了程序。如果调用 openapi 时，服务端返回 token 过期或 appSecretKey 过期等，处理：1.token 过期，需要采用 refreshToken 接口刷新 token 获取新的 token，当然获取 token 和刷新 token 的接口是不需要拦截验证的/getToken,/ refreshToken。2.如果 appSecretKey 过期，一个是服务端定时任务扫描提前预警快要过期的 appSecretKey，邮件预警即时续费，给 appSecretKey 续期。客户端这边只有联系平台客服，并交钱续期。如果没有期限限制，就不存在 appSecretKey 过期。但是 tmall 聚石塔接口就需要续费或定期申请更换 appSecretKey，过期会影响接口调用。
服务端验证 ip，限制次数流量（最高多少次，一天，一分钟等，根据费用、资源等），token 过期维护、appSecretKey 过期续费提醒。Token 生成、认证、appSecretKey 是否过期认证。
token 在服务端的存储、或 jwt 的不存储机制选择。安全、更可靠选服务器缓存，但是程序更复杂。 jwt 机制适用于简单、中小型的应用。
3>jwt sso 单点登录/服务调用认证。
图-1? OpenId 可视作 JWT
1.相同顶级域名下的单点登录，服务端无需缓存 session 等，无状态的登录认证信息机制。同域共享 cookie 的单点登录，例如 a.xxx.com 和 b.xxx.com。cookie 信息的安全机制、用户的登录身份验证信息服务端 session 端不存储，cookie 的伪造攻击很难防御。
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 中的用户名。
还未添加个人签名 2021.10.31 加入
还未添加个人简介
评论