基于session认证所显露的问题:
Session:
每个用户经过我们的应用认证之后,我们的应用都要在服务端做一次记录,以方便用户下次请求的鉴别,通常而言session都是保存在内存中,而随着认证用户的增多,服务端的开销会明显增大。
扩展性:
用户认证之后,服务端做认证记录,如果认证的记录被保存在内存中的话,这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源,这样在分布式的应用上,相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。
CSRF:
因为是基于cookie来进行用户识别的, cookie如果被截获,用户就会很容易受到跨站请求伪造的攻击。
1.0.2、基于传统token的认证
传统的Token,例如:用户登录成功生成对应的令牌,key为令牌 value:userid,隐藏了数据真实性 ,同时将该token存放到redis中,返回对应的真实令牌给客户端存放。
客户端每次访问后端请求的时候,会传递该token在请求中,服务器端接收到该token之后,从redis中查询如果存在的情况下,则说明在有效期内,如果在Redis中不存在的情况下,则说明过期或者token错误。
1.1. JWT是什么
JSON Web Token (JWT)是一个开放标准(RFC 7519),它定义了一种紧凑的、自包含的方式,用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任,因为它是数字签名的。
是目前流行的
跨域认证解决方案
,一种基于JSON的、用于在网络上声明某种主张的令牌(token)。
该token被设计为紧凑且安全的,特别适用于
分布式站点的单点登录(SSO)
场景。
JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被加密。
原理:jwt验证方式是将用户信息通过加密生成token,每次请求服务端只需要使用保存的密钥验证token的正确性,不用再保存任何session数据了,进而服务端变得无状态,容易实现拓展。
官网:
https://jwt.io/
1.2. 什么时候你应该用JWT
下列场景中使用JSON Web Token是很有用的:
Authorization
(授权) : 这是使用JWT的最常见场景。一旦用户登录,后续每个请求都将包含JWT,允许用户访问该令牌允许的路由、服务和资源。
单点登录
是现在广泛使用的JWT的一个特性,因为它的开销很小,并且可以轻松地
跨域
使用。
Information Exchange
(信息交换) : 对于安全的在各方之间传输信息而言,JSON Web Tokens无疑是一种很好的方式。因为JWTs可以被签名,例如,用公钥/私钥对,你可以确定发送人就是它们所说的那个人。另外,由于签名是使用头和有效负载计算的,您还可以验证内容没有被篡改。
1.3.2、Payload装载
JWT的第二部分是payload,它包含声明(要求)。声明是关于实体(通常是用户)和其他数据的声明。声明有三种类型: registered, public 和 private。
Registered claims : 这里有一组预定义的声明,它们不是强制的,但是推荐。比如:iss (issuer), exp (expiration time), sub (subject), aud (audience)等。
iss (issuer):签发人
exp (expiration time):过期时间
sub (subject):主题
aud (audience):受众
nbf (Not Before):生效时间
iat (Issued At):签发时间
jti (JWT ID):编号
注意,不要在JWT的payload或header中放置敏感信息,除非它们是加密的。
1.3.3、Signature签名
为了得到签名部分,你必须有编码过的header、编码过的payload、一个秘钥,签名算法是header中指定的那个,然对它们签名即可。
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
签名是用于验证消息在传递过程中有没有被更改,并且,对于使用私钥签名的token,它还可以验证JWT的发送方是否为它所称的发送方。
看一张官网的图就明白了:
1.4. JWT是如何工作的
在认证的时候,当用户用他们的凭证成功登录以后,一个JSON Web Token将会被返回。此后,token就是用户凭证了,你必须非常小心以防止出现安全问题。一般而言,你保存令牌的时候不应该超过你所需要它的时间。
无论何时用户想要访问受保护的路由或者资源的时候,用户代理(通常是浏览器)都应该带上JWT,典型的,通常放在Authorization header中,用Bearer schema。
header应该看起来是这样的:
Authorization: Bearer <token>
服务器上的受保护的路由将会检查Authorization header中的JWT是否有效,如果有效,则用户可以访问受保护的资源。如果JWT包含足够多的必需的数据,那么就可以减少对某些操作的数据库查询的需要,尽管可能并不总是如此。
如果token是在授权头(Authorization header)中发送的,那么跨源资源共享(CORS)将不会成为问题,因为它不使用cookie。
下面这张图显示了如何获取JWT以及使用它来访问APIs或者资源:
应用(或者客户端)想授权服务器请求授权。例如,如果用授权码流程的话,就是/oauth/authorize
当授权被许可以后,授权服务器返回一个access token给应用
应用使用access token访问受保护的资源(比如:API)
1.5. 基于Token的身份认证 与 基于服务器的身份认证
1.5.1. 基于服务器的身份认证
在讨论基于Token的身份认证是如何工作的以及它的好处之前,我们先来看一下以前我们是怎么做的:
HTTP协议是无状态的,也就是说,如果我们已经认证了一个用户,那么他下一次请求的时候,服务器不知道我是谁,我们必须再次认证
传统的做法是将已经认证过的用户信息存储在服务器上,比如Session。用户下次请求的时候带着Session ID,然后服务器以此检查用户是否认证过。
这种基于服务器的身份认证方式存在一些问题:
Sessions : 每次用户认证通过以后,服务器需要创建一条记录保存用户信息,通常是在内存中,随着认证通过的用户越来越多,服务器的在这里的开销就会越来越大。
Scalability : 由于Session是在内存中的,这就带来一些扩展性的问题。
CORS : 当我们想要扩展我们的应用,让我们的数据被多个移动设备使用时,我们必须考虑跨资源共享问题。当使用AJAX调用从另一个域名下获取资源时,我们可能会遇到禁止请求的问题。
CSRF : 用户很容易受到CSRF攻击。
1.5.2. JWT与Session的差异
相同点是,它们都是存储用户信息;然而,Session是在服务器端的,而JWT是在客户端的。
Session方式存储用户信息的最大问题在于要占用大量服务器内存,增加服务器的开销。
而JWT方式将用户状态分散到了客户端中,可以明显减轻服务端的内存压力。
Session的状态是存储在服务器端,客户端只有session id;而Token的状态是存储在客户端。
1.5.3. 基于Token的身份认证是如何工作的
基于Token的身份认证是无状态的,服务器或者Session中不会存储任何用户信息。
没有会话信息意味着应用程序可以根据需要扩展和添加更多的机器,而不必担心用户登录的位置。
虽然这一实现可能会有所不同,但其主要流程如下:
用户携带用户名和密码请求访问
服务器校验用户凭据
应用提供一个token给客户端
客户端存储token,并且在随后的每一次请求中都带着它
服务器校验token并返回数据
每一次请求都需要token
Token应该放在请求header中
我们还需要将服务器设置为接受来自所有域的请求,用Access-Control-Allow-Origin: *
1.5.4. 用Token的好处
无状态和可扩展性:Tokens存储在客户端。完全无状态,可扩展。我们的负载均衡器可以将用户传递到任意服务器,因为在任何地方都没有状态或会话信息。
安全:Token不是Cookie。(The token, not a cookie.)每次请求的时候Token都会被发送。而且,由于没有Cookie被发送,还有助于防止CSRF攻击。即使在你的实现中将token存储到客户端的Cookie中,这个Cookie也只是一种存储机制,而非身份认证机制。没有基于会话的信息可以操作,因为我们没有会话!
还有一点,token在一段时间以后会过期,这个时候用户需要重新登录。这有助于我们保持安全。还有一个概念叫token撤销,它允许我们根据相同的授权许可使特定的token甚至一组token无效。
1.5.5. JWT与OAuth的区别
OAuth2是一种授权框架 ,JWT是一种认证协议
无论使用哪种方式切记用HTTPS来保证数据的安全性
OAuth2用在使用第三方账号登录的情况(比如使用weibo, qq, github登录某个app),而
JWT是用在前后端分离
, 需要简单的对后台API进行保护时使用。
1.5.6. 关于OAuth可以参考下面几篇
《
OAuth 2.0
》
《
Spring Security OAuth 2.0
》
《
OAuth 2.0 授权码请求
》
1.6. 参考
https://jwt.io/
https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication#toc-why-tokens-came-around
https://tools.ietf.org/html/rfc7519#section-3
http://blog.leapoahead.com/2015/09/06/understanding-jwt/
https://cnodejs.org/topic/557844a8e3cc2f192486a8ff
http://blog.leapoahead.com/2015/09/07/user-authentication-with-jwt/
二、JJWT实现
2.1、概要
JJWT是一个提供端到端的JWT创建和验证的Java库。永远免费和开源(Apache License,版本2.0),JJWT很容易使用和理解。它被设计成一个以建筑为中心的流畅界面,隐藏了它的大部分复杂性。
JJWT的目标是最容易使用和理解用于在JVM上创建和验证JSON Web令牌(JWTs)的库。
JJWT是基于JWT、JWS、JWE、JWK和JWA RFC规范的Java实现。
JJWT还添加了一些不属于规范的便利扩展,比如JWT压缩和索赔强制。
源码:
https://github.com/jwtk/jjwt
2.2、规范兼容
创建和解析明文压缩JWTs
创建、解析和验证所有标准JWS算法的数字签名紧凑JWTs(又称JWSs):
HS256: HMAC using SHA-256
HS384: HMAC using SHA-384
HS512: HMAC using SHA-512
RS256: RSASSA-PKCS-v1_5 using SHA-256
RS384: RSASSA-PKCS-v1_5 using SHA-384
RS512: RSASSA-PKCS-v1_5 using SHA-512
PS256: RSASSA-PSS using SHA-256 and MGF1 with SHA-256
PS384: RSASSA-PSS using SHA-384 and MGF1 with SHA-384
PS512: RSASSA-PSS using SHA-512 and MGF1 with SHA-512
ES256: ECDSA using P-256 and SHA-256
ES384: ECDSA using P-384 and SHA-384
ES512: ECDSA using P-521 and SHA-512
2.3、添加依赖
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt-api</artifactId>
<version>0.11.5</version>
</dependency>
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt-impl</artifactId>
<version>0.11.5</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt-jackson</artifactId> <!-- or jjwt-gson if Gson is preferred -->
<version>0.11.5</version>
<scope>runtime</scope>
</dependency>
<!-- Uncomment this next dependency if you are using JDK 10 or earlier and you also want to use
RSASSA-PSS (PS256, PS384, PS512) algorithms. JDK 11 or later does not require it for those algorithms:
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk15on</artifactId>
<version>1.70</version>
<scope>runtime</scope>
</dependency>
如果您使用的是JDK 10或更早版本,并且还希望使用RSASSA-PSS(PS256、PS384、PS512)算法。JDK 11或更高版本不需要这些算法,需要依赖bcprov-jdk15on。
2.4、生成JWT
package com.myproject.studentmis4;
import io.jsonwebtoken.*;
import io.jsonwebtoken.io.Decoders;
import io.jsonwebtoken.io.Encoders;
import io.jsonwebtoken.security.Keys;
import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;
import javax.crypto.SecretKey;
import java.nio.charset.StandardCharsets;
import java.security.Key;
import java.util.Date;
import java.util.UUID;
@SpringBootTest
public class JWTTest {
//过期毫秒时长
public static final long Expiration=24*60*60*1000;
//密钥
private static final String secretString="Zd+kZozTI5OgURtbegh8E6KTPghNNe/tEFwuLxd2UNw=";
//生成安全密钥
private static final SecretKey KEY = Keys.hmacShaKeyFor(Decoders.BASE64.decode(secretString));
/**生成密钥*/
@Test
public void genKey(){
Key key = Keys.secretKeyFor(SignatureAlgorithm.HS256);
String secretString = Encoders.BASE64.encode(key.getEncoded());
System.out.println(secretString);
@Test
public void creatJWT(){
//创建一个Jwt构造器
JwtBuilder builder = Jwts.builder();
//设置签发时间
builder.setIssuedAt(new Date());
//设置过期时间
builder.setExpiration(new Date(System.currentTimeMillis()+Expiration));
//设置Id
builder.setId(UUID.randomUUID().toString());
//设置主题
builder.setSubject("auth");
//设置自定义信息
builder.claim("username","zhangsan");
builder.claim("role","admin");
//设置签名
builder.signWith(KEY);
//生成token字符串
String token=builder.compact();
System.out.println(token);
运行结果:
eyJhbGciOiJIUzI1NiJ9.eyJpYXQiOjE2Njg2NDQ0MjksImV4cCI6MTY2ODczMDgyOSwianRpIjoiYTQ4NjJiNWYtZTg3NS00ZGQ5LTg1M2ItZTJmZjAyY2Y1NDViIiwic3ViIjoiYXV0aCIsInVzZXJuYW1lIjoiemhhbmdzYW4iLCJyb2xlIjoiYWRtaW4ifQ.VlEr3LZNc941vugUU8Cvxh5DX7h6rL1T3WSVZA81080
自定义密钥
您的密钥字符串是 Base64 编码的吗?如果是这样,请执行以下操作:
@Value("${jwt.token.secret}")
private String secret;
private Key getSigningKey() {
byte[] keyBytes = Decoders.BASE64.decode(this.secret);
return Keys.hmacShaKeyFor(keyBytes);
JwtToken.builder().value(Jwts.builder()
.setClaims(createClaims(account))
.setSubject(subject.toString())
.setIssuedAt(Date.from(createdDateTime))
.setExpiration(Date.from(expirationDateTime))
.signWith(getSigningKey())
.compact()).expiration(expirationDateTime.toString()).build()
如果您的密钥不是 base64 编码的(它可能应该是,因为例如,如果您使用原始密码,您的密钥可能不正确或格式不正确),您可以通过以下方式执行此操作:
private Key getSigningKey() {
byte[] keyBytes = this.secret.getBytes(StandardCharsets.UTF_8);
return Keys.hmacShaKeyFor(keyBytes);
但是,通常不建议使用第二个示例,因为这可能意味着您的密钥格式不佳。格式良好的安全随机密钥不是人类可读的,因此要将其存储为字符串,密钥字节通常首先进行 base64 编码。
从文档https://github.com/jwtk/jjwt#jws-key-create:
如果要生成足够强的 SecretKey 以用于 JWT HMAC-SHA 算法,请使用Keys.secretKeyFor(SignatureAlgorithm)
辅助方法:
SecretKey key = Keys.secretKeyFor(SignatureAlgorithm.HS256);