wordpress 屏蔽搜索,郴州网站排名优化,php网站开发实,有没有网页设计专业JWT的主要应用场景身份认证在这种场景下#xff0c;一旦用户完成了登陆#xff0c;在接下来的每个请求中包含JWT#xff0c;可以用来验证用户身份以及对路由#xff0c;服务和资源的访问权限进行验证。由于它的开销非常小#xff0c;可以轻松的在不同域名的系统中传递一旦用户完成了登陆在接下来的每个请求中包含JWT可以用来验证用户身份以及对路由服务和资源的访问权限进行验证。由于它的开销非常小可以轻松的在不同域名的系统中传递所有目前在单点登录(SSO)中比较广泛的使用了该技术。 信息交换在通信的双方之间使用JWT对数据进行编码是一种非常安全的方式由于它的信息是经过签名的可以确保发送者发送的信息是没有经过伪造的。JWT的结构JWT包含了使用.分隔的三部分 Header 头部 Payload 负载 Signature 签名其结构看起来是这样的Header.Payload.SignatureHeader在header中通常包含了两部分token类型和采用的加密算法。{ alg: HS256, typ: JWT} 接下来对这部分内容使用 Base64Url 编码组成了JWT结构的第一部分。PayloadToken的第二部分是负载它包含了claim Claim是一些实体(通常指的用户)的状态和额外的元数据有三种类型的claimreserved, public 和 private.Reserved claims: 这些claim是JWT预先定义的在JWT中并不会强制使用它们而是推荐使用常用的有 iss(签发者),exp(过期时间戳), sub(面向的用户), aud(接收方), iat(签发时间)。 Public claims根据需要定义自己的字段注意应该避免冲突 Private claims这些是自定义的字段可以用来在双方之间交换信息 负载使用的例子{ sub: 1234567890, name: John Doe, admin: true} 上述的负载需要经过Base64Url编码后作为JWT结构的第二部分。Signature创建签名需要使用编码后的header和payload以及一个秘钥使用header中指定签名算法进行签名。例如如果希望使用HMAC SHA256算法那么签名应该使用下列方式创建 HMACSHA256( base64UrlEncode(header) . base64UrlEncode(payload), secret) 签名用于验证消息的发送者以及消息是没有经过篡改的。 完整的JWT 完整的JWT格式的输出是以. 分隔的三段Base64编码与SAML等基于XML的标准相比JWT在HTTP和HTML环境中更容易传递。 下列的JWT展示了一个完整的JWT格式它拼接了之前的Header Payload以及秘钥签名encoded-jwt3.pngpython发送数据import calendarimport datetimeimport timeimport jenkinsimport requestsimport jsonimport loggingimport configparserimport jwt#read the private_keywith open(rsa_private_key.pem) as f:private_key f.read()exp datetime.datetime.utcnow() datetime.timedelta(minutes10)exp calendar.timegm(exp.timetuple())# Generate the JWTpayload {# issued at timeiat: int(time.time()),# JWT expiration time (10 minute maximum)exp: exp,# Integrations GitHub identifieriss: tom,}encoded jwt.encode(payload, private_key, algorithmRS256)try:headers {content-type: application/json,jwt: encoded}response requests.post(server_url, headersheaders)if response.status_code ! 200:logger.error(commit builds post go wrong , status code is : {}.format(response.status_code))logger.error(response.text)except Exception as e:logger.error(commit builds post Error: {}.format(e))java接受数据(springboot拦截器)public class WebInterceptor implements HandlerInterceptor {static final Logger logger LoggerFactory.getLogger(WebInterceptor.class);Autowiredprivate MyConfig myconfig;Overridepublic boolean preHandle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Object o) throws Exception {logger.info( request before );String jwt httpServletRequest.getHeader(jwt);logger.info(jwt is : jwt);String str null;if(myconfig null){WebApplicationContext wac WebApplicationContextUtils.getRequiredWebApplicationContext(httpServletRequest.getServletContext());myconfig wac.getBean(MyConfig.class);}try {//read the public keyFile file ResourceUtils.getFile(myconfig.getRsaPublicKeyDir());FileReader reader new FileReader(file);BufferedReader bReader new BufferedReader(reader);StringBuilder sb new StringBuilder();String s;while ((s bReader.readLine()) ! null) {sb.append(s);}bReader.close();str sb.toString();RsaKeyUtil rsaKeyUtil new RsaKeyUtil();PublicKey publicKey rsaKeyUtil.fromPemEncoded(str);// create a JWT consumerJwtConsumer jwtConsumer new JwtConsumerBuilder().setRequireExpirationTime().setVerificationKey(publicKey)//不能少不然会报错.setRelaxVerificationKeyValidation().setJwsAlgorithmConstraints( // only allow the expected signature algorithm(s) in the given contextnew AlgorithmConstraints(AlgorithmConstraints.ConstraintType.WHITELIST, // which is only RS256 hereAlgorithmIdentifiers.RSA_USING_SHA256)).build();// validate and decode the jwtJwtClaims jwtDecoded jwtConsumer.processToClaims(jwt);Map jwtClaims jwtDecoded.getClaimsMap();Object iss jwtClaims.get(iss);logger.info(jwtClaims is : jwtClaims);}catch (Exception e){logger.error(e.getMessage());return false;}return true;}}签名的目的最后一步签名的过程实际上是对头部以及载荷内容进行签名。一般而言加密算法对于不同的输入产生的输出总是不一样的。对于两个不同的输入产生同样的输出的概率极其地小(有可能比我成世界首富的概率还小)。所以我们就把“不一样的输入产生不一样的输出”当做必然事件来看待吧。所以如果有人对头部以及载荷的内容解码之后进行修改再进行编码的话那么新的头部和载荷的签名和之前的签名就将是不一样的。而且如果不知道服务器加密的时候用的密钥的话得出来的签名也一定会是不一样的。服务器应用在接受到JWT后会首先对头部和载荷的内容用同一算法再次签名。那么服务器应用是怎么知道我们用的是哪一种算法呢别忘了我们在JWT的头部中已经用alg字段指明了我们的加密算法了。如果服务器应用对头部和载荷再次以同样方法签名之后发现自己计算出来的签名和接受到的签名不一样那么就说明这个Token的内容被别人动过的我们应该拒绝这个Token返回一个HTTP 401 Unauthorized响应。信息会暴露是的。所以在JWT中不应该在载荷里面加入任何敏感的数据。在上面的例子中我们传输的是用户的User ID。这个值实际上不是什么敏感内容一般情况下被知道也是安全的。但是像密码这样的内容就不能被放在JWT中了。如果将用户的密码放在了JWT中那么怀有恶意的第三方通过Base64解码就能很快地知道你的密码了。JWT的适用场景我们可以看到JWT适合用于向Web应用传递一些非敏感信息。例如在上面提到的完成加好友的操作还有诸如下订单的操作等等。其实JWT还经常用于设计用户认证和授权系统甚至实现Web应用的单点登录。在下一次的文章中我将为大家系统地总结JWT在用户认证和授权上的应用。
