欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

java實現(xiàn)認(rèn)證與授權(quán)的jwt與token+redis,哪種方案更好用?

 更新時間:2025年09月27日 14:57:01   作者:程序員小2  
JWT(JSON Web Token)與Token+Redis是兩種常見的用戶認(rèn)證方案,它們在設(shè)計原理、性能和安全特性上存在顯著差異,JWT為無狀態(tài)認(rèn)證,適合分布式系統(tǒng)但無法主動失效;Token+Redis依賴Redis存儲會話,支持實時吊銷但運維復(fù)雜,兩者各有優(yōu)劣

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)

在深入討論之前,我們先明確兩個基本概念:

  1. 認(rèn)證(Authentication):你是誰?驗證用戶身份的過程
  2. 授權(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)點:

  1. 無狀態(tài):服務(wù)端不需要存儲會話信息
  2. 跨域友好:適合分布式系統(tǒng)和微服務(wù)架構(gòu)
  3. 自包含:令牌中包含所有必要信息
  4. 擴(kuò)展性好:可以輕松添加自定義聲明

缺點:

  1. 無法主動失效:一旦簽發(fā),在到期前一直有效
  2. 令牌大小:包含的信息越多,令牌越大
  3. 安全性依賴:完全依賴簽名,密鑰泄露后果嚴(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)點:

  1. 主動控制:可以隨時使特定令牌失效
  2. 信息量小:令牌只是一個標(biāo)識符,不會太大
  3. 靈活性高:可以存儲復(fù)雜的會話狀態(tài)
  4. 安全性好:令牌泄露可以立即撤銷

