专业剑 : JWT

JWT是各方之间安全传输信息的一种方式，JWT使用签名加密，安全性很高。另外，当 Header和Payload计算签名时，还可以验证内容是否被篡改。

 JWT、JWE、JWS 、JWK 都是什么鬼？还傻傻分不清？_互联网架构的博客-CSDN博客

https://www.cnblogs.com/shihaiming/p/9565835.html

JWT格式：header.payload.signature

1、header是头部信息

对明文的base64编码，不是加密，是可逆的。

{ 'typ': 'JWT', 'alg': 'HS256' }

2、Payload是数据包，同样是base64编码，可逆。

1）标准中注册的声明

  iss: jwt签发者

  sub: jwt所面向的用户

  aud: 接收jwt的一方

  exp: jwt的过期时间，这个过期时间必须要大于签发时间

  nbf: 定义在什么时间之前，该jwt都是不可用的.

  iat: jwt的签发时间

  jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。

2）公共的声明

3）私有的声明

3、Signature是签名，加密信息，用于验证。

可以用不可逆加密，比如SHA256，MD5，也可以使用非对称加密，比如RSA256.

使用非对称加密，用私钥加密得到签名部分，用公钥解密得到明文。

相当于JWT =

Base64UrlEncode(header) + “.”

+ Base64UrlEncode(payload) + “.”

+ SHA256RSA.sign(base64header, base64payload, privateKey)

签名的部分是对base64header + “.” + base64payload，通过私钥做RSA256加密得到。

请求端获得JWT后，可以对base64header和base64payload的部分做base64解码得到明文。可以对签名的部分通过公钥publicKey解密得到明文，通过后者得到的明文更安全，还可以对两者的明文做比对。

比如ms-ibss，把uniqueId放入payload，通过私钥加密得到签名部分，调用hk ibss传递参数（raoCaseId, uniqueId, ipAddress, deviceId）, ibss不需要用私钥进行加密得到JWT；返回JWT给前端。

前端调用hk ibss时传递参数（deviceId，JWT），ibss对JWT的签名部分通过公钥解密得到明文，获得uniqueId，查询得到关联的deviceId，比对请求的参数（deviceId）进行校验。

SHA256是散列加密。

如果修改JWT中的payload部分，解析jwt时是否会报错？会，不能通过签名校验。

理论上，攻击者可以先通过一个正确的请求获得正确的JWT，然后使用该JWT直到过期。

 总结

1. 可以保证header，payload和signature的一致性。

2. 可以防止payload信息被篡改。

3. header和payload的信息可能被泄漏。

解决中间人攻击的方案

1、在接口A上面增加注解@Pitcher投手，在接口返回响应时，对返回json体生成JWT，并放入响应header。

HandlerInterceptor无法使用postHandler修改response

https://www.cnblogs.com/haitao-fan/p/10308772.html

使用ResponseBodyAdvice修改response的header，需要有@ResponseBody

https://www.cnblogs.com/nuccch/p/7891634.html

2、在接口B上增加注解@Catcher捕手。

在接口收到请求时，对JWT解码获得json体，进行校验。

要拦截请求，获取到请求头；要判断是否有注解@Catcher；

判断请求头是否有token；从token解码出json体；

从json体判断是否。

https://www.jianshu.com/p/657fa7118e84?utm_source=oschina-app

不能使用RequestBodyAdvice，因为需要有@RequestBody

https://www.hellojava.com/a/45272.html

https://www.cnblogs.com/Wicher-lsl/p/11436224.html

JWE

JWE全称是Json Web Encripytion，即json web 加密。

java rsa加密_java如何使用JWE进行加密-CSDN博客

JWE是由系列标准组成的，JWEHeader就是java实现这一标准的一个类。

JWEHeader里面有各种各样的参数，比较重要的有alg，enc，kid，

alg表示使用的公钥算法模式，我们使用的是alg=RSA-OAEP。

alg和使用的公钥有关，如果使用的是RSA公钥，alg可以取值：RSA1_5，RSA_OAEP，RSA-OAEP-256；如果使用的是ECC公钥，则取值可能为：A128KW，A192KW，A256KW等。

enc表示的是使用的加密分组是多少位，并采用哪种方式，enc=A128GCM,表示使用128位分组的GCM加密方式。

kid用来标识使用的公钥，一般由解密方提供，用来告诉解密方用的哪把秘钥。jwk的id编号。

最后是JWE加密的输出，JWE加密的输入也是有一系列的标准定义的：一般密文输出都是如下格式：

