1. 项目概述为什么Token是现代登录的基石聊到登录功能很多刚入行的朋友可能还停留在“用户名密码”的初级阶段或者听说过Session和Cookie。但如果你现在去面试或者接手一个稍微有点规模的Web项目面试官或团队Leader问你登录怎么设计你要是还只提Session那可能就有点落伍了。今天我们就来彻底拆解一下用Token实现登录功能的具体实现这几乎是现代前后端分离架构下的标准答案。简单来说Token令牌就是一个字符串它承载了用户的身份信息是客户端比如浏览器、手机App在通过首次认证后从服务器拿到的一张“临时通行证”。之后客户端每次请求受保护的资源比如查看个人资料、下单购物只需要出示这张通行证即可无需再反复输入用户名和密码。这种方式完美解决了传统Session方案在分布式、跨域场景下的痛点。我们常说的JWTJSON Web Token就是Token的一种非常流行和标准的实现格式。接下来我不会只讲空洞的概念而是会手把手带你从零搭建一个完整的、生产可用的Token登录体系涵盖生成、发放、验证、刷新、安全防护等全链路细节并分享我踩过的无数个坑。2. 登录方案演进与Token的核心优势在深入代码之前我们必须搞清楚为什么Token方案会脱颖而出。这有助于我们在设计时做出更明智的抉择。2.1 从Session到Token的必然之路早期的Web应用普遍采用Session-Cookie机制。流程大致是用户登录服务器在内存或数据库中创建一个Session对象来保存用户状态如userId并生成一个唯一的Session ID返回给浏览器通常通过Set-Cookie头存入Cookie。浏览器后续请求会自动带上这个Cookie服务器通过Session ID找到对应的Session从而识别用户。这个方案在单体应用时代工作良好但面临三大挑战扩展性差Session通常存储在单台服务器的内存中。当用户量激增需要部署多台服务器集群时来自同一用户的请求可能被负载均衡到不同的服务器上而另一台服务器上没有对应的Session导致用户需要重新登录。虽然可以通过Session共享如Redis解决但引入了额外的复杂度和网络开销。跨域问题在前后端分离架构下前端项目如React/Vue应用运行在localhost:3000后端API在api.yourdomain.com浏览器出于安全考虑会限制跨域请求自动携带Cookie需要额外配置CORS with credentials比较麻烦。对移动端/API不友好原生App或第三方API调用者并非浏览器没有Cookie机制使用Session会非常别扭。2.2 Token方案如何破局Token方案的核心思想是“无状态”。服务器在验证用户凭证如密码后生成一个包含用户身份信息的Token通常是JWT格式将其返回给客户端。服务器不再保存这个Token客户端需要自己妥善保管如存放在LocalStorage、内存或安全存储中。此后客户端每次请求都在HTTP Header通常是Authorization: Bearer token中携带此Token。服务器收到后只需用预先约定好的密钥或公钥验证Token的合法性和有效性是否被篡改、是否过期即可从中解析出用户身份。它的优势显而易见无状态与扩展性服务器无需保存会话状态任何一台拥有验证密钥的服务器都可以独立验证Token天然支持分布式部署。跨域与多端支持Token通过HTTP Header传输完美规避了Cookie的跨域限制对Web、App、第三方API调用一视同仁。安全性可控Token可以设置较短的有效期如15分钟降低被盗用的风险。结合Refresh Token刷新令牌机制可以在用户无感知的情况下更新Token平衡安全与体验。注意Token并非银弹。它把状态管理的责任从服务器转移到了客户端和Token本身。一旦Token签发在有效期内无法主动使其失效除非使用黑名单机制但这又引入了状态因此对Token的安全存储和传输提出了更高要求。3. JWTToken的标准化实现当我们说Token登录时十有八九指的是JWT。它是一种开放标准RFC 7519定义了一种紧凑且自包含的方式用于在各方之间安全地传输信息作为JSON对象。3.1 JWT的结构解剖一个JWT看起来像这样xxxxx.yyyyy.zzzzz由三部分组成用点.分隔。Header头部一个JSON对象描述Token的类型和使用的签名算法如HMAC SHA256或RSA。它会进行Base64Url编码形成第一部分。{ alg: HS256, typ: JWT }Payload负载一个JSON对象包含了要传递的声明Claims。声明分为三种注册声明预定义的一些声明如iss签发者、exp过期时间、sub主题等。公共声明可以自定义的声明但为了避免冲突应使用IANA JSON Web Token Registry中定义的名字或者是一个包含防冲突命名空间的URI。私有声明自定义的声明用于在同意使用它们的各方之间共享信息。 例如{ sub: 1234567890, name: John Doe, iat: 1516239022, exp: 1516242622 }Payload也会进行Base64Url编码形成第二部分。请注意这部分只是编码并非加密任何人都可以解码看到内容。所以绝对不要在其中存放敏感信息如密码。Signature签名这是最关键的部分用于防止Token被篡改。签名通过对编码后的Header、编码后的Payload、一个密钥Secret以及Header中指定的算法生成。HMACSHA256( base64UrlEncode(header) . base64UrlEncode(payload), secret)最终将这三部分用点连接起来就形成了一个完整的JWT。3.2 签名与验证安全性的核心签名的存在是JWT安全的基石。服务器使用一个只有自己知道的密钥对于HMAC算法或私钥对于RSA算法来生成签名。当客户端将Token发回时服务器用同样的密钥/公钥重新计算签名并与Token中的签名部分进行比对。如果一致说明Token在传输过程中未被篡改因为攻击者不知道密钥无法伪造签名同时也能验证签发者身份。4. 实战构建完整的Token登录系统理论说再多不如一行代码。我们以Node.jsExpress框架和前端Vue为例构建一个最小可用的系统。其他语言框架如Spring Boot, Django原理完全相通。4.1 后端实现Node.js Express首先初始化项目并安装依赖npm init -y npm install express jsonwebtoken bcryptjs dotenvexpress: Web框架。jsonwebtoken: 用于生成和验证JWT的主流库。bcryptjs: 用于安全地哈希用户密码永远不要明文存储密码。dotenv: 管理环境变量如密钥。步骤1环境配置与模拟数据库创建.env文件存放密钥JWT_SECRETyour_super_secret_key_at_least_32_chars_long JWT_REFRESH_SECRETyour_super_secret_refresh_key ACCESS_TOKEN_EXPIRY15m // Access Token 15分钟过期 REFRESH_TOKEN_EXPIRY7d // Refresh Token 7天过期创建一个简单的app.js并模拟一个用户数据库require(dotenv).config(); const express require(express); const jwt require(jsonwebtoken); const bcrypt require(bcryptjs); const app express(); app.use(express.json()); // 模拟数据库中的用户表 const users []; const refreshTokens []; // 用于存储有效的刷新令牌生产环境用Redis // 密码哈希函数 const hashPassword async (password) await bcrypt.hash(password, 10); const comparePassword async (password, hash) await bcrypt.compare(password, hash);步骤2用户注册与登录接口// 用户注册 app.post(/api/register, async (req, res) { try { const { username, password } req.body; // 1. 检查用户是否存在 const userExists users.find(u u.username username); if (userExists) { return res.status(400).json({ message: 用户已存在 }); } // 2. 哈希密码 const hashedPassword await hashPassword(password); // 3. 保存用户模拟 const newUser { id: Date.now().toString(), username, password: hashedPassword }; users.push(newUser); // 4. 返回成功注意不要返回密码哈希 res.status(201).json({ message: 注册成功, userId: newUser.id }); } catch (error) { res.status(500).json({ message: 服务器内部错误 }); } }); // 用户登录核心 app.post(/api/login, async (req, res) { try { const { username, password } req.body; // 1. 查找用户 const user users.find(u u.username username); if (!user) { return res.status(401).json({ message: 用户名或密码错误 }); } // 2. 验证密码 const isPasswordValid await comparePassword(password, user.password); if (!isPasswordValid) { return res.status(401).json({ message: 用户名或密码错误 }); } // 3. 生成Access Token (JWT) const accessToken jwt.sign( { userId: user.id, username: user.username }, // Payload process.env.JWT_SECRET, { expiresIn: process.env.ACCESS_TOKEN_EXPIRY } ); // 4. 生成Refresh Token (也是一个JWT但用途单一仅用于刷新) const refreshToken jwt.sign( { userId: user.id }, process.env.JWT_REFRESH_SECRET, { expiresIn: process.env.REFRESH_TOKEN_EXPIRY } ); // 5. 存储Refresh Token生产环境应存Redis并设置TTL refreshTokens.push(refreshToken); // 6. 返回Tokens注意Refresh Token应通过HttpOnly Cookie返回更安全此处为演示用JSON res.json({ accessToken, refreshToken, tokenType: Bearer, expiresIn: 900 // 15分钟单位秒 }); } catch (error) { res.status(500).json({ message: 登录失败 }); } });步骤3受保护的路由与Token验证中间件这是核心中的核心。我们需要一个中间件来拦截请求验证Token。// JWT验证中间件 const authenticateJWT (req, res, next) { const authHeader req.headers.authorization; if (authHeader) { // 格式应为 Bearer token const token authHeader.split( )[1]; jwt.verify(token, process.env.JWT_SECRET, (err, user) { if (err) { // Token过期或无效 return res.status(403).json({ message: Token无效或已过期 }); } // 验证成功将用户信息挂载到req对象上供后续路由使用 req.user user; next(); }); } else { res.status(401).json({ message: 缺少认证令牌 }); } }; // 一个受保护的用户信息接口 app.get(/api/profile, authenticateJWT, (req, res) { // 此时req.user已包含从Token解析出的信息 res.json({ message: 这是你的个人资料, user: req.user }); });步骤4Token刷新接口Access Token过期后不应让用户重新登录而是使用Refresh Token来获取新的Access Token。app.post(/api/refresh-token, (req, res) { const { refreshToken } req.body; if (!refreshToken) { return res.status(401).json({ message: 缺少刷新令牌 }); } // 检查刷新令牌是否在我们的有效列表中防止被盗用 if (!refreshTokens.includes(refreshToken)) { return res.status(403).json({ message: 刷新令牌无效 }); } jwt.verify(refreshToken, process.env.JWT_REFRESH_SECRET, (err, user) { if (err) { return res.status(403).json({ message: 刷新令牌无效或已过期 }); } // 刷新令牌有效生成新的Access Token const newAccessToken jwt.sign( { userId: user.userId, username: user.username }, process.env.JWT_SECRET, { expiresIn: process.env.ACCESS_TOKEN_EXPIRY } ); res.json({ accessToken: newAccessToken, tokenType: Bearer, expiresIn: 900 }); }); }); // 用户登出使Refresh Token失效 app.post(/api/logout, (req, res) { const { refreshToken } req.body; const index refreshTokens.indexOf(refreshToken); if (index -1) { refreshTokens.splice(index, 1); // 从列表中移除 } res.json({ message: 登出成功 }); });4.2 前端实现Vue 3 Axios前端主要负责三件事登录时获取并存储Token发起请求时自动携带TokenToken过期时自动刷新。步骤1登录并存储Tokentemplate form submit.preventhandleLogin input v-modelusername placeholder用户名/ input v-modelpassword typepassword placeholder密码/ button typesubmit登录/button /form /template script setup import { ref } from vue; import axios from axios; const username ref(); const password ref(); const handleLogin async () { try { const response await axios.post(http://localhost:3000/api/login, { username: username.value, password: password.value }); const { accessToken, refreshToken } response.data; // 存储TokenAccess Token存内存或LocalStorageRefresh Token建议存HttpOnly Cookie更安全或安全存储 localStorage.setItem(accessToken, accessToken); localStorage.setItem(refreshToken, refreshToken); // 注意这不够安全仅演示 console.log(登录成功); // 跳转到主页... } catch (error) { console.error(登录失败:, error.response?.data?.message); } }; /script步骤2配置Axios拦截器自动携带Token这是前端实现无感认证的关键。创建一个axios实例并配置请求/响应拦截器。// utils/request.js import axios from axios; const service axios.create({ baseURL: http://localhost:3000/api, timeout: 10000, }); // 请求拦截器在每次请求前将Token放入Header service.interceptors.request.use( (config) { const token localStorage.getItem(accessToken); if (token) { config.headers.Authorization Bearer ${token}; } return config; }, (error) { return Promise.reject(error); } ); // 响应拦截器处理Token过期自动刷新 service.interceptors.response.use( (response) { return response; }, async (error) { const originalRequest error.config; // 如果是401错误通常是Token过期且不是刷新Token的请求本身尝试刷新 if (error.response?.status 401 !originalRequest._retry) { originalRequest._retry true; // 标记此请求已重试防止循环 try { const refreshToken localStorage.getItem(refreshToken); const refreshResponse await axios.post(http://localhost:3000/api/refresh-token, { refreshToken }); const newAccessToken refreshResponse.data.accessToken; localStorage.setItem(accessToken, newAccessToken); // 用新的Token重试原来的请求 originalRequest.headers.Authorization Bearer ${newAccessToken}; return service(originalRequest); } catch (refreshError) { // 刷新也失败跳转到登录页 console.error(刷新Token失败需要重新登录, refreshError); localStorage.clear(); window.location.href /login; return Promise.reject(refreshError); } } // 其他错误直接抛出 return Promise.reject(error); } ); export default service;然后在你的组件或页面中导入这个配置好的service来发起请求它将自动处理Token的携带和刷新。5. 高级话题与安全加固一个基础的Token系统搭建完成了但要用于生产环境还有大量的细节和安全考量。5.1 Token存储的安全博弈前端如何存储Token是一个经典的安全与便利的权衡问题。LocalStorage/SessionStorage易于实现但面临XSS跨站脚本攻击风险。如果网站存在XSS漏洞攻击者可以窃取存储在其中的Token。HttpOnly Cookie能有效防御XSS因为JavaScript无法读取HttpOnly Cookie但可能面临CSRF跨站请求伪造攻击需要配合CSRF Token等策略。同时在跨域场景下配置稍复杂。内存存储关闭标签页即消失最安全但用户体验差刷新页面就要重新登录。我的实践建议对于需要较高安全性的应用如金融采用“Access Token短有效期 Refresh Token存HttpOnly Cookie”的模式。对于一般应用可以将Access Token存于内存或短期Storage并确保网站完全没有XSS漏洞通过CSP等策略。5.2 如何实现Token的主动失效JWT一旦签发在过期前无法主动作废这是其“无状态”特性带来的副作用。如果用户修改密码或管理员封禁用户需要立即使其Token失效怎么办黑名单机制将需要失效的Token的IDJWT标准中的jti声明或Token本身存入一个黑名单如Redis并设置与Token过期时间一致的TTL。在验证Token时除了检查签名和过期时间还要查询黑名单。这实际上引入了一个“状态”但通常是可以接受的折中方案。短期Token 状态化Session回归本质使用非常短期的Token如5分钟并将用户状态是否有效存于Redis。每次验证Token时都去Redis检查一次用户状态。这相当于一个轻量级的、可扩展的Session。5.3 防范常见攻击重放攻击攻击者截获一个有效的Token在过期前重复使用。可以通过在Payload中加入jtiJWT ID、iat签发时间并结合服务器端的短期缓存如最近5分钟内使用过的jti来防止但这同样引入了状态。更通用的做法是依赖HTTPS和Token的短有效期来降低风险。令牌泄露确保Token只在HTTPS下传输。避免在URL参数中传递Token可能被日志记录。前端小心XSS。签名算法混淆攻击确保在验证Token时明确指定算法如jwt.verify(token, secret, { algorithms: [HS256] })防止攻击者强制使用none算法。6. 生产环境部署与运维心得把代码跑起来只是第一步让它稳定、安全地服务海量用户才是真正的挑战。6.1 密钥管理命脉所在JWT_SECRET是系统的命门一旦泄露攻击者可以伪造任意用户的Token。绝对不要将密钥硬编码在代码中或提交到版本控制系统如Git。必须使用环境变量或专业的密钥管理服务如AWS Secrets Manager, HashiCorp Vault。密钥需要足够长且随机建议使用openssl rand -base64 32命令生成。定期轮换密钥制定策略定期更新密钥。旧密钥需要在一定宽限期如所有已签发Token的最大有效期内仍能验证新签发的Token使用新密钥。6.2 性能与监控验证开销JWT验证涉及密码学运算虽然单次很快但在超高QPS下仍需关注。确保服务器有足够的CPU资源。监控Token相关错误在日志和监控系统如Prometheus, ELK中重点关注401 Unauthorized和403 Forbidden错误。错误率突然升高可能意味着攻击或客户端逻辑问题。设置合理的过期时间Access Token建议15-30分钟Refresh Token建议7天。根据业务安全等级调整。6.3 我踩过的那些“坑”时钟偏移问题服务器集群中如果各机器系统时间不同步可能导致Token验证失败exp过期判断不准。务必使用NTP服务确保所有服务器时间同步。日志泄露Token不小心将包含Authorization头的请求打印到应用日志中导致Token泄露。务必在日志中间件中过滤掉敏感头信息。前端路由守卫的异步问题在Vue Router或React Router的全局守卫中发起Token刷新请求是异步的如果多个路由跳转同时发生可能触发多次刷新。需要用一个标志位或Promise队列来防止重复刷新。移动端Token持久化在React Native或Flutter中不要用AsyncStorage或SharedPreferences明文存储Token。使用如react-native-keychain或flutter_secure_storage这类安全存储方案。7. 总结与扩展方向通过以上的拆解你应该已经掌握了从原理到实践构建一个健壮的Token登录系统的全部关键点。从简单的jsonwebtoken.sign和verify到考虑无状态与有状态的折中再到前端拦截器的精妙配合每一个环节都蕴含着对安全、体验和架构的思考。这个系统还可以向更多方向扩展单点登录SSO多个子系统使用同一个认证中心。这时Token通常是OAuth 2.0的Access Token会在中心签发在各个子系统间流通和验证。权限控制RBAC将用户角色如admin,user或权限列表如[article:read, user:write]作为声明Claims放入JWT的Payload中。后端在验证Token后直接从Payload解析权限无需再查数据库实现高效的接口级权限校验。扫码登录其本质是桌面端生成一个临时Token二维码移动端扫码后确认登录将这个临时Token与移动端已登录的用户身份绑定然后桌面端轮询获取最终的Access Token。最后记住没有完美的方案。Token方案在带来扩展性和灵活性的同时也将状态管理的复杂性和安全责任进行了转移。理解其原理看清其利弊根据你的实际业务场景用户量、安全要求、技术栈做出最适合的选型和设计才是工程师价值的体现。在实际项目中我通常会画出一个清晰的序列图标出Token的生成、传递、验证、刷新全流程并与团队成员评审确保每个人都理解数据是如何流动的安全边界在哪里。这比盲目套用任何一个“最佳实践”都重要得多。 
长河君 · 2026/8/7 23:51:41 · 阅读 1.2k 从Session到JWT：构建现代Web应用的无状态登录认证系统
1. 项目概述为什么Token是现代登录的基石聊到登录功能很多刚入行的朋友可能还停留在“用户名密码”的初级阶段或者听说过Session和Cookie。但如果你现在去面试或者接手一个稍微有点规模的Web项目面试官或团队Leader问你登录怎么设计你要是还只提Session那可能就有点落伍了。今天我们就来彻底拆解一下用Token实现登录功能的具体实现这几乎是现代前后端分离架构下的标准答案。简单来说Token令牌就是一个字符串它承载了用户的身份信息是客户端比如浏览器、手机App在通过首次认证后从服务器拿到的一张“临时通行证”。之后客户端每次请求受保护的资源比如查看个人资料、下单购物只需要出示这张通行证即可无需再反复输入用户名和密码。这种方式完美解决了传统Session方案在分布式、跨域场景下的痛点。我们常说的JWTJSON Web Token就是Token的一种非常流行和标准的实现格式。接下来我不会只讲空洞的概念而是会手把手带你从零搭建一个完整的、生产可用的Token登录体系涵盖生成、发放、验证、刷新、安全防护等全链路细节并分享我踩过的无数个坑。2. 登录方案演进与Token的核心优势在深入代码之前我们必须搞清楚为什么Token方案会脱颖而出。这有助于我们在设计时做出更明智的抉择。2.1 从Session到Token的必然之路早期的Web应用普遍采用Session-Cookie机制。流程大致是用户登录服务器在内存或数据库中创建一个Session对象来保存用户状态如userId并生成一个唯一的Session ID返回给浏览器通常通过Set-Cookie头存入Cookie。浏览器后续请求会自动带上这个Cookie服务器通过Session ID找到对应的Session从而识别用户。这个方案在单体应用时代工作良好但面临三大挑战扩展性差Session通常存储在单台服务器的内存中。当用户量激增需要部署多台服务器集群时来自同一用户的请求可能被负载均衡到不同的服务器上而另一台服务器上没有对应的Session导致用户需要重新登录。虽然可以通过Session共享如Redis解决但引入了额外的复杂度和网络开销。跨域问题在前后端分离架构下前端项目如React/Vue应用运行在localhost:3000后端API在api.yourdomain.com浏览器出于安全考虑会限制跨域请求自动携带Cookie需要额外配置CORS with credentials比较麻烦。对移动端/API不友好原生App或第三方API调用者并非浏览器没有Cookie机制使用Session会非常别扭。2.2 Token方案如何破局Token方案的核心思想是“无状态”。服务器在验证用户凭证如密码后生成一个包含用户身份信息的Token通常是JWT格式将其返回给客户端。服务器不再保存这个Token客户端需要自己妥善保管如存放在LocalStorage、内存或安全存储中。此后客户端每次请求都在HTTP Header通常是Authorization: Bearer token中携带此Token。服务器收到后只需用预先约定好的密钥或公钥验证Token的合法性和有效性是否被篡改、是否过期即可从中解析出用户身份。它的优势显而易见无状态与扩展性服务器无需保存会话状态任何一台拥有验证密钥的服务器都可以独立验证Token天然支持分布式部署。跨域与多端支持Token通过HTTP Header传输完美规避了Cookie的跨域限制对Web、App、第三方API调用一视同仁。安全性可控Token可以设置较短的有效期如15分钟降低被盗用的风险。结合Refresh Token刷新令牌机制可以在用户无感知的情况下更新Token平衡安全与体验。注意Token并非银弹。它把状态管理的责任从服务器转移到了客户端和Token本身。一旦Token签发在有效期内无法主动使其失效除非使用黑名单机制但这又引入了状态因此对Token的安全存储和传输提出了更高要求。3. JWTToken的标准化实现当我们说Token登录时十有八九指的是JWT。它是一种开放标准RFC 7519定义了一种紧凑且自包含的方式用于在各方之间安全地传输信息作为JSON对象。3.1 JWT的结构解剖一个JWT看起来像这样xxxxx.yyyyy.zzzzz由三部分组成用点.分隔。Header头部一个JSON对象描述Token的类型和使用的签名算法如HMAC SHA256或RSA。它会进行Base64Url编码形成第一部分。{ alg: HS256, typ: JWT }Payload负载一个JSON对象包含了要传递的声明Claims。声明分为三种注册声明预定义的一些声明如iss签发者、exp过期时间、sub主题等。公共声明可以自定义的声明但为了避免冲突应使用IANA JSON Web Token Registry中定义的名字或者是一个包含防冲突命名空间的URI。私有声明自定义的声明用于在同意使用它们的各方之间共享信息。 例如{ sub: 1234567890, name: John Doe, iat: 1516239022, exp: 1516242622 }Payload也会进行Base64Url编码形成第二部分。请注意这部分只是编码并非加密任何人都可以解码看到内容。所以绝对不要在其中存放敏感信息如密码。Signature签名这是最关键的部分用于防止Token被篡改。签名通过对编码后的Header、编码后的Payload、一个密钥Secret以及Header中指定的算法生成。HMACSHA256( base64UrlEncode(header) . base64UrlEncode(payload), secret)最终将这三部分用点连接起来就形成了一个完整的JWT。3.2 签名与验证安全性的核心签名的存在是JWT安全的基石。服务器使用一个只有自己知道的密钥对于HMAC算法或私钥对于RSA算法来生成签名。当客户端将Token发回时服务器用同样的密钥/公钥重新计算签名并与Token中的签名部分进行比对。如果一致说明Token在传输过程中未被篡改因为攻击者不知道密钥无法伪造签名同时也能验证签发者身份。4. 实战构建完整的Token登录系统理论说再多不如一行代码。我们以Node.jsExpress框架和前端Vue为例构建一个最小可用的系统。其他语言框架如Spring Boot, Django原理完全相通。4.1 后端实现Node.js Express首先初始化项目并安装依赖npm init -y npm install express jsonwebtoken bcryptjs dotenvexpress: Web框架。jsonwebtoken: 用于生成和验证JWT的主流库。bcryptjs: 用于安全地哈希用户密码永远不要明文存储密码。dotenv: 管理环境变量如密钥。步骤1环境配置与模拟数据库创建.env文件存放密钥JWT_SECRETyour_super_secret_key_at_least_32_chars_long JWT_REFRESH_SECRETyour_super_secret_refresh_key ACCESS_TOKEN_EXPIRY15m // Access Token 15分钟过期 REFRESH_TOKEN_EXPIRY7d // Refresh Token 7天过期创建一个简单的app.js并模拟一个用户数据库require(dotenv).config(); const express require(express); const jwt require(jsonwebtoken); const bcrypt require(bcryptjs); const app express(); app.use(express.json()); // 模拟数据库中的用户表 const users []; const refreshTokens []; // 用于存储有效的刷新令牌生产环境用Redis // 密码哈希函数 const hashPassword async (password) await bcrypt.hash(password, 10); const comparePassword async (password, hash) await bcrypt.compare(password, hash);步骤2用户注册与登录接口// 用户注册 app.post(/api/register, async (req, res) { try { const { username, password } req.body; // 1. 检查用户是否存在 const userExists users.find(u u.username username); if (userExists) { return res.status(400).json({ message: 用户已存在 }); } // 2. 哈希密码 const hashedPassword await hashPassword(password); // 3. 保存用户模拟 const newUser { id: Date.now().toString(), username, password: hashedPassword }; users.push(newUser); // 4. 返回成功注意不要返回密码哈希 res.status(201).json({ message: 注册成功, userId: newUser.id }); } catch (error) { res.status(500).json({ message: 服务器内部错误 }); } }); // 用户登录核心 app.post(/api/login, async (req, res) { try { const { username, password } req.body; // 1. 查找用户 const user users.find(u u.username username); if (!user) { return res.status(401).json({ message: 用户名或密码错误 }); } // 2. 验证密码 const isPasswordValid await comparePassword(password, user.password); if (!isPasswordValid) { return res.status(401).json({ message: 用户名或密码错误 }); } // 3. 生成Access Token (JWT) const accessToken jwt.sign( { userId: user.id, username: user.username }, // Payload process.env.JWT_SECRET, { expiresIn: process.env.ACCESS_TOKEN_EXPIRY } ); // 4. 生成Refresh Token (也是一个JWT但用途单一仅用于刷新) const refreshToken jwt.sign( { userId: user.id }, process.env.JWT_REFRESH_SECRET, { expiresIn: process.env.REFRESH_TOKEN_EXPIRY } ); // 5. 存储Refresh Token生产环境应存Redis并设置TTL refreshTokens.push(refreshToken); // 6. 返回Tokens注意Refresh Token应通过HttpOnly Cookie返回更安全此处为演示用JSON res.json({ accessToken, refreshToken, tokenType: Bearer, expiresIn: 900 // 15分钟单位秒 }); } catch (error) { res.status(500).json({ message: 登录失败 }); } });步骤3受保护的路由与Token验证中间件这是核心中的核心。我们需要一个中间件来拦截请求验证Token。// JWT验证中间件 const authenticateJWT (req, res, next) { const authHeader req.headers.authorization; if (authHeader) { // 格式应为 Bearer token const token authHeader.split( )[1]; jwt.verify(token, process.env.JWT_SECRET, (err, user) { if (err) { // Token过期或无效 return res.status(403).json({ message: Token无效或已过期 }); } // 验证成功将用户信息挂载到req对象上供后续路由使用 req.user user; next(); }); } else { res.status(401).json({ message: 缺少认证令牌 }); } }; // 一个受保护的用户信息接口 app.get(/api/profile, authenticateJWT, (req, res) { // 此时req.user已包含从Token解析出的信息 res.json({ message: 这是你的个人资料, user: req.user }); });步骤4Token刷新接口Access Token过期后不应让用户重新登录而是使用Refresh Token来获取新的Access Token。app.post(/api/refresh-token, (req, res) { const { refreshToken } req.body; if (!refreshToken) { return res.status(401).json({ message: 缺少刷新令牌 }); } // 检查刷新令牌是否在我们的有效列表中防止被盗用 if (!refreshTokens.includes(refreshToken)) { return res.status(403).json({ message: 刷新令牌无效 }); } jwt.verify(refreshToken, process.env.JWT_REFRESH_SECRET, (err, user) { if (err) { return res.status(403).json({ message: 刷新令牌无效或已过期 }); } // 刷新令牌有效生成新的Access Token const newAccessToken jwt.sign( { userId: user.userId, username: user.username }, process.env.JWT_SECRET, { expiresIn: process.env.ACCESS_TOKEN_EXPIRY } ); res.json({ accessToken: newAccessToken, tokenType: Bearer, expiresIn: 900 }); }); }); // 用户登出使Refresh Token失效 app.post(/api/logout, (req, res) { const { refreshToken } req.body; const index refreshTokens.indexOf(refreshToken); if (index -1) { refreshTokens.splice(index, 1); // 从列表中移除 } res.json({ message: 登出成功 }); });4.2 前端实现Vue 3 Axios前端主要负责三件事登录时获取并存储Token发起请求时自动携带TokenToken过期时自动刷新。步骤1登录并存储Tokentemplate form submit.preventhandleLogin input v-modelusername placeholder用户名/ input v-modelpassword typepassword placeholder密码/ button typesubmit登录/button /form /template script setup import { ref } from vue; import axios from axios; const username ref(); const password ref(); const handleLogin async () { try { const response await axios.post(http://localhost:3000/api/login, { username: username.value, password: password.value }); const { accessToken, refreshToken } response.data; // 存储TokenAccess Token存内存或LocalStorageRefresh Token建议存HttpOnly Cookie更安全或安全存储 localStorage.setItem(accessToken, accessToken); localStorage.setItem(refreshToken, refreshToken); // 注意这不够安全仅演示 console.log(登录成功); // 跳转到主页... } catch (error) { console.error(登录失败:, error.response?.data?.message); } }; /script步骤2配置Axios拦截器自动携带Token这是前端实现无感认证的关键。创建一个axios实例并配置请求/响应拦截器。// utils/request.js import axios from axios; const service axios.create({ baseURL: http://localhost:3000/api, timeout: 10000, }); // 请求拦截器在每次请求前将Token放入Header service.interceptors.request.use( (config) { const token localStorage.getItem(accessToken); if (token) { config.headers.Authorization Bearer ${token}; } return config; }, (error) { return Promise.reject(error); } ); // 响应拦截器处理Token过期自动刷新 service.interceptors.response.use( (response) { return response; }, async (error) { const originalRequest error.config; // 如果是401错误通常是Token过期且不是刷新Token的请求本身尝试刷新 if (error.response?.status 401 !originalRequest._retry) { originalRequest._retry true; // 标记此请求已重试防止循环 try { const refreshToken localStorage.getItem(refreshToken); const refreshResponse await axios.post(http://localhost:3000/api/refresh-token, { refreshToken }); const newAccessToken refreshResponse.data.accessToken; localStorage.setItem(accessToken, newAccessToken); // 用新的Token重试原来的请求 originalRequest.headers.Authorization Bearer ${newAccessToken}; return service(originalRequest); } catch (refreshError) { // 刷新也失败跳转到登录页 console.error(刷新Token失败需要重新登录, refreshError); localStorage.clear(); window.location.href /login; return Promise.reject(refreshError); } } // 其他错误直接抛出 return Promise.reject(error); } ); export default service;然后在你的组件或页面中导入这个配置好的service来发起请求它将自动处理Token的携带和刷新。5. 高级话题与安全加固一个基础的Token系统搭建完成了但要用于生产环境还有大量的细节和安全考量。5.1 Token存储的安全博弈前端如何存储Token是一个经典的安全与便利的权衡问题。LocalStorage/SessionStorage易于实现但面临XSS跨站脚本攻击风险。如果网站存在XSS漏洞攻击者可以窃取存储在其中的Token。HttpOnly Cookie能有效防御XSS因为JavaScript无法读取HttpOnly Cookie但可能面临CSRF跨站请求伪造攻击需要配合CSRF Token等策略。同时在跨域场景下配置稍复杂。内存存储关闭标签页即消失最安全但用户体验差刷新页面就要重新登录。我的实践建议对于需要较高安全性的应用如金融采用“Access Token短有效期 Refresh Token存HttpOnly Cookie”的模式。对于一般应用可以将Access Token存于内存或短期Storage并确保网站完全没有XSS漏洞通过CSP等策略。5.2 如何实现Token的主动失效JWT一旦签发在过期前无法主动作废这是其“无状态”特性带来的副作用。如果用户修改密码或管理员封禁用户需要立即使其Token失效怎么办黑名单机制将需要失效的Token的IDJWT标准中的jti声明或Token本身存入一个黑名单如Redis并设置与Token过期时间一致的TTL。在验证Token时除了检查签名和过期时间还要查询黑名单。这实际上引入了一个“状态”但通常是可以接受的折中方案。短期Token 状态化Session回归本质使用非常短期的Token如5分钟并将用户状态是否有效存于Redis。每次验证Token时都去Redis检查一次用户状态。这相当于一个轻量级的、可扩展的Session。5.3 防范常见攻击重放攻击攻击者截获一个有效的Token在过期前重复使用。可以通过在Payload中加入jtiJWT ID、iat签发时间并结合服务器端的短期缓存如最近5分钟内使用过的jti来防止但这同样引入了状态。更通用的做法是依赖HTTPS和Token的短有效期来降低风险。令牌泄露确保Token只在HTTPS下传输。避免在URL参数中传递Token可能被日志记录。前端小心XSS。签名算法混淆攻击确保在验证Token时明确指定算法如jwt.verify(token, secret, { algorithms: [HS256] })防止攻击者强制使用none算法。6. 生产环境部署与运维心得把代码跑起来只是第一步让它稳定、安全地服务海量用户才是真正的挑战。6.1 密钥管理命脉所在JWT_SECRET是系统的命门一旦泄露攻击者可以伪造任意用户的Token。绝对不要将密钥硬编码在代码中或提交到版本控制系统如Git。必须使用环境变量或专业的密钥管理服务如AWS Secrets Manager, HashiCorp Vault。密钥需要足够长且随机建议使用openssl rand -base64 32命令生成。定期轮换密钥制定策略定期更新密钥。旧密钥需要在一定宽限期如所有已签发Token的最大有效期内仍能验证新签发的Token使用新密钥。6.2 性能与监控验证开销JWT验证涉及密码学运算虽然单次很快但在超高QPS下仍需关注。确保服务器有足够的CPU资源。监控Token相关错误在日志和监控系统如Prometheus, ELK中重点关注401 Unauthorized和403 Forbidden错误。错误率突然升高可能意味着攻击或客户端逻辑问题。设置合理的过期时间Access Token建议15-30分钟Refresh Token建议7天。根据业务安全等级调整。6.3 我踩过的那些“坑”时钟偏移问题服务器集群中如果各机器系统时间不同步可能导致Token验证失败exp过期判断不准。务必使用NTP服务确保所有服务器时间同步。日志泄露Token不小心将包含Authorization头的请求打印到应用日志中导致Token泄露。务必在日志中间件中过滤掉敏感头信息。前端路由守卫的异步问题在Vue Router或React Router的全局守卫中发起Token刷新请求是异步的如果多个路由跳转同时发生可能触发多次刷新。需要用一个标志位或Promise队列来防止重复刷新。移动端Token持久化在React Native或Flutter中不要用AsyncStorage或SharedPreferences明文存储Token。使用如react-native-keychain或flutter_secure_storage这类安全存储方案。7. 总结与扩展方向通过以上的拆解你应该已经掌握了从原理到实践构建一个健壮的Token登录系统的全部关键点。从简单的jsonwebtoken.sign和verify到考虑无状态与有状态的折中再到前端拦截器的精妙配合每一个环节都蕴含着对安全、体验和架构的思考。这个系统还可以向更多方向扩展单点登录SSO多个子系统使用同一个认证中心。这时Token通常是OAuth 2.0的Access Token会在中心签发在各个子系统间流通和验证。权限控制RBAC将用户角色如admin,user或权限列表如[article:read, user:write]作为声明Claims放入JWT的Payload中。后端在验证Token后直接从Payload解析权限无需再查数据库实现高效的接口级权限校验。扫码登录其本质是桌面端生成一个临时Token二维码移动端扫码后确认登录将这个临时Token与移动端已登录的用户身份绑定然后桌面端轮询获取最终的Access Token。最后记住没有完美的方案。Token方案在带来扩展性和灵活性的同时也将状态管理的复杂性和安全责任进行了转移。理解其原理看清其利弊根据你的实际业务场景用户量、安全要求、技术栈做出最适合的选型和设计才是工程师价值的体现。在实际项目中我通常会画出一个清晰的序列图标出Token的生成、传递、验证、刷新全流程并与团队成员评审确保每个人都理解数据是如何流动的安全边界在哪里。这比盲目套用任何一个“最佳实践”都重要得多。