cms可以做多少个网站/seo快速工具

下面内容参考文章JWT详细讲解(保姆级教程)-阿里云开发者社区 (aliyun.com)

1.什么是JWT？

JSON Web Token（JWT）是一种开放标准（RFC 7519），它定义了一种紧凑且独立的方式，用于作为 JSON 对象在各方之间安全地传输信息。此信息可以被验证和信任，因为它是经过数字签名的。JWT 可以使用密钥（使用 HMAC 算法）或使用 RSA 或 ECDSA 的公钥/私钥对进行签名。

2.何时应使用 JSON Web 令牌？

授权：这是使用 JWT 的最常见方案。用户登录后，每个后续请求都将包含 JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是当今广泛使用 JWT 的一项功能，因为它的开销很小，并且能够轻松地跨不同域使用。
信息交换：JSON Web 令牌是在各方之间安全传输信息的好方法。由于可以对 JWT 进行签名（例如，使用公钥/私钥对），因此您可以确定发送者是他们所说的人。此外，由于签名是使用标头和有效负载计算的，因此您还可以验证内容是否未被篡改。

3.JWT结构（structure）

三部分组成，通过 . 分割开

Header
Payload
Signature

xxxxx.yyyyy.zzzzz

（1）Header

报头通常由两部分组成: Token的类型(即 JWT)和所使用的签名算法(如 HMAC SHA256或 RSA)。


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

最终这个 JSON 将由base64进行加密（该加密是可以对称解密的)，用于构成 JWT 的第一部分,eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9就是base64加密后的结果。

（2）Payload

Token的第二部分是有效负载，其中包含声明。声明是关于实体(通常是用户)和其他数据的语句。有三种类型的声明: registered claims, public claims, and private claims。

例如：

{"sub": "1234567890",// 注册声明"name": "John Doe",// 公共声明"admin": true // 私有声明
}

这部分的声明也会通过base64进行加密,最终形成JWT的第二部分。

registered claims(注册声明)

这些是一组预定义的声明，它们 不是强制性的，而是推荐的 ，以 提供一组有用的、可互操作的声明 。

例如:

iss: jwt签发者
sub: jwt所面向的用户
aud: 接收jwt的一方
exp: jwt的过期时间，这个过期时间必须要大于签发时间
nbf: 定义在什么时间之前，该jwt都是不可用的.
iat: jwt的签发时间
jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击

注意:声明名称只有三个字符，因为 JWT 意味着是紧凑的。

Public claims(公共的声明)

使用 JWT 的人可以随意定义这些声明( 可以自己声明一些有效信息如用户的id,name等,但是不要设置一些敏感信息,如密码 )。但是为了避免冲突，应该在 JWT注册表中定义它们，或者将它们定义为包含抗冲突名称空间的 URI。

Private claims(私人声明)

这些是创建用于在同意使用它们的各方之间共享信息的习惯声明，既不是注册声明，也不是公开声明( 私人声明是提供者和消费者所共同定义的声明 )。

注意:对于已签名的Token，这些信息虽然受到保护，不会被篡改，但任何人都可以阅读。除非加密，否则不要将机密信息放在 JWT 的有效负载或头元素中。

（3）Signature

要创建Signature，您必须获取编码的标头（header）、编码的有效载荷(payload)、secret、标头中指定的算法，并对其进行签名。

例如，如果您想使用 HMAC SHA256算法，签名将按以下方式创建:

HMACSHA256(base64UrlEncode(header) + "." +base64UrlEncode(payload),secret)

上面的JSON将会通过HMACSHA256算法结合secret进行加盐签名(私钥加密)，其中header和payload将通过base64UrlEncode()方法进行base64加密然后通过字符串拼接 "." 生成新字符串,最终生成JWT的第三部分SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

注意:secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了

（4） JWT的生成与解析

JWT输出是三个由点分隔的 Base64-URL 字符串，这些字符串可以在 HTML 和 HTTP 环境中轻松传递，同时与基于 XML 的标准(如 SAML)相比更加紧凑。

真实情况,一般是在请求头里加入Authorization，并加上Bearer标注最后是JWT(格式:Authorization: Bearer <token>)：

通过Java代码实现JWT的生成( 使用的是JJWT框架 )

先导入JJWT的依赖(JJWT是JWT的框架)

        <!--JWT(Json Web Token)登录支持--><dependency><groupId>io.jsonwebtoken</groupId><artifactId>jjwt</artifactId><version>0.9.1</version></dependency>

测试代码如下:

public class JjwtTest {@Testpublic void generateToken() {// JWT头部分信息【Header】Map<String, Object> header = new HashMap<>();header.put("alg", "HS256");header.put("typ", "JWT");// 载核【Payload】Map<String, Object> payload = new HashMap<>();payload.put("sub", "1234567890");payload.put("name","John Doe");payload.put("admin",true);// 声明Token失效时间Calendar instance = Calendar.getInstance();instance.add(Calendar.SECOND,300);// 300s// 生成TokenString token = Jwts.builder().setHeader(header)// 设置Header.setClaims(payload) // 设置载核.setExpiration(instance.getTime())// 设置生效时间.signWith(SignatureAlgorithm.HS256,"secret") // 签名,这里采用私钥进行签名,不要泄露了自己的私钥信息.compact(); // 压缩生成xxx.xxx.xxxSystem.out.println(token);}
}

结果如下：

通过Java代码实现JWT的解码( 使用的是JJWT框架 )

@Testpublic void getInfoByJwt() {// 生成的tokenString token = "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImV4cCI6MTY2MzI5NzQzMX0.Ju5EzKBpUnuIRhDG1SU0NwMGsd9Jl_8YBcMM6PB2C20";// 解析head信息JwsHeader jwsHeader = Jwts.parser().setSigningKey("secret").parseClaimsJws(token).getHeader();System.out.println(jwsHeader); // {typ=JWT, alg=HS256}System.out.println("typ:"+jwsHeader.get("typ"));// 解析PayloadClaims claims =    Jwts.parser().setSigningKey("secret").parseClaimsJws(token).getBody();System.out.println(claims);// {sub=1234567890, name=John Doe, admin=true, exp=1663297431}System.out.println("admin:"+claims.get("admin"));// 解析SignatureString signature =    Jwts.parser().setSigningKey("secret").parseClaimsJws(token).getSignature();System.out.println(signature); // Ju5EzKBpUnuIRhDG1SU0NwMGsd9Jl_8YBcMM6PB2C20}

结果：

5.为什么不用session和cookie ,反而用token

基于session认证的登入系统存在的问题:

session

每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。

扩展性

用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。

CSRF

因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。

基于token的鉴权机制,就没有这些问题:

基于token的鉴权机制

基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。

6.为什么使用JWT

由于 JSON 没有 XML 那么冗长，所以当对它进行编码时，它的大小也更小，这使得 JWT 比 SAML 更加紧凑。这使得 JWT 成为在 HTML 和 HTTP 环境中传递的一个很好的选择。
在安全性方面，SWT 只能由使用 HMAC 算法的共享秘密对称签名。但是，JWT 和 SAML Token可以使用 X.509证书形式的公钥/私钥对进行签名。与签名 JSON 的简单性相比，使用 XML 数字签名,签名 XML 而不引入模糊的安全漏洞是非常困难的。
JSON 解析器在大多数编程语言中都很常见，因为它们直接映射到对象。相反，XML 没有自然的文档到对象映射。这使得使用 JWT 比使用 SAML 断言更容易。
关于使用，JWT 是在 Internet 规模上使用的。这突出了在多个平台(尤其是移动平台)上对 JSON Web 令牌进行客户端处理的便利性。