java實現(xiàn)認(rèn)證與授權(quán)的jwt與token+redis,哪種方案更好用?
JWT(JSON Web Token)與Token+Redis是兩種常見的用戶認(rèn)證方案,它們在設(shè)計原理、性能和安全特性上存在顯著差異。JWT為無狀態(tài)認(rèn)證,適合分布式系統(tǒng)但無法主動失效;Token+Redis依賴Redis存儲會話,支持實時吊銷但運維復(fù)雜,兩者各有優(yōu)劣,混合方案結(jié)合短期JWT與Redis黑名單實現(xiàn)安全與便利平衡,推薦根據(jù)業(yè)務(wù)場景靈活選擇。
一、認(rèn)證與授權(quán)
在深入討論之前,我們先明確兩個基本概念:
- 認(rèn)證(Authentication):你是誰?驗證用戶身份的過程
- 授權(quán)(Authorization):你能做什么?驗證用戶權(quán)限的過程
無論是JWT還是Token+Redis,都是用來解決這兩個問題的技術(shù)方案。

二、JWT方案
2.1 JWT是什么?
JWT是一種無狀態(tài)的身份驗證機(jī)制,通過將用戶信息編碼在令牌中實現(xiàn)驗證。其核心優(yōu)勢在于分布式友好和性能高,適合微服務(wù)架構(gòu)和跨域SSO場景。但由于無法主動失效Token,存在信息泄露風(fēng)險,且權(quán)限更新需要重新生成Token。
JWT(JSON Web Token)是一種開放標(biāo)準(zhǔn)(RFC 7519),用于在各方之間安全地傳輸信息作為JSON對象。JWT由三部分組成:
header.payload.signature
- Header:包含令牌類型和簽名算法
- Payload:包含聲明(用戶信息、過期時間等)
- Signature:用于驗證消息在傳輸過程中沒有被篡改
2.2 JWT的工作流程
讓我們通過一個完整的登錄流程來理解JWT的工作原理:

2.3 JWT的Java實現(xiàn)示例
下面是一個簡單的JWT工具類實現(xiàn):
import io.jsonwebtoken.*;
import io.jsonwebtoken.security.Keys;
import java.security.Key;
import java.util.Date;
public class JwtUtil {
// 密鑰,實際項目中應(yīng)從配置中讀取
private static final Key key = Keys.secretKeyFor(SignatureAlgorithm.HS256);
// 過期時間:2小時
private static final long EXPIRATION_TIME = 2 * 60 * 60 * 1000;
/**
* 生成JWT
*/
public static String generateToken(String userId, String username, List<String> roles) {
return Jwts.builder()
.setSubject(userId)
.claim("username", username)
.claim("roles", roles)
.setIssuedAt(new Date())
.setExpiration(new Date(System.currentTimeMillis() + EXPIRATION_TIME))
.signWith(key)
.compact();
}
/**
* 驗證并解析JWT
*/
public static Claims parseToken(String token) {
try {
return Jwts.parserBuilder()
.setSigningKey(key)
.build()
.parseClaimsJws(token)
.getBody();
} catch (ExpiredJwtException e) {
thrownew RuntimeException("Token已過期", e);
} catch (JwtException e) {
thrownew RuntimeException("Token無效", e);
}
}
/**
* 刷新Token
*/
public static String refreshToken(String token) {
Claims claims = parseToken(token);
return generateToken(claims.getSubject(),
claims.get("username", String.class),
claims.get("roles", List.class));
}
}2.4 JWT的優(yōu)點和缺點
優(yōu)點:
- 無狀態(tài):服務(wù)端不需要存儲會話信息
- 跨域友好:適合分布式系統(tǒng)和微服務(wù)架構(gòu)
- 自包含:令牌中包含所有必要信息
- 擴(kuò)展性好:可以輕松添加自定義聲明
缺點:
- 無法主動失效:一旦簽發(fā),在到期前一直有效
- 令牌大小:包含的信息越多,令牌越大
- 安全性依賴:完全依賴簽名,密鑰泄露后果嚴(yán)重
三、Token+Redis方案
3.1 Token+Redis是什么?
該方案通過Redis集中存儲會話信息,具有完全控制會話和動態(tài)權(quán)限管理的優(yōu)勢,可實時吊銷Token或綁定設(shè)備屬性增強安全性。但性能依賴Redis集群,運維復(fù)雜度較高。實現(xiàn)時通常將生成的Token存入Redis并設(shè)置過期時間,結(jié)合攔截器進(jìn)行雙重驗證(簽名校驗和Redis查詢)。
Token+Redis方案使用隨機(jī)生成的令牌作為用戶會話的標(biāo)識,將會話數(shù)據(jù)存儲在Redis中。
這種方案本質(zhì)上是有狀態(tài)的,服務(wù)端需要維護(hù)會話狀態(tài)。
3.2 Token+Redis的工作流程

