jwt+rsa鉴权中心，及cookie写入问题（遇到的坑）

无状态登陆原理

首先说一下有状态：

有状态服务，就是服务每次会话都会记录客户端的信息，从而识别客户端身份，更具用户身份进行请求得处理，比如tomcat中的session

缺点：

1. 服务端保存大量数据，增加服务端压力
2. 服务端保存用户状态，无法水平扩展，（比如其他机器上的服务不会知道别台机器上的session）
3. 客户端请求依赖服务端，多次请求必须访问同一台服务器

无状态:

微服务集群中每个服务对外提供的都是restful风格的接口，二rest风格最重要的规范就是无状态。

1. 服务端不保存任何客户端请求者信息
2. 客户端每次请求必须具备自我描述信息，通过这些信息识别客户端身份

好处：

1. 客户端不依赖服务端，任何多吃请求不需要访问同一台服务器
2. 服务端的集群和状态对客户端透明
3. 服务端可以迁移和伸缩
4. 减小服务端存储压力

 

如何实现无状态

流程：

1. 当客户端第一次登陆时，服务端对用户进行信息认证
2. 认证通过将用户信息进行加密形成tocken，返回给客户端，作为登陆凭证
3. 以后每次请求用户都携带认证的tocken
4. 服务端对tocken解密，判断是否有效

安全性：tocken是识别客户端的唯一标识，如果加密不够严密，被人伪造就完了，采用jwt+RSA非对称加密

JWT

JWT 全程json web tocken,是json风格轻量级的授权和身份认证规范，可实现分布式，无状态的web应用授权

数据格式：

Header：头部。通常头部有俩部分信息

1. 声明类型，这里是JWT
2. 加密方式
3. 我们会对头部进行base64编码得到第2部分信息

Paylod：荷载，就是有效数据，包含：

1. 用户身份信息（使用base64编码，可解码，不要存放敏感信息）
2. 注册声明：如tocken的签发时间，过期时间，签发人等

这里也会采用base64编码，得到第二部分信息

Signature签名：是整个数据的认证信息，一般根据前俩步数据，加上服务的密钥（secrt）（不要泄露，最好周期更换），通过加密算法生成能用于验证真个数据的完整性可靠性

eyJhbGciOiJSUzI1NiJ9.        头部

JpZCI6MjAsInVzZXJuYW1lIjoiamFjayIsImV4cCI6MTYyMjQ3NTExM30.  荷载

签名

R9XxhZurtZQDqHK9iHyVjErOiBa_PuQRnR4CaIj_3QJQJYJiyFlMMhKH   

ZfeVnqWUjsT6HXgQ6vmggqkQ_FzESDUh38Qp4dFbNeZTM4HIcf3BWh

pZqUxv6M3v_ppC7OSMH_QOJQNHM4aAAx5TTYsJppeWLl_Lir_GK_kFouxL90
 

JWT交互流程

1. 用户登陆
2. 服务的认证，通过后根据secret生成tocken
3. 将生成的tocken返回给浏览器
4. 每次请求携带tocken
5. 服务端利用公钥解读jwt签名，判断签名有效后，从payload中获取信息
6. 处理请求返回响应结果
7. 因为JWT签发的tocken中已经包含了用户身份信息，并且每次请求都会携带，这样就无需保存用户的信息了

加密方式

对称加密：如AES

• 基本原理：将密文分为N个组，然后使用密钥对各个组进行加密，形成各自的密文，最后把所有分组密文进行合并，形成最终密文
• 优势：算法公开，计算量小，加密速度快，加密效率高
• 缺点：双方都有同样的密钥，安全性不高

非对称加密：如RSA

• 基本原理同时生成俩把密钥：私钥和公钥，私钥隐秘保存，公钥下发给信任的客户端

私钥加密：持有公钥或者私钥才能解密

公钥加密：持有私钥才能解密

优点：安全，男破解

缺点：算法比较耗时

不可逆加密

基本原理：加密过程中不使用密钥，输入明文后直接由系统加密处理为密文，这种加密方式是无法通过密文推算出明文的

 

 

理解:jwt解决了什么问题：私钥是用来签名的，输入用户名密码，鉴权通过后，使用私钥获取jwt签名，发给客户端，客户端后面访问时就携带jwt请求网关和微服务，网关和问服务使用公钥验证签名，正确就取出载荷里的用户信息。

没解决的问题：登陆时候用户名密码，还有登陆后的jwt在网络上都是明文传输了，如果被人监听就会泄露信息，这里就又要加密了。

加密办法和https

 

cookie问题

但我们通过postman访问时咳哟看到有返回的cookie信息，而通过门户网站访问却没有cookie信息，

原因是，我们通过门户网站访问的地址是nginx的地址，然后nginx做代理把请求给zuul网关处理（这时候域名是网关的地址），zuul网关又通过eureka注册中心来找到对应服务的地址（计算机名+端口+路径） ，然后域名就变成了对应服务的计算机名

解决：要把域名传递过去：

1. nginx中配置：proxy_set_header Host $host;   #设置请求头Host我为请求的请求头host
2. zuul网关中配置:add-host-header: true    #携带请求头信息，
3. zuul网关配置：sensitive-headers: #覆盖敏感头信息，这里为空表示不过滤任何敏感头信息，让cookie可以正常写入

配置第三步的原因zuul的PreDecorationFilter过滤器把敏感头信息过滤了详细代如下

if (!route.isCustomSensitiveHeaders()) {
					this.proxyRequestHelper
							.addIgnoredHeaders(this.properties.getSensitiveHeaders().toArray(new String[0])); //忽略敏感头信息
				}
				else {
					this.proxyRequestHelper.addIgnoredHeaders(route.getSensitiveHeaders().toArray(new String[0]));
				}

忽略的头信息内容：可以看到把cookie忽略了

 

 

 

修改了spring cloud的版本后终于可以搞到cookie了。干。

遇到问题：超级坑壁的问题，全设置好了还是获取不到正确的域名，导致设置不上cookie。原因：Finchley.SR1版本会存在获取不到cookie值的bug，所以要spring-cloud-dependencies替换成Finchley.RELEASE版本。

参考