一步步搭建分布式---整合sso单点登录+第三方登录+支付对接---要点

使用jwt完成sso单点登录

架构图如下：

可解决分布式和跨域的问题
架构的演进：

第一种单点登录

第二种单点登录

web集群，session共享

中间有一个使用redis完成session池，完成session共享—jsessionId相当于密钥。黑客通过拿到浏览器的cookie里面的jssionId（或者劫持jssionId）就可以 破解了（频繁连接rediss，缓存中取数据，再解密，进行比对）

改进

分布式中如果 用到了session，一定要有session池，让session共享

第三种单点登录

优缺点

jwt可以自定义token（只要算法足够复杂）。京东是把jwt生成的token直接写入到浏览器里面，再加入一些用户的信息（比如userId）。认证中心去解这个token，只要能解开，该用户（浏览器就是一个合法的浏览器）就是合法的。用户将不再打开rediss，拿到token，直接去掉了数据的开关。由访问数据库，访问业务功能的算法变成了加密解密的算法。由连接db的connection变成了加密解密的jar包（即jwt的jar，里面含有密钥。—该jar需要足够的安全，不能被反编译，让人获取到jar里面的东西）。你把token传给我，我用算法解得开，就是合法的（就能从token里面拿到用户的userId-------所以就不需要访问rediss，从里面拿token）。---------好像支付宝的java版的sdk。。。里面就含有密钥

结算，订单，购物的请求都会被拦截器拦截

拦截器相当于海关的警察。你的护照/身份证都会经过认证中心（出入境管理中心–只负责护照的颁发和认证—不负责用户信息的查询，身份证认证器）。。。。然后警察决定让不让你同行。（如果身份证过期，护照又不是你本人的，拦截器肯定不会让你放行的）。

该登录系统很方便与其他系统做对接-------认证中心的架构图

该端口号是提供给http和web请求服务

sesisonid弊端

使用共享sessionid的方式，它有一个弊端，就是无法跨顶级域名共享。taobao.com的cookie无法共享到alipay.com下，所以使用sessionid做的用户认证模块，其实它是和别的模块的耦合度比较高的。所以我们应该使用token来将用户认证模块单独独立出来。其实这就是sso单点登录的实现原理。

实现方案

sso（single sign on）可以自己写代码是实现。也可以使用框架实现。比如CAS（center authentic service认证服务中心）+shiro

代码实现

服务器key（这是服务端的密钥—服务器的唯一标识），用户信息，盐值（他是位于浏览器的，每个浏览器再不同的时间访问的时候所生成的jwt的token的 结果都不一样。随着时间，浏览器id的不同，这个盐分咸度是不一样的，一般是ip+浏览器的访问时间）

当前用户通过当前浏览器在固定时间内使用当前服务器token才有效，token就和这三者绑定在了一起，只要有一个被串改，token的都是无效的。这可以保证安全


谁申请，谁保存。认证中心只负责颁发token。拦截器验证完token后，将最新的token写入到浏览器的cookie里面。

浏览器请求业务模块，业务模块发现里面没有token，（体会浏览器）让浏览器重定向到认证中心。认证中心为浏览器返回一个登录的页面（点击订单被拦截，跳转到登录页面），在输入用户名/密码给认证中心。认证中心认证通过后会颁发token给浏览器（这是第5步和第6步----url中带着token）。（还未存入cookie里面）浏览器会带着含有token的请求再次访问业务模块。此时业务模块的拦截器会进行拦截，再将token写入到浏览器的cookie里面，拦截器放行。以后再登录，因为有了token，所以直接就能登录成功了

认证中心passport设计成controller，并且是restful风格，目的就是为了方便第三方系统接入（使用java代码发送http请求，远程调用服务，）。不能将其设为service，因为service只能是本项目，本应用能调用。它并不支持跨应用远程访问。

认证中心是用来颁发和验证token的，所以把他写作controller，而非service。controller写可以跨顶级域名实现认证的

第三代的缺点：认证中心的访问压力比较大。—负载均衡就可以了。如果用到了redis和db，这二者的压力又更大了。

业务逻辑

整合第三方登录

A. 在浏览器的页面（csdn上）点击第三方链接，跳转到第三方页面----进行授权
点一下qq，就是发送了一个授权请求

再点一下自己的qq头像----B操作—权限授予

1. A,B中的（Resource Owner）指用户，用户收到授权请求，用户授予权限许可

CDEF操作就是不可见的了
2. CD----腾讯服务器收到用户的授权同意了，腾讯服务器（Authorization Server）再发送允许通行的token给csdn
3. EF----csdn（Resource Server）拿到token后，再通过token从腾讯服务器哪里换取用户的信息，再将这个受保护的信息发给客户端进行csdn博客平台的登录。
获得授权码，再发送请求，通过授权码去交换—许可码–access-token
然后使用access-token去交换用户的信息

好比我把书放在了张三这里，李四来到张三这里想向他借这本书，但书是我的，所以张三需要先来问我是否同意借给他，我同意了，张三才能把书借给李四。

client就是小明，其中Client指第三方应用，，Authorization Server是我们的授权服务器，Resource Server是API服务器。

上述流程其实就是第三方登录/支付人们定义的auths协议

参考：https://blog.csdn.net/u010251897/article/details/80708498

项目中的三次远程调用（不算dubbo）

1. 对接第三方登录（restful风格的http）
   
2. 使用单点登录–调用认证中心（restful风格的http）
   

项目中的整合第三方支付

appid原来的名称是partterner，他就相当于你的应用和第三方应用达成的一个合作协议----即彼此都信任对方的意思。

对称加密：
天王盖地虎，宝塔镇河妖（我和他都知道天王盖地虎，宝塔镇河妖----对称密钥）

rsa非对称加密：
他和我的密钥不一样，不知道他的密钥，他也不知道我的密钥—两个超大质数的乘积的因式分解不可逆原理。rsa计算机需要算20年。
5*7=35
告诉大家有数为35，它是有两个超大质数的乘积的到。。。2048位的两个质数的乘积得到。。。
5和7，这是私钥
35是公钥
只有我知道是私钥，公钥所有人都可以知道。但只有我的私钥加密后 的签名可以解开公钥。。。5和7有乘积因式分解的关系—利用这种关系。。。。。我发了一条命令，你用35（质数乘积的算法）可以读出我的命令。其他人无法加密出来这样一条信息，你用4和5加密出来的，用35是无法解开的。。。。只有5和7加密的才能解开。。。。。。。如果你用35的公钥解出了一条信息。那你可以百分百确定这条信息是由合作伙伴我发出来的，如果解不开，这条信息就是伪造的

非对称用的都是rsa，但如果量子计算机技术成熟，该算法就结束了。计算机2年算，量子只需要2小时，你用公钥3和5解出来，就一定知道是我。。。。。。5*7=35.。。。。不管信息来源来自哪，我用公钥解开，就能确定唯一的身份。。。非对称密钥的网络签名。。。。。。使用私钥加密形成签名是为了验证身份和防伪。

网络签名
用户请求网站，网站返回给用户一个url。。。。url中携带着一个send签名（这是通过商城的私钥生成的签名，同时商城也会把公钥交给支付宝）。支付宝拥有了商城的公钥。。。。。支付宝用网站的公钥去解用户url中的签名，解开说明请求合法。。。支付宝再调网站，再发信息（用自己的私钥生成签名）给网站，支付完毕。。。。黑客可伪装支付宝。。。。。。。。网站拥有支付宝的公钥，所以它可以用支付宝的公钥去解支付宝的私钥