3.3 Token+Redis的Java實現(xiàn)示例
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Component;
import java.util.UUID;
import java.util.concurrent.TimeUnit;
@Component
public class RedisSessionManager {
private final RedisTemplate<String, Object> redisTemplate;
// 會話過期時間:2小時
private static final long SESSION_EXPIRE_TIME = 2 * 60 * 60;
public RedisSessionManager(RedisTemplate<String, Object> redisTemplate) {
this.redisTemplate = redisTemplate;
}
/**
* 創(chuàng)建會話
*/
public String createSession(User user) {
String token = generateToken();
SessionInfo sessionInfo = new SessionInfo(user.getId(), user.getUsername(), user.getRoles());
redisTemplate.opsForValue().set(
getRedisKey(token),
sessionInfo,
SESSION_EXPIRE_TIME,
TimeUnit.SECONDS
);
return token;
}
/**
* 獲取會話信息
*/
public SessionInfo getSession(String token) {
return (SessionInfo) redisTemplate.opsForValue().get(getRedisKey(token));
}
/**
* 刪除會話
*/
public void deleteSession(String token) {
redisTemplate.delete(getRedisKey(token));
}
/**
* 刷新會話有效期
*/
public void refreshSession(String token) {
redisTemplate.expire(getRedisKey(token), SESSION_EXPIRE_TIME, TimeUnit.SECONDS);
}
/**
* 生成隨機(jī)token
*/
private String generateToken() {
return UUID.randomUUID().toString().replace("-", "");
}
/**
* 獲取Redis key
*/
private String getRedisKey(String token) {
return "session:" + token;
}
/**
* 會話信息類
*/
@Data
@AllArgsConstructor
public static class SessionInfo {
private String userId;
private String username;
private List<String> roles;
private long createTime;
public SessionInfo(String userId, String username, List<String> roles) {
this.userId = userId;
this.username = username;
this.roles = roles;
this.createTime = System.currentTimeMillis();
}
}
}3.4 Token+Redis的優(yōu)點和缺點
優(yōu)點:
- 主動控制:可以隨時使特定令牌失效
- 信息量小:令牌只是一個標(biāo)識符,不會太大
- 靈活性高:可以存儲復(fù)雜的會話狀態(tài)
- 安全性好:令牌泄露可以立即撤銷
缺點:
- 有狀態(tài):服務(wù)端需要存儲會話信息
- Redis依賴:Redis成為單點故障源
- 網(wǎng)絡(luò)開銷:每次請求都需要查詢Redis
- 擴(kuò)展性挑戰(zhàn):需要處理Redis集群和數(shù)據(jù)同步
四、深度對比分析
4.1 性能對比
從性能角度,兩種方案有顯著差異:
方面 | JWT | Token+Redis |
認(rèn)證速度 | 快(本地驗證) | 慢(需要Redis查詢) |
網(wǎng)絡(luò)開銷 | 小 | 大(每次請求都需要訪問Redis) |
服務(wù)端壓力 | 小 | 大(Redis需要處理大量查詢) |
擴(kuò)展成本 | 低 | 高(需要維護(hù)Redis集群) |
4.2 安全性對比
安全性是認(rèn)證方案的核心考量因素:
JWT安全性考慮:
- 密鑰管理:簽名密鑰需要嚴(yán)格保護(hù),定期輪換
- 令牌泄露:無法主動失效,只能等待自動過期
- 算法選擇:需要選擇安全的簽名算法(如HS256、RS256)
Token+Redis安全性考慮:
- Redis安全:需要保證Redis實例的安全性
- 令牌隨機(jī)性:令牌必須足夠隨機(jī),防止猜測
- 傳輸安全:需要HTTPS防止令牌被竊聽
4.3 適用場景對比
不同的業(yè)務(wù)場景適合不同的方案:
適合JWT的場景:
- 分布式系統(tǒng)和微服務(wù)架構(gòu)
- 需要跨域認(rèn)證的單頁應(yīng)用(SPA)
- 無狀態(tài)API服務(wù)
- 移動應(yīng)用后端
適合Token+Redis的場景:
- 需要精細(xì)控制會話的企業(yè)應(yīng)用
- 需要實時吊銷權(quán)限的系統(tǒng)
- 會話信息復(fù)雜的傳統(tǒng)Web應(yīng)用
- 對安全性要求極高的金融系統(tǒng)
五、混合方案
有些小伙伴在工作中可能會想:能不能結(jié)合兩種方案的優(yōu)點?
答案是肯定的!
下面介紹一種混合方案:
5.1 短期JWT + Redis黑名單
這種方案使用短期有效的JWT,配合Redis黑名單實現(xiàn)主動注銷:
public class HybridAuthManager {
private final JwtUtil jwtUtil;
private final RedisTemplate<String, Object> redisTemplate;
// JWT短期有效期:15分鐘
private static final long SHORT_EXPIRATION = 15 * 60 * 1000;
// 刷新令牌有效期:7天
private static final long REFRESH_EXPIRATION = 7 * 24 * 60 * 60 * 1000;
/**
* 生成訪問令牌和刷新令牌
*/
public AuthResponse generateTokenPair(User user) {
// 生成短期訪問令牌
String accessToken = jwtUtil.generateToken(
user.getId(), user.getUsername(), user.getRoles(), SHORT_EXPIRATION);
// 生成長期刷新令牌
String refreshToken = UUID.randomUUID().toString();
// 存儲刷新令牌到Redis
storeRefreshToken(refreshToken, user.getId());
returnnew AuthResponse(accessToken, refreshToken);
}
/**
* 刷新訪問令牌
*/
public String refreshAccessToken(String refreshToken) {
// 驗證刷新令牌有效性
String userId = validateRefreshToken(refreshToken);
if (userId == null) {
thrownew RuntimeException("刷新令牌無效");
}
// 獲取用戶信息
User user = userService.getUserById(userId);
// 生成新的訪問令牌
return jwtUtil.generateToken(
user.getId(), user.getUsername(), user.getRoles(), SHORT_EXPIRATION);
}
/**
* 注銷令牌
*/
public void logout(String accessToken, String refreshToken) {
// 將訪問令牌加入黑名單(剩余有效期內(nèi))
Claims claims = jwtUtil.parseToken(accessToken);
long expiration = claims.getExpiration().getTime() - System.currentTimeMillis();
if (expiration > 0) {
redisTemplate.opsForValue().set(
"blacklist:" + accessToken,
"logout",
expiration,
TimeUnit.MILLISECONDS
);
}
// 刪除刷新令牌
if (refreshToken != null) {
redisTemplate.delete("refresh_token:" + refreshToken);
}
}
/**
* 驗證令牌是否在黑名單中
*/
public boolean isTokenBlacklisted(String token) {
return redisTemplate.hasKey("blacklist:" + token);
}
}5.2 混合方案工作流程