输出的JWE Compact序列为：

BASE64URL(UTF8(JWE Protected Header)) || ’.’ || BASE64URL(JWE Encrypted Key) || ’.’ ||BASE64URL(JWE Initialization Vector) || ’.’ || BASE64URL(JWE Ciphertext) || ’.’ || BASE64URL(JWE Authentication Tag)

如何评价IBSS的JWT

比如ms-ibss，把uniqueId放入payload，通过私钥加密得到签名部分，调用HK IBSS传递参数（raoCaseId, uniqueId, ipAddress, deviceId）, IBSS不需要用私钥进行加密得到JWT；返回JWT给前端。

前端调用HK IBSS时传递参数（deviceId，JWT），IBSS对JWT的签名部分通过公钥解密得到明文，获得uniqueId，查询得到关联的deviceId，比对请求的参数（deviceId）进行校验。

进入激活页面，

1. 前端调用BFF，前端传递IPAddress和DeviceId。

2. BFF调用ms-rao，BFF从请求头获取applicationID，即RAOCaseId。

3. ms-rao调用ms-ibss，ms-rao通过工具类随机生成UniqueId。

4. ms-ibss调用IBSS/init，生成JWT并绑定设备。

请求头包括Rquuid，ClientId，ClientCountry，TraxDateTime，请求体包括RAOCaseId，UniqueId，IPAddress，DeviceId。如果返回成功，ms-ibss用UniqueId生成JWT，返回给RAO和前端。

生成JWT：ms-ibss从本地密钥文件rao-keystore-4096.jks获取keystore，通过别名（mscp-dev/prod.ocbcgroup.ocbc.com）从keystore获取公钥，通过别名和密码获取私钥；再通过UniqueId和expiresDate生成JWT。

5. 前端直接调用IBSS/isEligible，校验JWT。

前端传递JWT和deviceID；IBSS校验JWT，若成功则返回E2EE.Public Key Modulus（公钥），Public Key Exponent, 3DES Key Length。前端存储上述公钥key到encrypted store。

6. 用户输入账户名和密码，激活。

7. 前端直接调用IBSS/create，绑定用户和JWT。

前端获取存储的公钥key，调用E2EE.js对密码做对称加密。

前端调用IBSS/create，传递JWT和账户名/密码。

IBSS校验JWT。

IBSS注册并激活账户名和密码。

注：IBSS负责生成和校验JWT。JWT同RAOCaseId，UniqueId，IPAddress，DeviceId关联绑定（意味着绑定过的DeviceId是否可以再用，取决于IBSS绑定关系的强弱）。

调用/isEligible时，JWT的作用是设备校验的数字签名。

调用/create时，账户成功激活后把账户名和密码通过JWT关联绑定。

估计登录及后续操作，都会把JWT作为身份校验的数字签名。

设备校验：IBSS通过JWT获取关联对应的UniqueId和DeviceId，同前端传递的DeviceId比较是否一致。

总结：

1. 该方案的JWT通过UniqueId生成，UniqueId先和应用信息（applicationID，ClientId），设备信息（UniqueId，IPAddress，DeviceId）绑定。再同用户信息（账号，加密后密码）绑定。

2. JWT的payload其中不包括设备信息或用户信息。而且JWT的生成是在用户登录之前。

3. 公钥和算法存储在前端js，容易被攻击。

如何评价中兴的token校验

中兴微服务框架的token校验，场景是在公司内部（跨局域网或者广域网），解决员工的电脑访问公司的服务器的身份认证的问题。

一、            员工的设备一定安装uac的客户端，uac客户端负责请求uac服务端，生成和更新token，并缓存在本地。

二、            员工设备上的应用，从缓存获取token放到请求头（empno, clientip, token, syscode），发送给应用的服务端。

三、            应用的服务端校验token，通过请求uac服务端校验，如果通过则放入缓存。

问题：可能受到中间人攻击。

如何评价OCBC的token认证方案

用户登录，MFE访问ms-cust-sec，传递用户名和密码，用户身份验证成功，返回token。

后续MFE访问其他服务和接口都需要在请求头传递token，包括x-acc-op。

gateway负责路由转发，通过调用ms-auth校验token。

当用户需要进行高风险交易，通过调用ms-cust-auth进行授权，比如OTP，TAC，2FA等方式。

用户通过手机安装了APP和SDK，并成功绑定了soft token，ms-token-mgn负责token的管理，比如注册，激活等。

ms-authorization - 专业剑 - Confluence