級(jí)登錄全流程設(shè)計(jì)：認(rèn)證授權(quán)、會(huì)話管理與安全防護(hù)實(shí)踐)
1. 從零搭建企業(yè)級(jí)登錄先搞清楚我們?cè)诮鉀Q什么問題登錄這個(gè)功能單看好像就是“輸入賬號(hào)密碼、點(diǎn)一下按鈕”這么簡單但一旦放到企業(yè)級(jí)場(chǎng)景里它立刻變成整個(gè)系統(tǒng)中最敏感、最容易出事故、也最容易被攻擊者盯上的模塊。我見過太多項(xiàng)目在聯(lián)調(diào)階段才發(fā)現(xiàn)登錄流程設(shè)計(jì)得支離破碎有的把會(huì)話狀態(tài)塞進(jìn)本地存儲(chǔ)被腳本一鍋端有的密碼校驗(yàn)邏輯寫得比業(yè)務(wù)代碼還隨意還有的登錄接口被刷到數(shù)據(jù)庫連接池直接打滿。這些問題如果能在動(dòng)手寫代碼之前把整體流程想清楚大部分都能提前規(guī)避。先說清楚一個(gè)概念企業(yè)級(jí)用戶登錄指的是面向企業(yè)內(nèi)部員工、外部合作方、或者大規(guī)模C端用戶的統(tǒng)一身份認(rèn)證入口。它和“小網(wǎng)站搞個(gè)session存一下用戶ID”最大的區(qū)別在于企業(yè)級(jí)登錄要考慮的不只是“怎么驗(yàn)證密碼”還要考慮多端兼容、會(huì)話安全、單點(diǎn)登錄SSO、權(quán)限隔離、審計(jì)追蹤、防暴力破解、高可用部署這樣一整套體系。換句話說登錄不是一個(gè)“功能點(diǎn)”而是一條完整的安全鏈路。這篇文章我會(huì)從方案選型、核心代碼實(shí)現(xiàn)、踩坑記錄、到線上排查技巧完整走一遍企業(yè)級(jí)登錄流程的設(shè)計(jì)與落地。如果你正在做企業(yè)內(nèi)部系統(tǒng)、SaaS平臺(tái)、或者任何對(duì)安全要求比較高的Web應(yīng)用這篇文章應(yīng)該能幫你少走不少彎路。我會(huì)盡量把原理講透代碼部分也會(huì)給到可以直接改改就用的程度。2. 整體方案設(shè)計(jì)為什么我選擇了這套登錄架構(gòu)2.1 核心需求拆解登錄不只是校驗(yàn)密碼動(dòng)手設(shè)計(jì)之前我習(xí)慣先把需求拆成四個(gè)維度認(rèn)證Authentication、授權(quán)Authorization、會(huì)話管理Session Management、審計(jì)Audit。這四個(gè)詞聽起來很像但實(shí)際是四件完全不同的事。認(rèn)證解決的是“你是誰”的問題常見手段就是賬號(hào)密碼、短信驗(yàn)證碼、掃碼登錄、OAuth第三方授權(quán)授權(quán)解決的是“你能干什么”的問題比如登錄之后能訪問哪些菜單、哪些接口會(huì)話管理解決的是“怎么維持登錄狀態(tài)”的問題包括Token怎么發(fā)、怎么存、怎么續(xù)期、怎么失效審計(jì)解決的是“出了問題怎么追溯”的問題包括登錄日志、操作日志、異常行為記錄。很多項(xiàng)目的登錄模塊做得不好根本原因就是把這四個(gè)維度混在了一起。比如有的團(tuán)隊(duì)把用戶的權(quán)限列表直接塞進(jìn)JWT里美其名曰“無狀態(tài)設(shè)計(jì)”結(jié)果權(quán)限一改Token還得等過期才生效有的團(tuán)隊(duì)把會(huì)話存在內(nèi)存里服務(wù)一重啟全部用戶掉線。所以我做方案設(shè)計(jì)的第一步就是先把這四個(gè)維度分開畫清楚再?zèng)Q定每部分用什么技術(shù)承載。2.2 方案選型從Session到JWT再到混合方案登錄會(huì)話方案的主流選項(xiàng)大致有三類傳統(tǒng)Session、純JWT、以及Session JWT混合。我分別說下它們的適用場(chǎng)景和坑。傳統(tǒng)Session方案服務(wù)端把會(huì)話ID種在Cookie里用戶信息存服務(wù)端內(nèi)存或Redis。優(yōu)點(diǎn)是實(shí)現(xiàn)簡單、服務(wù)端可控性強(qiáng)、想踢誰踢誰缺點(diǎn)是分布式環(huán)境下要解決Session共享問題而且Cookie在跨域場(chǎng)景下比較麻煩。這個(gè)方案適合傳統(tǒng)服務(wù)端渲染的Web應(yīng)用比如企業(yè)內(nèi)部管理后臺(tái)。純JWT方案服務(wù)端把用戶信息簽進(jìn)Token里客戶端保存Token每次請(qǐng)求帶上來。優(yōu)點(diǎn)是天然適合前后端分離和移動(dòng)端服務(wù)端不需要存會(huì)話狀態(tài)擴(kuò)展性好缺點(diǎn)是Token沒法主動(dòng)失效除非引入黑名單機(jī)制而且如果往Token里塞太多東西請(qǐng)求頭會(huì)變得很大。這個(gè)方案適合開放API平臺(tái)、多端共用的服務(wù)。我實(shí)際項(xiàng)目里用得最多的是第三種混合方案。登錄成功后簽發(fā)短期JWT作為訪問憑證同時(shí)把刷新令牌Refresh Token存在Redis里有效期設(shè)置得長一些。短期Token過期后客戶端用刷新令牌換新Token。這樣既保留了JWT適合多端、擴(kuò)展性好的優(yōu)點(diǎn)又通過刷新令牌的Redis存儲(chǔ)實(shí)現(xiàn)了“可控的登錄狀態(tài)”——管理員可以刪除Redis里的刷新令牌達(dá)到強(qiáng)制下線效果。提示純JWT不是說不能用但它在企業(yè)級(jí)場(chǎng)景里有一個(gè)很尷尬的問題你沒辦法在服務(wù)端把已經(jīng)發(fā)出的Token作廢。如果遇到安全事件需要緊急踢掉所有在線用戶純JWT方案得靠改密鑰才能實(shí)現(xiàn)那代價(jià)就太大了。2.3 為什么企業(yè)級(jí)登錄必須做“多因子”設(shè)計(jì)我說的多因子不是指一定要上短信或者掃碼而是說至少要有兩層驗(yàn)證邏輯。第一層是“你知道什么”也就是賬號(hào)密碼第二層我建議至少做到“你擁有什么”比如手機(jī)驗(yàn)證碼、或者已經(jīng)綁定過的設(shè)備信息。對(duì)于后臺(tái)管理類系統(tǒng)這一步幾乎是必須的。有一次我負(fù)責(zé)給一個(gè)內(nèi)部運(yùn)營平臺(tái)加登錄功能一開始只做了賬號(hào)密碼上線第二天就有同事反饋說自己密碼被改了。查日志發(fā)現(xiàn)是有人拿弱口令字典在掃登錄接口剛好掃中了幾個(gè)用生日當(dāng)密碼的賬號(hào)。后來我上了登錄失敗次數(shù)限制、密碼復(fù)雜度策略、以及二次驗(yàn)證才把這個(gè)口子堵住。這里的教訓(xùn)是企業(yè)級(jí)系統(tǒng)的登錄入口永遠(yuǎn)默認(rèn)被攻擊者盯著安全設(shè)計(jì)不是“要不要做”的問題而是“怎么做才不拖累體驗(yàn)”的問題。3. 核心代碼實(shí)現(xiàn)一套可以落地的登錄流程3.1 技術(shù)棧說明我用Java技術(shù)棧做示例原因很簡單企業(yè)級(jí)后端項(xiàng)目Java的占比依然很高Spring Boot Spring Security Redis這套組合在業(yè)界非常成熟。但本文講的流程設(shè)計(jì)思路是完全語言無關(guān)的你用Node.js、Python、Go也能對(duì)應(yīng)落地。Spring Boot 2.7.xSpring SecurityJWTjjwt 0.11.5RedisSpring Data RedisMyBatis-Plus用于查詢用戶信息可替換成任何ORM密碼加密BCrypt3.2 表結(jié)構(gòu)設(shè)計(jì)用戶的密碼不該出現(xiàn)在用戶表里先看表結(jié)構(gòu)。很多新手會(huì)直接把密碼字段放在用戶表里這在企業(yè)級(jí)設(shè)計(jì)里是不推薦的。我習(xí)慣把“賬號(hào)信息”和“身份憑證”分開存儲(chǔ)這樣后續(xù)如果需要支持多種登錄方式——密碼登錄、短信登錄、企業(yè)微信掃碼登錄——擴(kuò)展起來不會(huì)動(dòng)用戶主表。-- 用戶基礎(chǔ)表 CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(64) NOT NULL UNIQUE, real_name VARCHAR(64), status TINYINT NOT NULL DEFAULT 1 COMMENT 1:啟用 0:禁用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 用戶憑據(jù)表存密碼、上次修改時(shí)間等信息 CREATE TABLE sys_user_credential ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, credential_type VARCHAR(16) NOT NULL DEFAULT PASSWORD, password_hash VARCHAR(256) NOT NULL, last_reset_time DATETIME, failed_attempts INT DEFAULT 0, lock_until DATETIME, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_user_type (user_id, credential_type) );這兩個(gè)表的關(guān)系是一對(duì)多一個(gè)用戶可以有多種類型的憑證。密碼只存BCrypt加過密的哈希值不存明文這一點(diǎn)沒有任何商量余地。BCrypt是自適應(yīng)哈希算法可以調(diào)節(jié)計(jì)算成本暴力破解的代價(jià)非常高比MD5、SHA-256這類純哈希方案安全很多。3.3 登錄接口實(shí)現(xiàn)從校驗(yàn)到發(fā)Token的完整鏈路登錄接口的核心邏輯分六步我一個(gè)個(gè)拆開講。第一步參數(shù)校驗(yàn)。接收用戶名、密碼、驗(yàn)證碼如果有先做基礎(chǔ)格式校驗(yàn)比如用戶名不能含特殊字符、密碼不能為空、驗(yàn)證碼是否正確。驗(yàn)證碼的校驗(yàn)要放在密碼校驗(yàn)之前這樣可以把大部分自動(dòng)化攻擊擋在密碼校驗(yàn)之外減少密碼哈希的計(jì)算消耗。第二步查詢用戶。根據(jù)用戶名查用戶主表查不到就直接返回“用戶名或密碼錯(cuò)誤”——這里注意千萬不能提示“用戶不存在”否則攻擊者就能通過接口批量探測(cè)哪些賬號(hào)是真實(shí)存在的。第三步校驗(yàn)用戶狀態(tài)。用戶狀態(tài)為禁用、已鎖定、已刪除都直接拒絕登錄。這一步要在密碼校驗(yàn)之前做因?yàn)槊艽a校驗(yàn)更昂貴而且對(duì)已禁用用戶做密碼校驗(yàn)也沒有意義。第四步校驗(yàn)密碼。用BCrypt的matches方法比對(duì)明文密碼和哈希值。失敗則記錄失敗次數(shù)連續(xù)失敗達(dá)到閾值就鎖定賬號(hào)一段時(shí)間。第五步簽發(fā)Token。密碼校驗(yàn)通過后生成訪問Token和刷新Token。第六步記錄登錄日志返回Token給前端。核心代碼我用Spring Security的Filter鏈來實(shí)現(xiàn)但為了展示完整邏輯先寫出最直白的Controller版本方便理解每一步。RestController public class AuthController { Autowired private UserService userService; Autowired private TokenService tokenService; Autowired private LoginLogService loginLogService; PostMapping(/api/auth/login) public ResponseEntityLoginResponse login(RequestBody Valid LoginRequest request) { // 第一步基礎(chǔ)校驗(yàn)由 Valid 注解完成這里省略 // 第二步查詢用戶 User user userService.findByUsername(request.getUsername()); if (user null) { throw new BusinessException(用戶名或密碼錯(cuò)誤); } // 第三步用戶狀態(tài)校驗(yàn) if (user.getStatus() 0) { throw new BusinessException(賬號(hào)已被禁用請(qǐng)聯(lián)系管理員); } // 第四步密碼校驗(yàn) Credential credential userService.findCredential(user.getId()); if (credential null || !PasswordUtil.matches(request.getPassword(), credential.getPasswordHash())) { handleLoginFailure(request.getUsername()); throw new BusinessException(用戶名或密碼錯(cuò)誤); } // 檢查是否鎖定 if (credential.getLockUntil() ! null credential.getLockUntil().isAfter(LocalDateTime.now())) { throw new BusinessException(賬號(hào)已鎖定請(qǐng)稍后再試); } // 第五步簽發(fā)Token TokenPair tokenPair tokenService.createTokenPair(user.getId(), request.getLoginDevice()); // 第六步記錄日志 loginLogService.recordLogin(user.getId(), request.getUsername(), LoginResult.SUCCESS, RequestUtil.getClientIp()); return ResponseEntity.ok(new LoginResponse( tokenPair.getAccessToken(), tokenPair.getRefreshToken(), tokenPair.getExpiresIn())); } }這里有個(gè)非常重要的細(xì)節(jié)密碼錯(cuò)誤和用戶不存在時(shí)返回給前端的提示文案要完全一樣統(tǒng)一為“用戶名或密碼錯(cuò)誤”。這是登錄接口防用戶枚舉的標(biāo)準(zhǔn)做法。你可以自己建個(gè)測(cè)試賬號(hào)故意輸錯(cuò)密碼和故意輸錯(cuò)用戶名看返回信息是否一致如果一致說明這個(gè)接口在信息泄露層面是安全的。BCrypt匹配的代碼很簡單但我想特別說下它內(nèi)部做了什么。BCrypt匹配過程不只是簡單地做一次哈希比較它會(huì)從存儲(chǔ)的哈希串里解析出鹽值和代價(jià)因子然后用相同的鹽值重新計(jì)算輸入的密碼最后再比較結(jié)果。代價(jià)因子越高單次計(jì)算耗時(shí)越長暴力破解的成本就越高。我給內(nèi)部系統(tǒng)配置的代價(jià)因子是10大約耗時(shí)100毫秒左右如果是面向用戶的C端系統(tǒng)建議配到12雖然登錄會(huì)慢一點(diǎn)點(diǎn)但安全性提升明顯。3.4 令牌發(fā)放與刷新JWT Redis的混合會(huì)話方案接下來是令牌部分這也是整個(gè)登錄流程里我最想重點(diǎn)講的環(huán)節(jié)。訪問Token我習(xí)慣設(shè)置15分鐘有效期刷新Token設(shè)置7天有效期刷新Token存在Redis里Key的格式是refresh:token:{userId}:{jti}Value存的是刷新Token本身的哈希值同時(shí)設(shè)置過期時(shí)間。這樣做有三個(gè)好處。第一訪問Token短命即使被竊取攻擊者能利用的時(shí)間窗口很短第二刷新Token存在服務(wù)端管理員可以刪除Redis中的Key來實(shí)現(xiàn)強(qiáng)制下線第三刷新Token用jtiJWT ID作為標(biāo)識(shí)每次刷新可以旋轉(zhuǎn)令牌舊令牌直接失效能有效防止Token重放。TokenService的核心代碼如下Service public class TokenService { Value(${jwt.access-token-expire}) private long accessTokenExpire; // 毫秒默認(rèn) 90000015分鐘 Value(${jwt.refresh-token-expire}) private long refreshTokenExpire; // 毫秒默認(rèn) 6048000007天 Autowired private StringRedisTemplate redisTemplate; private static final String REFRESH_KEY_PREFIX refresh:token:; public TokenPair createTokenPair(Long userId, String device) { // 生成訪問Token String accessToken createAccessToken(userId, device); // 生成刷新Token String refreshToken createRefreshToken(userId, device); return new TokenPair(accessToken, refreshToken, accessTokenExpire); } private String createAccessToken(Long userId, String device) { long now System.currentTimeMillis(); return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(device, device) .setIssuer(your-system) .setIssuedAt(new Date(now)) .setExpiration(new Date(now accessTokenExpire)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); } private String createRefreshToken(Long userId, String device) { String jti UUID.randomUUID().toString().replace(-, ); long now System.currentTimeMillis(); String refreshToken Jwts.builder() .setSubject(String.valueOf(userId)) .setId(jti) .claim(device, device) .setIssuer(your-system) .setIssuedAt(new Date(now)) .setExpiration(new Date(now refreshTokenExpire)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); // 刷新Token存入Redis String redisKey REFRESH_KEY_PREFIX userId : jti; // 只存哈希值不存完整Token減少Redis內(nèi)存占用 redisTemplate.opsForValue().set(redisKey, DigestUtils.sha256Hex(refreshToken), refreshTokenExpire, TimeUnit.MILLISECONDS); return refreshToken; } public RefreshResult refreshAccessToken(String oldRefreshToken) { // 解析舊刷新Token Claims claims; try { claims Jwts.parserBuilder() .setSigningKey(secretKey) .build() .parseClaimsJws(oldRefreshToken) .getBody(); } catch (JwtException e) { throw new BusinessException(登錄狀態(tài)已過期請(qǐng)重新登錄); } String userId claims.getSubject(); String jti claims.getId(); String device claims.get(device, String.class); // 校驗(yàn)Redis中的刷新Token是否匹配 String redisKey REFRESH_KEY_PREFIX userId : jti; String storedHash redisTemplate.opsForValue().get(redisKey); if (storedHash null || !storedHash.equals(DigestUtils.sha256Hex(oldRefreshToken))) { throw new BusinessException(登錄狀態(tài)已過期請(qǐng)重新登錄); } // 旋轉(zhuǎn)刷新Token刪除舊Key生成新Token對(duì) redisTemplate.delete(redisKey); TokenPair newTokenPair createTokenPair(Long.parseLong(userId), device); return new RefreshResult(newTokenPair.getAccessToken(), newTokenPair.getRefreshToken(), newTokenPair.getAccessExpiresIn()); } public void revokeByUserId(Long userId) { // 管理員強(qiáng)制下線刪除該用戶所有刷新Token SetString keys redisTemplate.keys(REFRESH_KEY_PREFIX userId :*); if (keys ! null !keys.isEmpty()) { redisTemplate.delete(keys); } } }刷新接口的邏輯很簡單前端拿到401響應(yīng)后帶上刷新Token請(qǐng)求/api/auth/refresh服務(wù)端驗(yàn)證刷新Token有效且Redis中有對(duì)應(yīng)記錄然后刪除舊刷新Token生成新的一對(duì)Token返回。這里有一個(gè)細(xì)節(jié)刷新接口本身也要做防盜用處理我要求前端必須在每次刷新時(shí)把舊刷新Token從本地移除并立即替換為新Token。如果檢測(cè)到同一個(gè)刷新Token被使用了兩次說明可能存在Token被竊取的風(fēng)險(xiǎn)我會(huì)把該用戶名下所有的刷新Token全部作廢并要求重新登錄。注意生產(chǎn)環(huán)境里令牌接口必須走HTTPS否則Token在傳輸過程中被截獲前面做的一切安全工作都等于零。這一點(diǎn)不需要討論是強(qiáng)制要求。3.5 密碼加密與校驗(yàn)BCrypt為什么是默認(rèn)選擇密碼存儲(chǔ)方式在企業(yè)級(jí)登錄里是一個(gè)永恒的話題。我見過有人用MD5加鹽來存儲(chǔ)也見過直接明文存儲(chǔ)的“事故現(xiàn)場(chǎng)”——那種系統(tǒng)的審計(jì)報(bào)告我甚至不敢仔細(xì)看。這里我直接給結(jié)論新系統(tǒng)一律用BCrypt舊系統(tǒng)從MD5遷移到BCrypt的方案我也在下面的坑點(diǎn)里詳細(xì)說明。BCrypt的核心特點(diǎn)有三個(gè)。第一內(nèi)置鹽值。每次加密都生成隨機(jī)鹽值同樣的密碼兩次加密的結(jié)果不一樣所以攻擊者無法通過彩虹表直接破解。第二計(jì)算成本可調(diào)。通過代價(jià)因子cost factor控制哈希計(jì)算次數(shù)代價(jià)因子每加1計(jì)算時(shí)間大約翻倍。第三自帶格式。BCrypt的哈希字符串形如$2a$10$7EqJtq8hPqXfYvLbI5Xh0u...其中$2a是算法標(biāo)識(shí)10是代價(jià)因子后面是鹽值和哈希值。BCrypt的使用代碼public class PasswordUtil { // 加密 public static String encode(String rawPassword) { return BCrypt.hashpw(rawPassword, BCrypt.gensalt(10)); } // 校驗(yàn) public static boolean matches(String rawPassword, String encodedPassword) { return BCrypt.checkpw(rawPassword, encodedPassword); } }使用時(shí)的注意點(diǎn)BCrypt有輸入長度限制超過72字節(jié)的密碼會(huì)被截?cái)嗨詷I(yè)務(wù)上要限制密碼最大長度。另外如果你的系統(tǒng)需要從MD5或SHA-256遷移到BCrypt不能簡單地把舊哈希直接換成BCrypt——用戶下次登錄時(shí)需要能校驗(yàn)舊密碼同時(shí)又能無縫升級(jí)。我常用的方案是給用戶憑據(jù)表加一個(gè)credential_version字段舊用戶是V1用MD5校驗(yàn)首次用V1版本密碼成功登錄后立刻把密碼重新用BCrypt加密同時(shí)把版本改為V2后續(xù)登錄走V2校驗(yàn)。這樣用戶無感知地完成了密碼存儲(chǔ)升級(jí)不需要讓所有人都重置密碼。4. 登錄鏈路中的安全防護(hù)細(xì)節(jié)那些看不見的攻防4.1 暴力破解防護(hù)不只是限制失敗次數(shù)暴力破解防護(hù)只做“失敗次數(shù)鎖定”是遠(yuǎn)遠(yuǎn)不夠的。攻擊者如果控制了一批代理IP或者借用分布式節(jié)點(diǎn)來攻擊單純按IP限流很容易被繞過。更靠譜的做法是分層防護(hù)。第一層驗(yàn)證碼。登錄頁的圖形驗(yàn)證碼或滑塊驗(yàn)證碼在前端發(fā)起登錄請(qǐng)求時(shí)必須攜帶。服務(wù)端校驗(yàn)驗(yàn)證碼通過后才繼續(xù)走賬號(hào)密碼校驗(yàn)。驗(yàn)證碼可以放在Redis里5分鐘有效一次性使用。第二層賬號(hào)維度限制。同一賬號(hào)連續(xù)失敗5次鎖定15分鐘鎖定時(shí)間隨失敗次數(shù)遞增比如第6到第10次失敗鎖30分鐘超過10次鎖24小時(shí)。這個(gè)策略要把攻擊者的成本抬得足夠高又不至于影響正常用戶。第三層IP維度的頻率限制。同一IP在單位時(shí)間內(nèi)的登錄請(qǐng)求次數(shù)超過閾值就拒絕比如每分鐘不超過30次每小時(shí)不超過100次。具體閾值要根據(jù)你系統(tǒng)的實(shí)際用戶量調(diào)整核心是防止集中的自動(dòng)化請(qǐng)求。防暴力破解的核心代碼Aspect Component public class LoginAttemptAspect { Autowired private StringRedisTemplate redisTemplate; // 賬號(hào)失敗鎖定Key private static final String ACCOUNT_FAIL_KEY login:fail:account:; // IP失敗鎖定Key private static final String IP_FAIL_KEY login:fail:ip:; public void recordFailure(String username, String ip) { // 賬號(hào)維度 String accountKey ACCOUNT_FAIL_KEY username; Long accountCount redisTemplate.opsForValue().increment(accountKey); if (accountCount ! null accountCount 1) { redisTemplate.expire(accountKey, 15, TimeUnit.MINUTES); } if (accountCount 5) { // 鎖定賬號(hào)15分鐘 String lockKey login:lock:account: username; redisTemplate.opsForValue().set(lockKey, 1, 15, TimeUnit.MINUTES); } // IP維度 String ipKey IP_FAIL_KEY ip; Long ipCount redisTemplate.opsForValue().increment(ipKey); if (ipCount ! null ipCount 1) { redisTemplate.expire(ipKey, 1, TimeUnit.MINUTES); } if (ipCount 30) { // 該IP臨時(shí)拒絕登錄 String ipBlockKey login:block:ip: ip; redisTemplate.opsForValue().set(ipBlockKey, 1, 5, TimeUnit.MINUTES); } } }這套方案在我維護(hù)過的系統(tǒng)里跑了兩三年效果很穩(wěn)定。有個(gè)值得注意的細(xì)節(jié)失敗次數(shù)計(jì)數(shù)器在Redis里要設(shè)置過期時(shí)間不能全程累計(jì)。否則正常用戶可能在連續(xù)幾天內(nèi)偶爾輸錯(cuò)幾次密碼就被累計(jì)到鎖定閾值體驗(yàn)很差。4.2 登錄態(tài)安全防固定會(huì)話攻擊與Token泄露登錄態(tài)安全還有一個(gè)容易忽略的點(diǎn)固定會(huì)話攻擊。攻擊者可以先在自己瀏覽器里登錄一個(gè)合法賬號(hào)拿到一個(gè)有效的會(huì)話ID然后誘導(dǎo)受害者使用這個(gè)會(huì)話ID去登錄。如果系統(tǒng)在登錄成功后沒有更換會(huì)話ID攻擊者就能用同一個(gè)會(huì)話ID冒充受害者。JWT方案同樣存在這個(gè)問題所以我在登錄成功后簽發(fā)的Token里會(huì)帶一個(gè)隨機(jī)字符串jti并確保每次登錄都重新生成不同設(shè)備、不同會(huì)話之間互相獨(dú)立。還有一個(gè)和業(yè)務(wù)強(qiáng)相關(guān)的細(xì)節(jié)賬號(hào)同時(shí)多端登錄怎么處理。有的系統(tǒng)要求一個(gè)人只能同時(shí)在一個(gè)設(shè)備上登錄新的登錄會(huì)踢掉舊的有的系統(tǒng)允許多端共存但要做設(shè)備管理列表。我建議做設(shè)備管理查登錄日志時(shí)能清晰看到“哪個(gè)用戶、什么時(shí)間、用什么設(shè)備登錄”這在安全審計(jì)時(shí)非常重要。我的實(shí)現(xiàn)是在刷新Token里加入設(shè)備標(biāo)識(shí)登錄時(shí)前端傳入設(shè)備編號(hào)不傳則根據(jù)User-Agent生成唯一標(biāo)識(shí)。記錄設(shè)備信息不是為了炫技而是為了讓用戶能在“賬號(hào)安全中心”里看到自己的登錄設(shè)備列表一旦發(fā)現(xiàn)陌生設(shè)備可以直接踢下線。4.3 登錄日志與審計(jì)出了事拿得出數(shù)據(jù)登錄日志這塊很多團(tuán)隊(duì)會(huì)拖到出安全事故后才想起來補(bǔ)。但企業(yè)級(jí)系統(tǒng)的登錄入口我一定會(huì)在設(shè)計(jì)階段就把審計(jì)日志做進(jìn)去。登錄日志至少需要包含這些字段用戶ID、用戶名、登錄時(shí)間、登錄IP、設(shè)備信息、登錄結(jié)果成功/失敗、失敗原因。我的日志表設(shè)計(jì)如下CREATE TABLE sys_login_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT, username VARCHAR(64), login_ip VARCHAR(64), device_info VARCHAR(256), user_agent VARCHAR(512), login_result TINYINT COMMENT 1:成功 2:密碼錯(cuò)誤 3:賬號(hào)鎖定 4:驗(yàn)證碼錯(cuò)誤, fail_reason VARCHAR(128), login_time DATETIME, INDEX idx_user_time (user_id, login_time), INDEX idx_ip_time (login_ip, login_time) );寫日志的時(shí)機(jī)要選好成功日志在Token簽發(fā)后記錄失敗日志在每一步失敗分支里記錄。日志的數(shù)據(jù)量會(huì)增長很快我建議按天做分區(qū)保留最近90天超過時(shí)間的歸檔到冷存儲(chǔ)。審計(jì)日志絕對(duì)不能只存在應(yīng)用服務(wù)器本地磁盤要統(tǒng)一匯總到日志中心否則服務(wù)器一旦重新部署數(shù)據(jù)就丟了。我個(gè)人在實(shí)際排查問題時(shí)發(fā)現(xiàn)用戶忘記密碼是最常見的工單類型。有了登錄日志客服可以直接看到用戶是不是被鎖定、鎖定時(shí)間到什么時(shí)候能很快判斷是攻擊導(dǎo)致的鎖定還是用戶自己輸錯(cuò)太多次。這個(gè)價(jià)值在實(shí)際運(yùn)維中非常明顯。5. 實(shí)操過程記錄從零搭建到線上穩(wěn)定運(yùn)行5.1 環(huán)境準(zhǔn)備我這邊使用的環(huán)境是一臺(tái)4核8G的開發(fā)機(jī)安裝CentOS 7系統(tǒng)、Docker、MySQL 8.0、Redis 6.0。企業(yè)級(jí)登錄模塊的開發(fā)和部署我建議至少把MySQL和Redis用Docker單獨(dú)跑起來方便重置環(huán)境。簡單貼一下啟動(dòng)命令# 啟動(dòng)MySQL docker run -d --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDyourpassword \ -e MYSQL_DATABASEenterprise_auth \ mysql:8.0 # 啟動(dòng)Redis docker run -d --name redis6 \ -p 6379:6379 \ redis:6.0 --requirepass yourredispassword表結(jié)構(gòu)按照上面的SQL建好之后插入一個(gè)測(cè)試賬號(hào)INSERT INTO sys_user (username, real_name) VALUES (tester, 測(cè)試用戶); INSERT INTO sys_user_credential (user_id, credential_type, password_hash) VALUES (1, PASSWORD, $2a$10$...); -- 用BCrypt加密后的值5.2 登錄接口調(diào)試過程我習(xí)慣用Postman做初步調(diào)試。登錄接口的請(qǐng)求體{ username: tester, password: Test123456, captcha: 8F2A }調(diào)試時(shí)重點(diǎn)關(guān)注三個(gè)響應(yīng)登錄成功的200響應(yīng)、密碼錯(cuò)誤的401響應(yīng)、賬號(hào)鎖定的403響應(yīng)。響應(yīng)體里的錯(cuò)誤碼要設(shè)計(jì)清楚前端才能根據(jù)不同錯(cuò)誤類型給出不同提示。我常用的錯(cuò)誤碼定義是1001驗(yàn)證碼錯(cuò)誤1002用戶名或密碼錯(cuò)誤1003賬號(hào)已鎖定1004賬號(hào)已禁用1005登錄狀態(tài)已過期前端根據(jù)錯(cuò)誤碼提示相應(yīng)文案而不是直接把后端的錯(cuò)誤信息透出。這里有一個(gè)細(xì)節(jié)后端的錯(cuò)誤信息盡量別給前端展示統(tǒng)一轉(zhuǎn)成錯(cuò)誤碼否則會(huì)存在信息泄露風(fēng)險(xiǎn)也容易被攻擊者利用細(xì)節(jié)來枚舉用戶狀態(tài)。5.3 配置Spring Security放行登錄接口Spring Security默認(rèn)會(huì)攔截所有請(qǐng)求登錄接口本身要放行但刷新接口不能直接放行——刷新接口要單獨(dú)走一套校驗(yàn)邏輯。我的配置思路是Configuration EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests() .antMatchers(/api/auth/login).permitAll() // 登錄接口放行 .antMatchers(/api/auth/captcha).permitAll() // 驗(yàn)證碼接口放行 .anyRequest().authenticated() .and() .addFilterBefore(jwtAuthFilter, UsernamePasswordAuthenticationFilter.class); } }JWT過濾器的邏輯是從請(qǐng)求頭Authorization里取Token解析成功就向SecurityContext寫入認(rèn)證信息解析失敗則返回401。過濾器的代碼不復(fù)雜但有一個(gè)細(xì)節(jié)Token過期返回的401和未攜帶Token返回的401響應(yīng)體的錯(cuò)誤碼要一致不能給攻擊者區(qū)分“這個(gè)接口需要登錄”和“這個(gè)Token剛好過期”的機(jī)會(huì)。5.4 前端登錄流程對(duì)接前端拿到Token后的存儲(chǔ)位置我這里直接給出結(jié)論訪問Token只能放在內(nèi)存里刷新Token放在HttpOnly Cookie里。如果前端把兩個(gè)Token都放進(jìn)localStorage一旦出現(xiàn)跨站腳本漏洞Token會(huì)整個(gè)被偷走。放在HttpOnly Cookie里的刷新Token腳本拿不到安全級(jí)別高很多。我設(shè)計(jì)的前端登錄對(duì)接邏輯是頁面加載時(shí)先嘗試用刷新Token靜默換取訪問Token換不到就跳轉(zhuǎn)登錄頁登錄頁成功后拿到訪問Token刷新Token通過Set-Cookie種入。每次請(qǐng)求時(shí)攜帶訪問Token收到401時(shí)嘗試刷新刷新成功則重放原請(qǐng)求刷新失敗則跳回登錄頁。這套流程跑起來很順滑用戶基本感覺不到會(huì)話快過期這件事。6. 常見問題與排查技巧實(shí)錄6.1 用戶登錄后頻繁掉線這是我自己排查過最多的問題類型之一?，F(xiàn)象是用戶登錄成功但沒過多久就收到401。排查步驟我建議按下面順序走第一步看訪問Token過期時(shí)間是否太短。如果你把訪問Token設(shè)成了5分鐘甚至更短那用戶操作稍微磨蹭一點(diǎn)Token就過期了。我建議至少15分鐘配合刷新機(jī)制使用。第二步看前端是否正確處理了401刷新邏輯。很多前端代碼只在攔截器里做了“彈回登錄頁”沒有做“先用刷新Token靜默換新Token”。這種實(shí)現(xiàn)下Token一過期用戶就得重新登錄。正確做法是先嘗試靜默刷新刷新失敗再跳登錄頁。第三步看服務(wù)端時(shí)鐘是否同步。如果應(yīng)用服務(wù)器的時(shí)間比認(rèn)證授權(quán)服務(wù)器快或者慢Token的exp和iat字段就會(huì)出現(xiàn)偏差導(dǎo)致明明沒過期卻被判為過期。用NTP確保服務(wù)器時(shí)間同步這步常被忽略。6.2 Redis里刷新Token明明存在但刷新一直失敗我遇到過一次很詭異的場(chǎng)景刷新Token發(fā)過去了Redis里也能查到Key但服務(wù)端一直報(bào)“登錄狀態(tài)已過期”。查了很久最后發(fā)現(xiàn)是解析JWT的密鑰配置不一致——簽發(fā)Refresh Token用的密鑰和應(yīng)用啟動(dòng)時(shí)加載的密鑰不是同一個(gè)。如果你把密鑰放在配置中心務(wù)必確認(rèn)各環(huán)境配置的一致性。另一個(gè)可能原因是Redis的Key過期策略。我在前面代碼里給刷新Token設(shè)置了7天過期但如果用戶在7天內(nèi)頻繁活躍我一直建議在每次刷新時(shí)順帶延長刷新Token的過期時(shí)間也就是“滑動(dòng)過期”。如果沒做滑動(dòng)過期用戶哪怕天天在用系統(tǒng)登錄狀態(tài)也會(huì)在第7天準(zhǔn)時(shí)失效。這個(gè)體驗(yàn)很糟糕。我的做法是每次刷新成功后重新設(shè)置刷新Token的過期時(shí)間為7天。6.3 驗(yàn)證碼明明對(duì)了卻總是提示錯(cuò)誤驗(yàn)證碼問題的高發(fā)原因有兩個(gè)。第一驗(yàn)證碼使用一次后沒有刪除Redis中的緩存導(dǎo)致同一個(gè)驗(yàn)證碼可以重復(fù)使用前端又每次提交同一個(gè)驗(yàn)證碼后端一刪就再也對(duì)不上了所以會(huì)“明明對(duì)了但提示錯(cuò)誤”。第二驗(yàn)證碼的存儲(chǔ)Key生成的邏輯不一致。比如生成時(shí)用captcha:{uuid}校驗(yàn)時(shí)用captcha:uuid大小寫或分隔符不一致自然匹配不上。寫代碼時(shí)我強(qiáng)烈建議統(tǒng)一封裝一個(gè)驗(yàn)證碼服務(wù)生成和校驗(yàn)都走同一套Key拼接邏輯不要一個(gè)地方手寫一個(gè)Key。6.4 跨域場(chǎng)景下的Cookie和Token問題前后端分離的項(xiàng)目前端部署在app.example.com后端部署在api.example.com這是最常見的跨域場(chǎng)景?？缬虮旧聿浑y但有一個(gè)坑刷新Token放在HttpOnly Cookie里跨域請(qǐng)求時(shí)默認(rèn)不會(huì)攜帶Cookie。需要在后端配置CORS時(shí)設(shè)置allowCredentials(true)同時(shí)前端請(qǐng)求要帶上withCredentials。如果前端和后端的主域名不同比如前端是example.com后端是auth.anotherdomain.comCookie跨域攜帶就要設(shè)置Domain屬性。但Cookie的Domain不能跨完全不同的頂級(jí)域名這種場(chǎng)景下要么做代理轉(zhuǎn)發(fā)要么改用其它會(huì)話方案。我在實(shí)際項(xiàng)目里更推薦的做法是前端Nginx把/api路徑反向代理到后端服務(wù)這樣瀏覽器看到的請(qǐng)求是同源的Cookie方案能用CORS也不用額外開放。簡單直接問題最少。6.5 密碼升級(jí)遷移踩坑記錄最后分享一個(gè)舊系統(tǒng)改造的案例很有代表性。某系統(tǒng)原來用MD5存儲(chǔ)密碼用戶量好幾萬不可能讓所有人重置密碼。我接手后做了兩步改造第一步新增credential_version字段默認(rèn)V1。登錄接口邏輯改成根據(jù)用戶當(dāng)前版本走對(duì)應(yīng)的校驗(yàn)邏輯。V1的走M(jìn)D5校驗(yàn)校驗(yàn)成功后立即用BCrypt重算密碼哈希把版本升到V2。這樣所有用戶在自己下次登錄時(shí)完成無感升級(jí)。第二步在系統(tǒng)中加入密碼強(qiáng)度校驗(yàn)。新注冊(cè)或修改密碼時(shí)強(qiáng)制要求密碼長度不少于8位且包含大小寫字母、數(shù)字、特殊字符中至少三類。歷史不良密碼在升級(jí)時(shí)也要求用戶重置一次。整個(gè)遷移過程平穩(wěn)落地沒有產(chǎn)生一條“密碼失效”的工單。7. 最后的幾點(diǎn)心得登錄功能寫到這里我覺得最有價(jià)值的反而不是代碼而是對(duì)整個(gè)系統(tǒng)的安全邊界意識(shí)。企業(yè)級(jí)登錄流程涉及的東西非常多——Token策略、密碼存儲(chǔ)、暴力破解防護(hù)、審計(jì)日志、跨域處理、密碼升級(jí)——每一項(xiàng)單拎出來都不算難但組合在一起任何一個(gè)環(huán)節(jié)的疏忽都會(huì)成為攻擊者的突破口。我個(gè)人的體會(huì)是設(shè)計(jì)登錄模塊時(shí)永遠(yuǎn)要問自己三個(gè)問題如果數(shù)據(jù)庫泄露用戶的密碼安全嗎如果Token被截獲攻擊者能獲取哪些數(shù)據(jù)如果登錄接口被刷系統(tǒng)能支撐住嗎這三個(gè)問題全部能給出清晰答案你的登錄模塊才算真正達(dá)到了企業(yè)級(jí)要求。還有一點(diǎn)想強(qiáng)調(diào)登錄這個(gè)模塊改起來牽扯面很大上線前一定要做完整的回歸測(cè)試尤其是Token刷新、賬號(hào)鎖定、強(qiáng)制下線這幾個(gè)場(chǎng)景。我踩過最痛的一次坑就是上線時(shí)只測(cè)了“登錄成功”這條快樂路徑完全沒有覆蓋“Token過期后續(xù)期”的場(chǎng)景結(jié)果線上第一個(gè)小時(shí)就收到一堆“系統(tǒng)自動(dòng)退出”的反饋灰溜溜地回滾版本。從那以后我給自己立了個(gè)規(guī)矩登錄模塊的功能清單里永遠(yuǎn)把異常場(chǎng)景放到和正常場(chǎng)景同等重要的位置去測(cè)試。這篇文章里的代碼和方案我都實(shí)際用過可以直接作為你項(xiàng)目里的初始版本去改造。如果你的場(chǎng)景和我的有些差異比如用了別的后端語言或者需要考慮更復(fù)雜的權(quán)限模型核心的流程設(shè)計(jì)和安全思路依然可以復(fù)用。登錄是系統(tǒng)的門面值得你多花些心思去打磨。 企業(yè)級(jí)登錄全流程設(shè)計(jì)：認(rèn)證授權(quán)、會(huì)話管理與安全防護(hù)實(shí)踐
1. 從零搭建企業(yè)級(jí)登錄先搞清楚我們?cè)诮鉀Q什么問題登錄這個(gè)功能單看好像就是“輸入賬號(hào)密碼、點(diǎn)一下按鈕”這么簡單但一旦放到企業(yè)級(jí)場(chǎng)景里它立刻變成整個(gè)系統(tǒng)中最敏感、最容易出事故、也最容易被攻擊者盯上的模塊。我見過太多項(xiàng)目在聯(lián)調(diào)階段才發(fā)現(xiàn)登錄流程設(shè)計(jì)得支離破碎有的把會(huì)話狀態(tài)塞進(jìn)本地存儲(chǔ)被腳本一鍋端有的密碼校驗(yàn)邏輯寫得比業(yè)務(wù)代碼還隨意還有的登錄接口被刷到數(shù)據(jù)庫連接池直接打滿。這些問題如果能在動(dòng)手寫代碼之前把整體流程想清楚大部分都能提前規(guī)避。先說清楚一個(gè)概念企業(yè)級(jí)用戶登錄指的是面向企業(yè)內(nèi)部員工、外部合作方、或者大規(guī)模C端用戶的統(tǒng)一身份認(rèn)證入口。它和“小網(wǎng)站搞個(gè)session存一下用戶ID”最大的區(qū)別在于企業(yè)級(jí)登錄要考慮的不只是“怎么驗(yàn)證密碼”還要考慮多端兼容、會(huì)話安全、單點(diǎn)登錄SSO、權(quán)限隔離、審計(jì)追蹤、防暴力破解、高可用部署這樣一整套體系。換句話說登錄不是一個(gè)“功能點(diǎn)”而是一條完整的安全鏈路。這篇文章我會(huì)從方案選型、核心代碼實(shí)現(xiàn)、踩坑記錄、到線上排查技巧完整走一遍企業(yè)級(jí)登錄流程的設(shè)計(jì)與落地。如果你正在做企業(yè)內(nèi)部系統(tǒng)、SaaS平臺(tái)、或者任何對(duì)安全要求比較高的Web應(yīng)用這篇文章應(yīng)該能幫你少走不少彎路。我會(huì)盡量把原理講透代碼部分也會(huì)給到可以直接改改就用的程度。2. 整體方案設(shè)計(jì)為什么我選擇了這套登錄架構(gòu)2.1 核心需求拆解登錄不只是校驗(yàn)密碼動(dòng)手設(shè)計(jì)之前我習(xí)慣先把需求拆成四個(gè)維度認(rèn)證Authentication、授權(quán)Authorization、會(huì)話管理Session Management、審計(jì)Audit。這四個(gè)詞聽起來很像但實(shí)際是四件完全不同的事。認(rèn)證解決的是“你是誰”的問題常見手段就是賬號(hào)密碼、短信驗(yàn)證碼、掃碼登錄、OAuth第三方授權(quán)授權(quán)解決的是“你能干什么”的問題比如登錄之后能訪問哪些菜單、哪些接口會(huì)話管理解決的是“怎么維持登錄狀態(tài)”的問題包括Token怎么發(fā)、怎么存、怎么續(xù)期、怎么失效審計(jì)解決的是“出了問題怎么追溯”的問題包括登錄日志、操作日志、異常行為記錄。很多項(xiàng)目的登錄模塊做得不好根本原因就是把這四個(gè)維度混在了一起。比如有的團(tuán)隊(duì)把用戶的權(quán)限列表直接塞進(jìn)JWT里美其名曰“無狀態(tài)設(shè)計(jì)”結(jié)果權(quán)限一改Token還得等過期才生效有的團(tuán)隊(duì)把會(huì)話存在內(nèi)存里服務(wù)一重啟全部用戶掉線。所以我做方案設(shè)計(jì)的第一步就是先把這四個(gè)維度分開畫清楚再?zèng)Q定每部分用什么技術(shù)承載。2.2 方案選型從Session到JWT再到混合方案登錄會(huì)話方案的主流選項(xiàng)大致有三類傳統(tǒng)Session、純JWT、以及Session JWT混合。我分別說下它們的適用場(chǎng)景和坑。傳統(tǒng)Session方案服務(wù)端把會(huì)話ID種在Cookie里用戶信息存服務(wù)端內(nèi)存或Redis。優(yōu)點(diǎn)是實(shí)現(xiàn)簡單、服務(wù)端可控性強(qiáng)、想踢誰踢誰缺點(diǎn)是分布式環(huán)境下要解決Session共享問題而且Cookie在跨域場(chǎng)景下比較麻煩。這個(gè)方案適合傳統(tǒng)服務(wù)端渲染的Web應(yīng)用比如企業(yè)內(nèi)部管理后臺(tái)。純JWT方案服務(wù)端把用戶信息簽進(jìn)Token里客戶端保存Token每次請(qǐng)求帶上來。優(yōu)點(diǎn)是天然適合前后端分離和移動(dòng)端服務(wù)端不需要存會(huì)話狀態(tài)擴(kuò)展性好缺點(diǎn)是Token沒法主動(dòng)失效除非引入黑名單機(jī)制而且如果往Token里塞太多東西請(qǐng)求頭會(huì)變得很大。這個(gè)方案適合開放API平臺(tái)、多端共用的服務(wù)。我實(shí)際項(xiàng)目里用得最多的是第三種混合方案。登錄成功后簽發(fā)短期JWT作為訪問憑證同時(shí)把刷新令牌Refresh Token存在Redis里有效期設(shè)置得長一些。短期Token過期后客戶端用刷新令牌換新Token。這樣既保留了JWT適合多端、擴(kuò)展性好的優(yōu)點(diǎn)又通過刷新令牌的Redis存儲(chǔ)實(shí)現(xiàn)了“可控的登錄狀態(tài)”——管理員可以刪除Redis里的刷新令牌達(dá)到強(qiáng)制下線效果。提示純JWT不是說不能用但它在企業(yè)級(jí)場(chǎng)景里有一個(gè)很尷尬的問題你沒辦法在服務(wù)端把已經(jīng)發(fā)出的Token作廢。如果遇到安全事件需要緊急踢掉所有在線用戶純JWT方案得靠改密鑰才能實(shí)現(xiàn)那代價(jià)就太大了。2.3 為什么企業(yè)級(jí)登錄必須做“多因子”設(shè)計(jì)我說的多因子不是指一定要上短信或者掃碼而是說至少要有兩層驗(yàn)證邏輯。第一層是“你知道什么”也就是賬號(hào)密碼第二層我建議至少做到“你擁有什么”比如手機(jī)驗(yàn)證碼、或者已經(jīng)綁定過的設(shè)備信息。對(duì)于后臺(tái)管理類系統(tǒng)這一步幾乎是必須的。有一次我負(fù)責(zé)給一個(gè)內(nèi)部運(yùn)營平臺(tái)加登錄功能一開始只做了賬號(hào)密碼上線第二天就有同事反饋說自己密碼被改了。查日志發(fā)現(xiàn)是有人拿弱口令字典在掃登錄接口剛好掃中了幾個(gè)用生日當(dāng)密碼的賬號(hào)。后來我上了登錄失敗次數(shù)限制、密碼復(fù)雜度策略、以及二次驗(yàn)證才把這個(gè)口子堵住。這里的教訓(xùn)是企業(yè)級(jí)系統(tǒng)的登錄入口永遠(yuǎn)默認(rèn)被攻擊者盯著安全設(shè)計(jì)不是“要不要做”的問題而是“怎么做才不拖累體驗(yàn)”的問題。3. 核心代碼實(shí)現(xiàn)一套可以落地的登錄流程3.1 技術(shù)棧說明我用Java技術(shù)棧做示例原因很簡單企業(yè)級(jí)后端項(xiàng)目Java的占比依然很高Spring Boot Spring Security Redis這套組合在業(yè)界非常成熟。但本文講的流程設(shè)計(jì)思路是完全語言無關(guān)的你用Node.js、Python、Go也能對(duì)應(yīng)落地。Spring Boot 2.7.xSpring SecurityJWTjjwt 0.11.5RedisSpring Data RedisMyBatis-Plus用于查詢用戶信息可替換成任何ORM密碼加密BCrypt3.2 表結(jié)構(gòu)設(shè)計(jì)用戶的密碼不該出現(xiàn)在用戶表里先看表結(jié)構(gòu)。很多新手會(huì)直接把密碼字段放在用戶表里這在企業(yè)級(jí)設(shè)計(jì)里是不推薦的。我習(xí)慣把“賬號(hào)信息”和“身份憑證”分開存儲(chǔ)這樣后續(xù)如果需要支持多種登錄方式——密碼登錄、短信登錄、企業(yè)微信掃碼登錄——擴(kuò)展起來不會(huì)動(dòng)用戶主表。-- 用戶基礎(chǔ)表 CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(64) NOT NULL UNIQUE, real_name VARCHAR(64), status TINYINT NOT NULL DEFAULT 1 COMMENT 1:啟用 0:禁用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); -- 用戶憑據(jù)表存密碼、上次修改時(shí)間等信息 CREATE TABLE sys_user_credential ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, credential_type VARCHAR(16) NOT NULL DEFAULT PASSWORD, password_hash VARCHAR(256) NOT NULL, last_reset_time DATETIME, failed_attempts INT DEFAULT 0, lock_until DATETIME, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_user_type (user_id, credential_type) );這兩個(gè)表的關(guān)系是一對(duì)多一個(gè)用戶可以有多種類型的憑證。密碼只存BCrypt加過密的哈希值不存明文這一點(diǎn)沒有任何商量余地。BCrypt是自適應(yīng)哈希算法可以調(diào)節(jié)計(jì)算成本暴力破解的代價(jià)非常高比MD5、SHA-256這類純哈希方案安全很多。3.3 登錄接口實(shí)現(xiàn)從校驗(yàn)到發(fā)Token的完整鏈路登錄接口的核心邏輯分六步我一個(gè)個(gè)拆開講。第一步參數(shù)校驗(yàn)。接收用戶名、密碼、驗(yàn)證碼如果有先做基礎(chǔ)格式校驗(yàn)比如用戶名不能含特殊字符、密碼不能為空、驗(yàn)證碼是否正確。驗(yàn)證碼的校驗(yàn)要放在密碼校驗(yàn)之前這樣可以把大部分自動(dòng)化攻擊擋在密碼校驗(yàn)之外減少密碼哈希的計(jì)算消耗。第二步查詢用戶。根據(jù)用戶名查用戶主表查不到就直接返回“用戶名或密碼錯(cuò)誤”——這里注意千萬不能提示“用戶不存在”否則攻擊者就能通過接口批量探測(cè)哪些賬號(hào)是真實(shí)存在的。第三步校驗(yàn)用戶狀態(tài)。用戶狀態(tài)為禁用、已鎖定、已刪除都直接拒絕登錄。這一步要在密碼校驗(yàn)之前做因?yàn)槊艽a校驗(yàn)更昂貴而且對(duì)已禁用用戶做密碼校驗(yàn)也沒有意義。第四步校驗(yàn)密碼。用BCrypt的matches方法比對(duì)明文密碼和哈希值。失敗則記錄失敗次數(shù)連續(xù)失敗達(dá)到閾值就鎖定賬號(hào)一段時(shí)間。第五步簽發(fā)Token。密碼校驗(yàn)通過后生成訪問Token和刷新Token。第六步記錄登錄日志返回Token給前端。核心代碼我用Spring Security的Filter鏈來實(shí)現(xiàn)但為了展示完整邏輯先寫出最直白的Controller版本方便理解每一步。RestController public class AuthController { Autowired private UserService userService; Autowired private TokenService tokenService; Autowired private LoginLogService loginLogService; PostMapping(/api/auth/login) public ResponseEntityLoginResponse login(RequestBody Valid LoginRequest request) { // 第一步基礎(chǔ)校驗(yàn)由 Valid 注解完成這里省略 // 第二步查詢用戶 User user userService.findByUsername(request.getUsername()); if (user null) { throw new BusinessException(用戶名或密碼錯(cuò)誤); } // 第三步用戶狀態(tài)校驗(yàn) if (user.getStatus() 0) { throw new BusinessException(賬號(hào)已被禁用請(qǐng)聯(lián)系管理員); } // 第四步密碼校驗(yàn) Credential credential userService.findCredential(user.getId()); if (credential null || !PasswordUtil.matches(request.getPassword(), credential.getPasswordHash())) { handleLoginFailure(request.getUsername()); throw new BusinessException(用戶名或密碼錯(cuò)誤); } // 檢查是否鎖定 if (credential.getLockUntil() ! null credential.getLockUntil().isAfter(LocalDateTime.now())) { throw new BusinessException(賬號(hào)已鎖定請(qǐng)稍后再試); } // 第五步簽發(fā)Token TokenPair tokenPair tokenService.createTokenPair(user.getId(), request.getLoginDevice()); // 第六步記錄日志 loginLogService.recordLogin(user.getId(), request.getUsername(), LoginResult.SUCCESS, RequestUtil.getClientIp()); return ResponseEntity.ok(new LoginResponse( tokenPair.getAccessToken(), tokenPair.getRefreshToken(), tokenPair.getExpiresIn())); } }這里有個(gè)非常重要的細(xì)節(jié)密碼錯(cuò)誤和用戶不存在時(shí)返回給前端的提示文案要完全一樣統(tǒng)一為“用戶名或密碼錯(cuò)誤”。這是登錄接口防用戶枚舉的標(biāo)準(zhǔn)做法。你可以自己建個(gè)測(cè)試賬號(hào)故意輸錯(cuò)密碼和故意輸錯(cuò)用戶名看返回信息是否一致如果一致說明這個(gè)接口在信息泄露層面是安全的。BCrypt匹配的代碼很簡單但我想特別說下它內(nèi)部做了什么。BCrypt匹配過程不只是簡單地做一次哈希比較它會(huì)從存儲(chǔ)的哈希串里解析出鹽值和代價(jià)因子然后用相同的鹽值重新計(jì)算輸入的密碼最后再比較結(jié)果。代價(jià)因子越高單次計(jì)算耗時(shí)越長暴力破解的成本就越高。我給內(nèi)部系統(tǒng)配置的代價(jià)因子是10大約耗時(shí)100毫秒左右如果是面向用戶的C端系統(tǒng)建議配到12雖然登錄會(huì)慢一點(diǎn)點(diǎn)但安全性提升明顯。3.4 令牌發(fā)放與刷新JWT Redis的混合會(huì)話方案接下來是令牌部分這也是整個(gè)登錄流程里我最想重點(diǎn)講的環(huán)節(jié)。訪問Token我習(xí)慣設(shè)置15分鐘有效期刷新Token設(shè)置7天有效期刷新Token存在Redis里Key的格式是refresh:token:{userId}:{jti}Value存的是刷新Token本身的哈希值同時(shí)設(shè)置過期時(shí)間。這樣做有三個(gè)好處。第一訪問Token短命即使被竊取攻擊者能利用的時(shí)間窗口很短第二刷新Token存在服務(wù)端管理員可以刪除Redis中的Key來實(shí)現(xiàn)強(qiáng)制下線第三刷新Token用jtiJWT ID作為標(biāo)識(shí)每次刷新可以旋轉(zhuǎn)令牌舊令牌直接失效能有效防止Token重放。TokenService的核心代碼如下Service public class TokenService { Value(${jwt.access-token-expire}) private long accessTokenExpire; // 毫秒默認(rèn) 90000015分鐘 Value(${jwt.refresh-token-expire}) private long refreshTokenExpire; // 毫秒默認(rèn) 6048000007天 Autowired private StringRedisTemplate redisTemplate; private static final String REFRESH_KEY_PREFIX refresh:token:; public TokenPair createTokenPair(Long userId, String device) { // 生成訪問Token String accessToken createAccessToken(userId, device); // 生成刷新Token String refreshToken createRefreshToken(userId, device); return new TokenPair(accessToken, refreshToken, accessTokenExpire); } private String createAccessToken(Long userId, String device) { long now System.currentTimeMillis(); return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(device, device) .setIssuer(your-system) .setIssuedAt(new Date(now)) .setExpiration(new Date(now accessTokenExpire)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); } private String createRefreshToken(Long userId, String device) { String jti UUID.randomUUID().toString().replace(-, ); long now System.currentTimeMillis(); String refreshToken Jwts.builder() .setSubject(String.valueOf(userId)) .setId(jti) .claim(device, device) .setIssuer(your-system) .setIssuedAt(new Date(now)) .setExpiration(new Date(now refreshTokenExpire)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); // 刷新Token存入Redis String redisKey REFRESH_KEY_PREFIX userId : jti; // 只存哈希值不存完整Token減少Redis內(nèi)存占用 redisTemplate.opsForValue().set(redisKey, DigestUtils.sha256Hex(refreshToken), refreshTokenExpire, TimeUnit.MILLISECONDS); return refreshToken; } public RefreshResult refreshAccessToken(String oldRefreshToken) { // 解析舊刷新Token Claims claims; try { claims Jwts.parserBuilder() .setSigningKey(secretKey) .build() .parseClaimsJws(oldRefreshToken) .getBody(); } catch (JwtException e) { throw new BusinessException(登錄狀態(tài)已過期請(qǐng)重新登錄); } String userId claims.getSubject(); String jti claims.getId(); String device claims.get(device, String.class); // 校驗(yàn)Redis中的刷新Token是否匹配 String redisKey REFRESH_KEY_PREFIX userId : jti; String storedHash redisTemplate.opsForValue().get(redisKey); if (storedHash null || !storedHash.equals(DigestUtils.sha256Hex(oldRefreshToken))) { throw new BusinessException(登錄狀態(tài)已過期請(qǐng)重新登錄); } // 旋轉(zhuǎn)刷新Token刪除舊Key生成新Token對(duì) redisTemplate.delete(redisKey); TokenPair newTokenPair createTokenPair(Long.parseLong(userId), device); return new RefreshResult(newTokenPair.getAccessToken(), newTokenPair.getRefreshToken(), newTokenPair.getAccessExpiresIn()); } public void revokeByUserId(Long userId) { // 管理員強(qiáng)制下線刪除該用戶所有刷新Token SetString keys redisTemplate.keys(REFRESH_KEY_PREFIX userId :*); if (keys ! null !keys.isEmpty()) { redisTemplate.delete(keys); } } }刷新接口的邏輯很簡單前端拿到401響應(yīng)后帶上刷新Token請(qǐng)求/api/auth/refresh服務(wù)端驗(yàn)證刷新Token有效且Redis中有對(duì)應(yīng)記錄然后刪除舊刷新Token生成新的一對(duì)Token返回。這里有一個(gè)細(xì)節(jié)刷新接口本身也要做防盜用處理我要求前端必須在每次刷新時(shí)把舊刷新Token從本地移除并立即替換為新Token。如果檢測(cè)到同一個(gè)刷新Token被使用了兩次說明可能存在Token被竊取的風(fēng)險(xiǎn)我會(huì)把該用戶名下所有的刷新Token全部作廢并要求重新登錄。注意生產(chǎn)環(huán)境里令牌接口必須走HTTPS否則Token在傳輸過程中被截獲前面做的一切安全工作都等于零。這一點(diǎn)不需要討論是強(qiáng)制要求。3.5 密碼加密與校驗(yàn)BCrypt為什么是默認(rèn)選擇密碼存儲(chǔ)方式在企業(yè)級(jí)登錄里是一個(gè)永恒的話題。我見過有人用MD5加鹽來存儲(chǔ)也見過直接明文存儲(chǔ)的“事故現(xiàn)場(chǎng)”——那種系統(tǒng)的審計(jì)報(bào)告我甚至不敢仔細(xì)看。這里我直接給結(jié)論新系統(tǒng)一律用BCrypt舊系統(tǒng)從MD5遷移到BCrypt的方案我也在下面的坑點(diǎn)里詳細(xì)說明。BCrypt的核心特點(diǎn)有三個(gè)。第一內(nèi)置鹽值。每次加密都生成隨機(jī)鹽值同樣的密碼兩次加密的結(jié)果不一樣所以攻擊者無法通過彩虹表直接破解。第二計(jì)算成本可調(diào)。通過代價(jià)因子cost factor控制哈希計(jì)算次數(shù)代價(jià)因子每加1計(jì)算時(shí)間大約翻倍。第三自帶格式。BCrypt的哈希字符串形如$2a$10$7EqJtq8hPqXfYvLbI5Xh0u...其中$2a是算法標(biāo)識(shí)10是代價(jià)因子后面是鹽值和哈希值。BCrypt的使用代碼public class PasswordUtil { // 加密 public static String encode(String rawPassword) { return BCrypt.hashpw(rawPassword, BCrypt.gensalt(10)); } // 校驗(yàn) public static boolean matches(String rawPassword, String encodedPassword) { return BCrypt.checkpw(rawPassword, encodedPassword); } }使用時(shí)的注意點(diǎn)BCrypt有輸入長度限制超過72字節(jié)的密碼會(huì)被截?cái)嗨詷I(yè)務(wù)上要限制密碼最大長度。另外如果你的系統(tǒng)需要從MD5或SHA-256遷移到BCrypt不能簡單地把舊哈希直接換成BCrypt——用戶下次登錄時(shí)需要能校驗(yàn)舊密碼同時(shí)又能無縫升級(jí)。我常用的方案是給用戶憑據(jù)表加一個(gè)credential_version字段舊用戶是V1用MD5校驗(yàn)首次用V1版本密碼成功登錄后立刻把密碼重新用BCrypt加密同時(shí)把版本改為V2后續(xù)登錄走V2校驗(yàn)。這樣用戶無感知地完成了密碼存儲(chǔ)升級(jí)不需要讓所有人都重置密碼。4. 登錄鏈路中的安全防護(hù)細(xì)節(jié)那些看不見的攻防4.1 暴力破解防護(hù)不只是限制失敗次數(shù)暴力破解防護(hù)只做“失敗次數(shù)鎖定”是遠(yuǎn)遠(yuǎn)不夠的。攻擊者如果控制了一批代理IP或者借用分布式節(jié)點(diǎn)來攻擊單純按IP限流很容易被繞過。更靠譜的做法是分層防護(hù)。第一層驗(yàn)證碼。登錄頁的圖形驗(yàn)證碼或滑塊驗(yàn)證碼在前端發(fā)起登錄請(qǐng)求時(shí)必須攜帶。服務(wù)端校驗(yàn)驗(yàn)證碼通過后才繼續(xù)走賬號(hào)密碼校驗(yàn)。驗(yàn)證碼可以放在Redis里5分鐘有效一次性使用。第二層賬號(hào)維度限制。同一賬號(hào)連續(xù)失敗5次鎖定15分鐘鎖定時(shí)間隨失敗次數(shù)遞增比如第6到第10次失敗鎖30分鐘超過10次鎖24小時(shí)。這個(gè)策略要把攻擊者的成本抬得足夠高又不至于影響正常用戶。第三層IP維度的頻率限制。同一IP在單位時(shí)間內(nèi)的登錄請(qǐng)求次數(shù)超過閾值就拒絕比如每分鐘不超過30次每小時(shí)不超過100次。具體閾值要根據(jù)你系統(tǒng)的實(shí)際用戶量調(diào)整核心是防止集中的自動(dòng)化請(qǐng)求。防暴力破解的核心代碼Aspect Component public class LoginAttemptAspect { Autowired private StringRedisTemplate redisTemplate; // 賬號(hào)失敗鎖定Key private static final String ACCOUNT_FAIL_KEY login:fail:account:; // IP失敗鎖定Key private static final String IP_FAIL_KEY login:fail:ip:; public void recordFailure(String username, String ip) { // 賬號(hào)維度 String accountKey ACCOUNT_FAIL_KEY username; Long accountCount redisTemplate.opsForValue().increment(accountKey); if (accountCount ! null accountCount 1) { redisTemplate.expire(accountKey, 15, TimeUnit.MINUTES); } if (accountCount 5) { // 鎖定賬號(hào)15分鐘 String lockKey login:lock:account: username; redisTemplate.opsForValue().set(lockKey, 1, 15, TimeUnit.MINUTES); } // IP維度 String ipKey IP_FAIL_KEY ip; Long ipCount redisTemplate.opsForValue().increment(ipKey); if (ipCount ! null ipCount 1) { redisTemplate.expire(ipKey, 1, TimeUnit.MINUTES); } if (ipCount 30) { // 該IP臨時(shí)拒絕登錄 String ipBlockKey login:block:ip: ip; redisTemplate.opsForValue().set(ipBlockKey, 1, 5, TimeUnit.MINUTES); } } }這套方案在我維護(hù)過的系統(tǒng)里跑了兩三年效果很穩(wěn)定。有個(gè)值得注意的細(xì)節(jié)失敗次數(shù)計(jì)數(shù)器在Redis里要設(shè)置過期時(shí)間不能全程累計(jì)。否則正常用戶可能在連續(xù)幾天內(nèi)偶爾輸錯(cuò)幾次密碼就被累計(jì)到鎖定閾值體驗(yàn)很差。4.2 登錄態(tài)安全防固定會(huì)話攻擊與Token泄露登錄態(tài)安全還有一個(gè)容易忽略的點(diǎn)固定會(huì)話攻擊。攻擊者可以先在自己瀏覽器里登錄一個(gè)合法賬號(hào)拿到一個(gè)有效的會(huì)話ID然后誘導(dǎo)受害者使用這個(gè)會(huì)話ID去登錄。如果系統(tǒng)在登錄成功后沒有更換會(huì)話ID攻擊者就能用同一個(gè)會(huì)話ID冒充受害者。JWT方案同樣存在這個(gè)問題所以我在登錄成功后簽發(fā)的Token里會(huì)帶一個(gè)隨機(jī)字符串jti并確保每次登錄都重新生成不同設(shè)備、不同會(huì)話之間互相獨(dú)立。還有一個(gè)和業(yè)務(wù)強(qiáng)相關(guān)的細(xì)節(jié)賬號(hào)同時(shí)多端登錄怎么處理。有的系統(tǒng)要求一個(gè)人只能同時(shí)在一個(gè)設(shè)備上登錄新的登錄會(huì)踢掉舊的有的系統(tǒng)允許多端共存但要做設(shè)備管理列表。我建議做設(shè)備管理查登錄日志時(shí)能清晰看到“哪個(gè)用戶、什么時(shí)間、用什么設(shè)備登錄”這在安全審計(jì)時(shí)非常重要。我的實(shí)現(xiàn)是在刷新Token里加入設(shè)備標(biāo)識(shí)登錄時(shí)前端傳入設(shè)備編號(hào)不傳則根據(jù)User-Agent生成唯一標(biāo)識(shí)。記錄設(shè)備信息不是為了炫技而是為了讓用戶能在“賬號(hào)安全中心”里看到自己的登錄設(shè)備列表一旦發(fā)現(xiàn)陌生設(shè)備可以直接踢下線。4.3 登錄日志與審計(jì)出了事拿得出數(shù)據(jù)登錄日志這塊很多團(tuán)隊(duì)會(huì)拖到出安全事故后才想起來補(bǔ)。但企業(yè)級(jí)系統(tǒng)的登錄入口我一定會(huì)在設(shè)計(jì)階段就把審計(jì)日志做進(jìn)去。登錄日志至少需要包含這些字段用戶ID、用戶名、登錄時(shí)間、登錄IP、設(shè)備信息、登錄結(jié)果成功/失敗、失敗原因。我的日志表設(shè)計(jì)如下CREATE TABLE sys_login_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT, username VARCHAR(64), login_ip VARCHAR(64), device_info VARCHAR(256), user_agent VARCHAR(512), login_result TINYINT COMMENT 1:成功 2:密碼錯(cuò)誤 3:賬號(hào)鎖定 4:驗(yàn)證碼錯(cuò)誤, fail_reason VARCHAR(128), login_time DATETIME, INDEX idx_user_time (user_id, login_time), INDEX idx_ip_time (login_ip, login_time) );寫日志的時(shí)機(jī)要選好成功日志在Token簽發(fā)后記錄失敗日志在每一步失敗分支里記錄。日志的數(shù)據(jù)量會(huì)增長很快我建議按天做分區(qū)保留最近90天超過時(shí)間的歸檔到冷存儲(chǔ)。審計(jì)日志絕對(duì)不能只存在應(yīng)用服務(wù)器本地磁盤要統(tǒng)一匯總到日志中心否則服務(wù)器一旦重新部署數(shù)據(jù)就丟了。我個(gè)人在實(shí)際排查問題時(shí)發(fā)現(xiàn)用戶忘記密碼是最常見的工單類型。有了登錄日志客服可以直接看到用戶是不是被鎖定、鎖定時(shí)間到什么時(shí)候能很快判斷是攻擊導(dǎo)致的鎖定還是用戶自己輸錯(cuò)太多次。這個(gè)價(jià)值在實(shí)際運(yùn)維中非常明顯。5. 實(shí)操過程記錄從零搭建到線上穩(wěn)定運(yùn)行5.1 環(huán)境準(zhǔn)備我這邊使用的環(huán)境是一臺(tái)4核8G的開發(fā)機(jī)安裝CentOS 7系統(tǒng)、Docker、MySQL 8.0、Redis 6.0。企業(yè)級(jí)登錄模塊的開發(fā)和部署我建議至少把MySQL和Redis用Docker單獨(dú)跑起來方便重置環(huán)境。簡單貼一下啟動(dòng)命令# 啟動(dòng)MySQL docker run -d --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDyourpassword \ -e MYSQL_DATABASEenterprise_auth \ mysql:8.0 # 啟動(dòng)Redis docker run -d --name redis6 \ -p 6379:6379 \ redis:6.0 --requirepass yourredispassword表結(jié)構(gòu)按照上面的SQL建好之后插入一個(gè)測(cè)試賬號(hào)INSERT INTO sys_user (username, real_name) VALUES (tester, 測(cè)試用戶); INSERT INTO sys_user_credential (user_id, credential_type, password_hash) VALUES (1, PASSWORD, $2a$10$...); -- 用BCrypt加密后的值5.2 登錄接口調(diào)試過程我習(xí)慣用Postman做初步調(diào)試。登錄接口的請(qǐng)求體{ username: tester, password: Test123456, captcha: 8F2A }調(diào)試時(shí)重點(diǎn)關(guān)注三個(gè)響應(yīng)登錄成功的200響應(yīng)、密碼錯(cuò)誤的401響應(yīng)、賬號(hào)鎖定的403響應(yīng)。響應(yīng)體里的錯(cuò)誤碼要設(shè)計(jì)清楚前端才能根據(jù)不同錯(cuò)誤類型給出不同提示。我常用的錯(cuò)誤碼定義是1001驗(yàn)證碼錯(cuò)誤1002用戶名或密碼錯(cuò)誤1003賬號(hào)已鎖定1004賬號(hào)已禁用1005登錄狀態(tài)已過期前端根據(jù)錯(cuò)誤碼提示相應(yīng)文案而不是直接把后端的錯(cuò)誤信息透出。這里有一個(gè)細(xì)節(jié)后端的錯(cuò)誤信息盡量別給前端展示統(tǒng)一轉(zhuǎn)成錯(cuò)誤碼否則會(huì)存在信息泄露風(fēng)險(xiǎn)也容易被攻擊者利用細(xì)節(jié)來枚舉用戶狀態(tài)。5.3 配置Spring Security放行登錄接口Spring Security默認(rèn)會(huì)攔截所有請(qǐng)求登錄接口本身要放行但刷新接口不能直接放行——刷新接口要單獨(dú)走一套校驗(yàn)邏輯。我的配置思路是Configuration EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests() .antMatchers(/api/auth/login).permitAll() // 登錄接口放行 .antMatchers(/api/auth/captcha).permitAll() // 驗(yàn)證碼接口放行 .anyRequest().authenticated() .and() .addFilterBefore(jwtAuthFilter, UsernamePasswordAuthenticationFilter.class); } }JWT過濾器的邏輯是從請(qǐng)求頭Authorization里取Token解析成功就向SecurityContext寫入認(rèn)證信息解析失敗則返回401。過濾器的代碼不復(fù)雜但有一個(gè)細(xì)節(jié)Token過期返回的401和未攜帶Token返回的401響應(yīng)體的錯(cuò)誤碼要一致不能給攻擊者區(qū)分“這個(gè)接口需要登錄”和“這個(gè)Token剛好過期”的機(jī)會(huì)。5.4 前端登錄流程對(duì)接前端拿到Token后的存儲(chǔ)位置我這里直接給出結(jié)論訪問Token只能放在內(nèi)存里刷新Token放在HttpOnly Cookie里。如果前端把兩個(gè)Token都放進(jìn)localStorage一旦出現(xiàn)跨站腳本漏洞Token會(huì)整個(gè)被偷走。放在HttpOnly Cookie里的刷新Token腳本拿不到安全級(jí)別高很多。我設(shè)計(jì)的前端登錄對(duì)接邏輯是頁面加載時(shí)先嘗試用刷新Token靜默換取訪問Token換不到就跳轉(zhuǎn)登錄頁登錄頁成功后拿到訪問Token刷新Token通過Set-Cookie種入。每次請(qǐng)求時(shí)攜帶訪問Token收到401時(shí)嘗試刷新刷新成功則重放原請(qǐng)求刷新失敗則跳回登錄頁。這套流程跑起來很順滑用戶基本感覺不到會(huì)話快過期這件事。6. 常見問題與排查技巧實(shí)錄6.1 用戶登錄后頻繁掉線這是我自己排查過最多的問題類型之一?，F(xiàn)象是用戶登錄成功但沒過多久就收到401。排查步驟我建議按下面順序走第一步看訪問Token過期時(shí)間是否太短。如果你把訪問Token設(shè)成了5分鐘甚至更短那用戶操作稍微磨蹭一點(diǎn)Token就過期了。我建議至少15分鐘配合刷新機(jī)制使用。第二步看前端是否正確處理了401刷新邏輯。很多前端代碼只在攔截器里做了“彈回登錄頁”沒有做“先用刷新Token靜默換新Token”。這種實(shí)現(xiàn)下Token一過期用戶就得重新登錄。正確做法是先嘗試靜默刷新刷新失敗再跳登錄頁。第三步看服務(wù)端時(shí)鐘是否同步。如果應(yīng)用服務(wù)器的時(shí)間比認(rèn)證授權(quán)服務(wù)器快或者慢Token的exp和iat字段就會(huì)出現(xiàn)偏差導(dǎo)致明明沒過期卻被判為過期。用NTP確保服務(wù)器時(shí)間同步這步常被忽略。6.2 Redis里刷新Token明明存在但刷新一直失敗我遇到過一次很詭異的場(chǎng)景刷新Token發(fā)過去了Redis里也能查到Key但服務(wù)端一直報(bào)“登錄狀態(tài)已過期”。查了很久最后發(fā)現(xiàn)是解析JWT的密鑰配置不一致——簽發(fā)Refresh Token用的密鑰和應(yīng)用啟動(dòng)時(shí)加載的密鑰不是同一個(gè)。如果你把密鑰放在配置中心務(wù)必確認(rèn)各環(huán)境配置的一致性。另一個(gè)可能原因是Redis的Key過期策略。我在前面代碼里給刷新Token設(shè)置了7天過期但如果用戶在7天內(nèi)頻繁活躍我一直建議在每次刷新時(shí)順帶延長刷新Token的過期時(shí)間也就是“滑動(dòng)過期”。如果沒做滑動(dòng)過期用戶哪怕天天在用系統(tǒng)登錄狀態(tài)也會(huì)在第7天準(zhǔn)時(shí)失效。這個(gè)體驗(yàn)很糟糕。我的做法是每次刷新成功后重新設(shè)置刷新Token的過期時(shí)間為7天。6.3 驗(yàn)證碼明明對(duì)了卻總是提示錯(cuò)誤驗(yàn)證碼問題的高發(fā)原因有兩個(gè)。第一驗(yàn)證碼使用一次后沒有刪除Redis中的緩存導(dǎo)致同一個(gè)驗(yàn)證碼可以重復(fù)使用前端又每次提交同一個(gè)驗(yàn)證碼后端一刪就再也對(duì)不上了所以會(huì)“明明對(duì)了但提示錯(cuò)誤”。第二驗(yàn)證碼的存儲(chǔ)Key生成的邏輯不一致。比如生成時(shí)用captcha:{uuid}校驗(yàn)時(shí)用captcha:uuid大小寫或分隔符不一致自然匹配不上。寫代碼時(shí)我強(qiáng)烈建議統(tǒng)一封裝一個(gè)驗(yàn)證碼服務(wù)生成和校驗(yàn)都走同一套Key拼接邏輯不要一個(gè)地方手寫一個(gè)Key。6.4 跨域場(chǎng)景下的Cookie和Token問題前后端分離的項(xiàng)目前端部署在app.example.com后端部署在api.example.com這是最常見的跨域場(chǎng)景?？缬虮旧聿浑y但有一個(gè)坑刷新Token放在HttpOnly Cookie里跨域請(qǐng)求時(shí)默認(rèn)不會(huì)攜帶Cookie。需要在后端配置CORS時(shí)設(shè)置allowCredentials(true)同時(shí)前端請(qǐng)求要帶上withCredentials。如果前端和后端的主域名不同比如前端是example.com后端是auth.anotherdomain.comCookie跨域攜帶就要設(shè)置Domain屬性。但Cookie的Domain不能跨完全不同的頂級(jí)域名這種場(chǎng)景下要么做代理轉(zhuǎn)發(fā)要么改用其它會(huì)話方案。我在實(shí)際項(xiàng)目里更推薦的做法是前端Nginx把/api路徑反向代理到后端服務(wù)這樣瀏覽器看到的請(qǐng)求是同源的Cookie方案能用CORS也不用額外開放。簡單直接問題最少。6.5 密碼升級(jí)遷移踩坑記錄最后分享一個(gè)舊系統(tǒng)改造的案例很有代表性。某系統(tǒng)原來用MD5存儲(chǔ)密碼用戶量好幾萬不可能讓所有人重置密碼。我接手后做了兩步改造第一步新增credential_version字段默認(rèn)V1。登錄接口邏輯改成根據(jù)用戶當(dāng)前版本走對(duì)應(yīng)的校驗(yàn)邏輯。V1的走M(jìn)D5校驗(yàn)校驗(yàn)成功后立即用BCrypt重算密碼哈希把版本升到V2。這樣所有用戶在自己下次登錄時(shí)完成無感升級(jí)。第二步在系統(tǒng)中加入密碼強(qiáng)度校驗(yàn)。新注冊(cè)或修改密碼時(shí)強(qiáng)制要求密碼長度不少于8位且包含大小寫字母、數(shù)字、特殊字符中至少三類。歷史不良密碼在升級(jí)時(shí)也要求用戶重置一次。整個(gè)遷移過程平穩(wěn)落地沒有產(chǎn)生一條“密碼失效”的工單。7. 最后的幾點(diǎn)心得登錄功能寫到這里我覺得最有價(jià)值的反而不是代碼而是對(duì)整個(gè)系統(tǒng)的安全邊界意識(shí)。企業(yè)級(jí)登錄流程涉及的東西非常多——Token策略、密碼存儲(chǔ)、暴力破解防護(hù)、審計(jì)日志、跨域處理、密碼升級(jí)——每一項(xiàng)單拎出來都不算難但組合在一起任何一個(gè)環(huán)節(jié)的疏忽都會(huì)成為攻擊者的突破口。我個(gè)人的體會(huì)是設(shè)計(jì)登錄模塊時(shí)永遠(yuǎn)要問自己三個(gè)問題如果數(shù)據(jù)庫泄露用戶的密碼安全嗎如果Token被截獲攻擊者能獲取哪些數(shù)據(jù)如果登錄接口被刷系統(tǒng)能支撐住嗎這三個(gè)問題全部能給出清晰答案你的登錄模塊才算真正達(dá)到了企業(yè)級(jí)要求。還有一點(diǎn)想強(qiáng)調(diào)登錄這個(gè)模塊改起來牽扯面很大上線前一定要做完整的回歸測(cè)試尤其是Token刷新、賬號(hào)鎖定、強(qiáng)制下線這幾個(gè)場(chǎng)景。我踩過最痛的一次坑就是上線時(shí)只測(cè)了“登錄成功”這條快樂路徑完全沒有覆蓋“Token過期后續(xù)期”的場(chǎng)景結(jié)果線上第一個(gè)小時(shí)就收到一堆“系統(tǒng)自動(dòng)退出”的反饋灰溜溜地回滾版本。從那以后我給自己立了個(gè)規(guī)矩登錄模塊的功能清單里永遠(yuǎn)把異常場(chǎng)景放到和正常場(chǎng)景同等重要的位置去測(cè)試。這篇文章里的代碼和方案我都實(shí)際用過可以直接作為你項(xiàng)目里的初始版本去改造。如果你的場(chǎng)景和我的有些差異比如用了別的后端語言或者需要考慮更復(fù)雜的權(quán)限模型核心的流程設(shè)計(jì)和安全思路依然可以復(fù)用。登錄是系統(tǒng)的門面值得你多花些心思去打磨。