六、實際項目選型建議
根據(jù)我多年的工作經(jīng)驗,給大家一些實用的選型建議:
6.1 選擇JWT當(dāng)以下情況成立時:
- 系統(tǒng)是分布式架構(gòu),需要無狀態(tài)認(rèn)證。
- 需要支持跨域認(rèn)證(如多個前端應(yīng)用共享后端)。
- API消費者主要是第三方應(yīng)用或移動端。
- 團(tuán)隊有能力管理好密鑰和令牌安全。
6.2 選擇Token+Redis當(dāng)以下情況成立時:
- 系統(tǒng)是單體或少量服務(wù)的架構(gòu)。
- 需要精細(xì)的會話控制和實時權(quán)限管理。
- 有專業(yè)的運維團(tuán)隊維護(hù)Redis集群。
- 對安全性要求極高,需要即時吊銷能力。
6.3 選擇混合方案當(dāng)以下情況成立時:
- 既需要JWT的無狀態(tài)特性,又需要主動注銷能力。
- 系統(tǒng)對用戶體驗要求高(避免頻繁登錄)。
- 有能力處理稍復(fù)雜的令牌管理邏輯。
- 需要平衡安全性和便利性。
總結(jié)
通過上面的詳細(xì)分析,JWT和token+redis這兩種方案,各有優(yōu)缺點和適用場景。
我們可以得出以下結(jié)論:
- 沒有絕對的最好方案:只有最適合具體業(yè)務(wù)場景的方案。
- JWT優(yōu)勢在無狀態(tài)和擴(kuò)展性:適合分布式系統(tǒng)和API優(yōu)先的架構(gòu)。
- Token+Redis優(yōu)勢在控制和靈活性:適合需要精細(xì)會話管理的企業(yè)應(yīng)用。
- 混合方案取長補短:適合大多數(shù)現(xiàn)代Web應(yīng)用。
有些小伙伴在工作中可能會盲目追求技術(shù)的新穎性,或者過度設(shè)計認(rèn)證方案。
我的建議是:從實際業(yè)務(wù)需求出發(fā),選擇最簡單可靠的方案。
對于大多數(shù)應(yīng)用來說,我推薦采用混合方案:
- 使用短期JWT保證API的無狀態(tài)特性。
- 使用刷新令牌機(jī)制優(yōu)化用戶體驗。
- 使用Redis黑名單提供主動注銷能力。
- 使用HTTPS和嚴(yán)格的密鑰管理保證安全性。
無論選擇哪種方案,都要記?。喊踩皇且粋€功能,而是一個過程。
到此這篇關(guān)于java實現(xiàn)認(rèn)證與授權(quán)的jwt與token+redis,哪種方案更好用?的文章就介紹到這了,更多相關(guān)java實現(xiàn)認(rèn)證與授權(quán)的jwt與token+redis內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
- 如何使用jwt+redis實現(xiàn)單點登錄
- 使用Redis實現(xiàn)JWT令牌主動失效機(jī)制
- SpringSecurity+Redis+Jwt實現(xiàn)用戶認(rèn)證授權(quán)
- Shiro整合Springboot和redis,jwt過程中的錯誤shiroFilterChainDefinition問題
- jwt+redis實現(xiàn)登錄認(rèn)證的示例代碼
- 基于 Redis 的 JWT令牌失效處理方案(實現(xiàn)步驟)
- springboot+springsecurity+mybatis+JWT+Redis?實現(xiàn)前后端離實戰(zhàn)教程
- SpringBoot整合SpringSecurity和JWT和Redis實現(xiàn)統(tǒng)一鑒權(quán)認(rèn)證
- SpringSecurity+jwt+redis基于數(shù)據(jù)庫登錄認(rèn)證的實現(xiàn)
相關(guān)文章
java利用JEXL實現(xiàn)動態(tài)表達(dá)式編譯
這篇文章主要介紹了java利用JEXL實現(xiàn)動態(tài)表達(dá)式編譯,系統(tǒng)要獲取多個數(shù)據(jù)源的數(shù)據(jù),并進(jìn)行處理,最后輸出多個字段。字段的計算規(guī)則一般是簡單的取值最多加一點條件判斷,下面是具體的實現(xiàn)方法2021-04-04
SpringBoot+Mybatis Plus導(dǎo)致PageHelper失效的解決方法
在Springboot項目中使用分頁插件的時候,發(fā)現(xiàn)PageHelper插件失效了 ,本文主要介紹了SpringBoot+Mybatis Plus導(dǎo)致PageHelper失效的解決方法,感興趣的可以了解一下2024-07-07
在Spring Boot中實現(xiàn)文件上傳與管理的操作
在 Spring Boot 中實現(xiàn)文件上傳與管理非常簡單,通過配置文件上傳、創(chuàng)建文件上傳、下載、列表和刪除接口,我們可以輕松地處理文件操作,結(jié)合前端頁面,可以提供一個完整的文件管理系統(tǒng),這篇文章主要介紹了在Spring Boot中實現(xiàn)文件上傳與管理,需要的朋友可以參考下2024-07-07

