* C端用户身份认证令牌生成(处理器)* 可将用户信息加密到token中,服务器不保存任何用户信息。服务器通过使用保存的密钥验证token的正确性,只要正确即通过验证。* 官网:https://jwt.io/* 参考链接:http://www.what21.com/u/10004/8500160812902131556.htm* 推荐场景(需确认C端用户身份,通过此令牌防止C端或黑客拦截报文篡改用户身份信息,从而导致接口调用后敏感信息泄露)* JWT的应用场景:* 1、json格式简单,相比xml,jwt中已经有了需要的全部信息。* 2、同session相比,性能更好一些,省去了处理分布session的问题;对于大行其道的restful来讲,支持得很好;浏览器+app+pc,这种多终端开发,是很好的选择。* 3、令牌请求时放到请求报文的header中进行上送(请求键请使用paas-jwt)* 应用场景流程:* 1、用户认证。认证方式可能很多,自己认证或者sso。* 2、认证后,调用易百服务端的此接口构造JWT。* 3、把JWT返回服务端(客户端),客户端存储。* 4、客户端访问服务器,请求头带上JWT。* 5、服务器端判断JWT是否正确并且没有超时,正常,向下流转;否则,转到授权。* 特别注意:对于外部对接gateway网关访问PAAS接口中,需要对接方在适当时机(如用户授权)请求此接口进行令牌颁发* 客户端直接颁发会有安全性问题,必须由对接方服务端进行此接口调用,且gateway网关进行对接方服务端的IP白名单配置
PAAS内部逻辑: 1)gateway增加JWT验证支持,配置微服务接口黑白名单方式开启验证功能(哈根项目先以白名单方式追加验证,未来通过黑名单方式剔除无状态接口) 2)gateway验证JWT后需要将业务载体对象传递给rpcRequest的header(header键暂定paas-jwt-preload) 3)微服务层获取用户信息(由原来从请求对象中获取用户ID的方式调整为从rpcRequest中的Header获取)*** 最佳实践:微服务可使用拦截器拦截rpcRequest头部信息,通过反射转成业务对象的用户标识字段
请求报文示例:
{ "uuid": "20211224-kecwygdsipokqstbqtbwmqlpxijewfbf", "appId": "ebuytes100100100", "action": "genJsonWebToken", "timestamp": 1640331603, "signType": "sha256", "sign": "1289147634148182", "content": { "phoneNumber": "135xxxx8254", "thirdOpenId": "fd6e02c1ee5f9de3df811d03244c8e42" }, "lang": "zh_CN" }
响应报文示例:
{ "uuid": "20211224-kecwygdsipokqstbqtbwmqlpxijewfbf", "action": "genJsonWebToken", "content": { "paasJwt":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhcHBJZCI6ImVidXlkOGM2N2QzNzE3NzEiLCJ0aGlyZE9wZW5JZCI6ImZkNmUwMmMxZWU1ZjlkZTNkZjgxMWQwMzI0NGM4ZTQyIiwiZXhwIjoxNjQwMzMyMTIyLCJub25jZSI6ImR6QnJiY0hVIiwiaWF0IjoxNjQwMzMyMDkyLCJtZW1iZXJJZCI6ImZkNmUwMmMxZWU1ZjlkZTNkZjgxMWQwMzI0NGM4ZTQyIn0.YdU4lZQ4_34O9jomyOMOnz6Kad0breQVzSF89hgis-k" }, "success": true, "errorCode": "", "errorMessage": "", "timestamp": 1640332092481, "signType": "sha256", "sign": "f94ddcbf0ab5bc28ad0fb018a4365b7164c9dbfb46de458e704813d7757b4bd7" }
注意:为保证签名的一致性,返回报文中的content字段将以string形式的进行返回,例如:
{ "content": { "userId": 1, "userName": "Trump" } }
将返回为:
{ "content": "{\"userId\":1,\"userName\":\"Trump\"}" }
No Comments