缺點:

  1. 有狀態(tài):服務(wù)端需要存儲會話信息
  2. Redis依賴:Redis成為單點故障源
  3. 網(wǎng)絡(luò)開銷:每次請求都需要查詢Redis
  4. 擴(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安全性考慮:

  1. 密鑰管理:簽名密鑰需要嚴(yán)格保護(hù),定期輪換
  2. 令牌泄露:無法主動失效,只能等待自動過期
  3. 算法選擇:需要選擇安全的簽名算法(如HS256、RS256)

Token+Redis安全性考慮:

  1. Redis安全:需要保證Redis實例的安全性
  2. 令牌隨機(jī)性:令牌必須足夠隨機(jī),防止猜測
  3. 傳輸安全:需要HTTPS防止令牌被竊聽

4.3 適用場景對比

不同的業(yè)務(wù)場景適合不同的方案:

適合JWT的場景:

  1. 分布式系統(tǒng)和微服務(wù)架構(gòu)
  2. 需要跨域認(rèn)證的單頁應(yīng)用(SPA)
  3. 無狀態(tài)API服務(wù)
  4. 移動應(yīng)用后端

適合Token+Redis的場景:

  1. 需要精細(xì)控制會話的企業(yè)應(yīng)用
  2. 需要實時吊銷權(quán)限的系統(tǒng)
  3. 會話信息復(fù)雜的傳統(tǒng)Web應(yīng)用
  4. 對安全性要求極高的金融系統(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)以下情況成立時:

  1. 系統(tǒng)是分布式架構(gòu),需要無狀態(tài)認(rèn)證。
  2. 需要支持跨域認(rèn)證(如多個前端應(yīng)用共享后端)。
  3. API消費者主要是第三方應(yīng)用或移動端。
  4. 團(tuán)隊有能力管理好密鑰和令牌安全。

6.2 選擇Token+Redis當(dāng)以下情況成立時:

  1. 系統(tǒng)是單體或少量服務(wù)的架構(gòu)。
  2. 需要精細(xì)的會話控制和實時權(quán)限管理。
  3. 有專業(yè)的運維團(tuán)隊維護(hù)Redis集群。
  4. 對安全性要求極高,需要即時吊銷能力。

6.3 選擇混合方案當(dāng)以下情況成立時:

  1. 既需要JWT的無狀態(tài)特性,又需要主動注銷能力。
  2. 系統(tǒng)對用戶體驗要求高(避免頻繁登錄)。
  3. 有能力處理稍復(fù)雜的令牌管理邏輯。
  4. 需要平衡安全性和便利性。

總結(jié)

通過上面的詳細(xì)分析,JWT和token+redis這兩種方案,各有優(yōu)缺點和適用場景。

我們可以得出以下結(jié)論:

  1. 沒有絕對的最好方案:只有最適合具體業(yè)務(wù)場景的方案。
  2. JWT優(yōu)勢在無狀態(tài)和擴(kuò)展性:適合分布式系統(tǒng)和API優(yōu)先的架構(gòu)。
  3. Token+Redis優(yōu)勢在控制和靈活性:適合需要精細(xì)會話管理的企業(yè)應(yīng)用。
  4. 混合方案取長補短:適合大多數(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)文章希望大家以后多多支持腳本之家!

相關(guān)文章

  • Java forEach對原數(shù)組的操作過程

    Java forEach對原數(shù)組的操作過程

    forEach對于基本數(shù)據(jù)類型,是直接賦值,對于引用數(shù)據(jù)類型,是引用地址值,forEach遍歷時,是創(chuàng)建的臨時變量,引用的數(shù)據(jù)地址,本文給大家介紹Java forEach對原數(shù)組的操作過程,感興趣的朋友一起看看吧
    2024-02-02
  • MyBatis處理枚舉類型的方法詳解

    MyBatis處理枚舉類型的方法詳解

    MyBatis 處理枚舉類型的機(jī)制相對直接,它提供了一種靈活的方式來處理Java枚舉(enum)類型和數(shù)據(jù)庫之間的映射,本文給大家介紹了MyBatis處理枚舉類型的兩種方法,需要的朋友可以參考下
    2024-07-07
  • java利用JEXL實現(xiàn)動態(tài)表達(dá)式編譯

    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+Mybatis Plus導(dǎo)致PageHelper失效的解決方法

    在Springboot項目中使用分頁插件的時候,發(fā)現(xiàn)PageHelper插件失效了 ,本文主要介紹了SpringBoot+Mybatis Plus導(dǎo)致PageHelper失效的解決方法,感興趣的可以了解一下
    2024-07-07
  • java super關(guān)鍵字知識點詳解

    java super關(guān)鍵字知識點詳解

    在本篇文章里小編給大家整理的是一篇關(guān)于java super關(guān)鍵字知識點詳解內(nèi)容,有興趣的朋友們可以參考下。
    2021-01-01
  • java 愷撒加密/解密實現(xiàn)原理(附帶源碼)

    java 愷撒加密/解密實現(xiàn)原理(附帶源碼)

    本文介紹Java實現(xiàn)愷撒加密與解密,通過固定位移量對字母進(jìn)行循環(huán)替換,保留大小寫及非字母字符,由于其實現(xiàn)簡單、易于理解,愷撒加密常被用作學(xué)習(xí)加密算法的入門案例,感興趣的朋友一起看看吧
    2025-08-08
  • Spring Boot 常用注解詳解與使用最佳實踐建議

    Spring Boot 常用注解詳解與使用最佳實踐建議

    這篇文章主要介紹了Spring Boot 常用注解詳解與使用最佳實踐建議,本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友參考下吧
    2025-05-05
  • 解決jpa查詢語句自動變成了update的問題

    解決jpa查詢語句自動變成了update的問題

    這篇文章主要介紹了解決jpa查詢語句自動變成了update的問題,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教
    2021-08-08
  • 在Spring Boot中實現(xiàn)文件上傳與管理的操作

    在Spring Boot中實現(xiàn)文件上傳與管理的操作

    在 Spring Boot 中實現(xiàn)文件上傳與管理非常簡單,通過配置文件上傳、創(chuàng)建文件上傳、下載、列表和刪除接口,我們可以輕松地處理文件操作,結(jié)合前端頁面,可以提供一個完整的文件管理系統(tǒng),這篇文章主要介紹了在Spring Boot中實現(xiàn)文件上傳與管理,需要的朋友可以參考下
    2024-07-07
  • Java中的自旋鎖與阻塞鎖詳解

    Java中的自旋鎖與阻塞鎖詳解

    這篇文章主要介紹了Java中的自旋鎖與阻塞鎖詳解,阻塞鎖是指當(dāng)線程嘗試獲取鎖失敗時,線程進(jìn)入阻塞狀態(tài),直到接收信號后被喚醒,阻塞或者喚醒一個Java線程需要操作系統(tǒng)切換CPU?狀態(tài)來完成,這種狀態(tài)轉(zhuǎn)換?需要耗費處理器時間,需要的朋友可以參考下
    2023-10-10

最新評論