简介面向C#开发者与需要对API接口做安全加固的技术人员这份资源围绕JWT标准展开覆盖Token从生成、签名、验签到过期刷新、OAuth2.0集成等完整流程并提供可直接落地的示例工程。资源共748个文件压缩包约55MB核心内容为C#源码cs与MVC视图页面cshtml同时附带所需依赖库dll、配置文件config以及项目工程文件sln/csproj便于直接编译运行与二次修改。已有9415人学习下载适合初中级开发者理解JWT原理并快速实现身份验证功能。从中可掌握System.IdentityModel.Tokens.Jwt库的典型用法包括TokenValidationParameters参数配置、密钥管理与刷新策略并了解到微服务场景下无状态认证的具体写法是一份结合理论说明与可运行代码的实用参考资料。 JWT Token 这个东西只要做过前后端分离项目基本都会碰到。前阵子我接手一个老系统用户登录成功后后续每个请求都要拿 sessionId 去 Redis 里查用户信息高峰期 Redis 的连接数和响应时间都压得有点难看。后来把会话方案整体切到 JWT Token服务端彻底无状态了登录后发一个 Token后续请求带着它进来验签通过就直接信任一下轻松了不少。当然JWT 也不是银弹什么场景该用、生成和验证这条链路上有哪些坑、Token 怎么续签、怎么防伪造这些点今天一次性说清楚正好对应上你搜的那些词jwt在线解析、token失效、token续签、jwt伪造等等。1. JWT到底解决了什么问题从Session的痛点说起1.1 Session登录的局限与JWT的定位早期做 Web 登录主流方案是 Session-Cookie用户输完账号密码服务端生成一个 sessionId 存到内存或者 Redis再把 sessionId 写进 Cookie 返回给浏览器。浏览器下次请求带上 Cookie服务端拿 sessionId 去查对应的会话数据。这套方案在单机时代没问题但一旦服务拆成多个实例部署或者做了负载均衡就会面临一个尴尬局面用户第一次请求落在 A 机器登录状态存在 A第二次请求被负载均衡转到了 B 机器B 上没有这份 session用户就被当成未登录了。解决思路无非两种一种是做 Session 粘滞把同一个用户的请求固定转发到同一台机器但这会破坏负载均衡的弹性另一种是把 Session 集中放到 Redis所有实例共享这个方案用得很广但 Redis 一旦抖动所有用户的登录态都受影响而且每次请求都要多一次网络 IO。JWT 的思路完全反过来不把状态存在服务端而是把用户身份信息直接编码进 Token 里发给客户端服务端只负责验签。签名通过就认为这个 Token 合法里面的用户信息可以直接用不需要再查询任何会话存储。这就是 JWT 常说的无状态。1.2 JWT的结构拆解Header、Payload、SignatureJWT 是一串由三个部分组成的字符串用点号分隔长得像这样xxxxx.yyyyy.zzzzz。三个部分分别是 Header、Payload、Signature。Header 里放的是算法和 Token 类型最常见的组合是{alg:HS256,typ:JWT}。算法字段很关键后面讲安全漏洞的时候还要专门提它。Payload 是载荷区可以放签发人、过期时间、主题、自定义的业务字段。注意Payload 只是做了 Base64URL 编码并没有加密任何人都可以解码看到里面的内容。网上搜一下jwt在线解析把 Token 粘进去就能看到明文。所以千万别把密码、手机号、身份证这类敏感信息塞进 Payload。Signature 是整个 Token 的防伪标识由 Header Payload 密钥经过指定算法计算出来。服务端验证 Token 时重新计算一遍签名比对是否一致一致就说明 Token 没被篡改过。用生活一点的话说JWT 就像一张盖了公章的工作证。公章代表服务端的私密密钥证上的信息谁都能看Payload 明文但别人没有公章伪造不出来。只要章是真的、内容没被改过这张证就能用。1.3 Cookie、Session与Token的区别这三者的关系经常有人搞混。Session 是服务端的会话记录Cookie 是浏览器端存储数据的机制Token 是客户端保存的一种凭证。URL 里常见的cookie session token区别这个问题其实就是三个不同维度的东西Session 是状态放在服务端Cookie 是状态放在浏览器的一种载体JWT Token 则是状态本身被编码进凭证里。它们不是互斥的也经常会组合出现Session 方案里用 Cookie 传 sessionIdJWT 方案里也可以把 Token 丢进 Cookie 里传输也可以放请求头 Authorization 里传看具体场景。2. 生成Token的完整实操选型、依赖与核心代码2.1 技术选型jjwt还是java-jwtJava 生态里做 JWT 的库不少比较主流的有 jjwtio.jsonwebtoken、Java JWTcom.auth0、Nimbus JOSE JWT。我个人的习惯是选 jjwt原因很直接API 设计比较清爽官方文档完整社区活跃支持的签名算法覆盖了 HS、RS、ES 全系列对 Jackson 的集成也很顺不需要自己写序列化适配。如果项目里用的是 Spring Bootjjwt 和 Spring Security 的搭配也比较常见。下面所有示例都以 jjwt0.11.5版本为准这个版本是目前生产环境里用得比较多的稳定版。2.2 生成Token的代码实现与参数说明先引入 Maven 依赖总共三个包dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-impl/artifactId version0.11.5/version scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-jackson/artifactId version0.11.5/version scoperuntime/scope /dependency接口在 jjwt-api 里真正干活的是 runtime 的 impl 和 jackson 模块。少了后面任何一个运行阶段都会报 ClassNotFoundException 这一类的错误。然后是核心的生成方法import io.jsonwebtoken.Jwts; import io.jsonwebtoken.SignatureAlgorithm; import io.jsonwebtoken.security.Keys; import javax.crypto.SecretKey; import java.nio.charset.StandardCharsets; import java.util.Date; public class TokenGenerator { // 生产环境务必从配置中心读取不要硬编码在代码里 private static final String SECRET your-256-bit-secret-key-change-me-to-a-long-random-string; private static final SecretKey KEY Keys.hmacShaKeyFor(SECRET.getBytes(StandardCharsets.UTF_8)); public static String generateToken(String userId, String username, String role) { long now System.currentTimeMillis(); long expireMills 30 * 60 * 1000; // 30分钟过期 return Jwts.builder() .setHeaderParam(alg, HS256) .setSubject(userId) .setIssuer(my-app) .setIssuedAt(new Date(now)) .setExpiration(new Date(now expireMills)) .claim(username, username) .claim(role, role) .signWith(KEY, SignatureAlgorithm.HS256) .compact(); } }几个关键点说一下setSubject存用户主键这是最常用的字段后续验证完 Token 可以直接拿 userId 出来当上下文。claim是自定义字段用户名、角色、权限点都可以往里面放。但记住前面说的敏感信息不能放。signWith指定密钥和算法。HS256 是对称算法生成和验证用的是同一个密钥所以密钥本身一定要保密长度也不能太短否则会报WeakKeyException。测试阶段容易踩这个坑随便写个secret当密钥结果项目启动就抛异常。HS256 要求密钥至少 256 位也就是 32 个字节。2.3 密钥管理HS256和RS256怎么选HS256 和 RS256 是两种最常用的签名算法选择时要考虑应用场景。HS256 是对称加密一个密钥同时用来签名和验签。优点是计算快实现简单适合单体应用内部服务之间的 Token 签发和验证。缺点是密钥只有一把拿到它就能伪造任何 Token所以密钥必须锁死在服务端不能发给任何第三方。RS256 是非对称加密私钥签名公钥验签。典型场景是第三方开放平台你的服务用私钥给客户端签发 JWT客户端或其他信任方用你下发的公钥验证真伪私钥永远不需要离开你的服务。这样就算公钥泄露也无法伪造 Token。缺点是非对称计算比对称慢配置也更重。具体做项目时如果 JWT 只在自己系统内部用HS256 是够的如果 Token 会被外部系统消费或者要开放给第三方校验那就得用 RS256同时把公钥通过接口或者 JWKS 的方式开放出去。3. 验证Token不是简单的解析完整校验链路3.1 认证过滤器的位置与设计生成 Token 只是前半段真正考验细节的是验证链路。在 Spring Boot 项目里最常见的做法是写一个 OncePerRequestFilter把它挂到 Spring Security 的过滤器链上或者直接注册到 Servlet 的过滤器链上对所有需要鉴权的接口做统一拦截。过滤器的逻辑大致是从请求头取Authorization: Bearer token段。没有 Token 就直接放行或者按匿名处理由后面的授权逻辑决定放不放行。有 Token 就进入验签流程。校验通过把用户信息放进 SecurityContext 或者 ThreadLocal供 Controller 层使用。校验失败按异常类型返回 401 或者 403。实际的代码我习惯写成下面这样先取 Header再剥掉Bearer前缀String header request.getHeader(Authorization); if (header null || !header.startsWith(Bearer )) { filterChain.doFilter(request, response); return; } String token header.substring(7);3.2 过期校验、签名校验与异常分类验证的核心代码并不复杂难在异常处理要区分清楚。完整代码如下import io.jsonwebtoken.*; public class TokenValidator { private static final SecretKey KEY Keys.hmacShaKeyFor(SECRET.getBytes(StandardCharsets.UTF_8)); public static Claims validateToken(String token) { JwsClaims jws Jwts.parserBuilder() .setSigningKey(KEY) .build() .parseClaimsJws(token); return jws.getBody(); } }parseClaimsJws内部按顺序做了几件重要的事格式校验Token 必须是三段否则抛 MalformedJwtException。签名校验用密钥重新算一遍签名和 Token 里的 Signature 比对。对不上说明 Token 被篡改或者密钥不对抛 SignatureException。过期时间校验判断exp是否早于当前时间过期了抛 ExpiredJwtException。时间窗校验如果设置了nbfnot before字段还会校验当前时间是否在生效时间之后。所以捕获异常时不要一把梭要分类型处理异常类型含义建议处理ExpiredJwtExceptionToken 过期返回 401提示登录态过期前端跳登录页SignatureException签名校验失败按非法请求处理记日志返回 401MalformedJwtExceptionToken 格式错误按非法请求处理UnsupportedJwtException算法不支持等按非法请求处理排查签名算法3.3 常见验证失败场景与放开白名单我踩过的坑之一是 Redis 查询被误背锅。切换 JWT 之前团队里有人说 JWT 无状态省事但也有同事担心 Token 被抢了没法主动踢人。这个矛盾在验证环节要先想清楚JWT 验证默认只在服务端本地算签名和过期时间不发任何外部请求所以从性能上说验一个 Token 就是几次 HMAC 计算毫秒级都不到。但如果你想实现用户被禁用了 Token 立刻失效这类需求就还得引入黑名单或者版本号机制在第 4 节细说。另一个是springboot jwt 放开swagger这类白名单配置的场景。Swagger 或接口文档的静态资源、登录接口本身是不需要鉴权的否则会陷入登录接口也要 Token但没登录哪来的 Token的死循环。实际项目里一般维护一个 permitAll 的 URL 列表包括/auth/login、/swagger-ui/**、/v3/api-docs/**这些路径在过滤器里先判断请求路径是否命中白名单命中就直接放行不走 Token 校验。这样省事也避免把接口文档也锁起来。3.4 获取请求头里的Token与上下文传递这里要提醒一个问题很多人从request.getHeader(Authorization)取出 Token 后只验签就完事了不去检查 Payload 里的签发人、受众等字段。如果项目有多个客户端共用同一套签发密钥或者 Token 可能流通到别的系统里最好再核对一下iss、aud这些声明避免一个服务签发的 Token 被另一个服务无脑接受。验签通过后的 Claims 对象里getSubject()拿到的是 userId建议立刻放进请求上下文中。通常做法是在过滤器里往request.setAttribute(userId, userId)塞一份然后在 Controller 里用RequestAttribute(userId)取配合 Spring Security 的话就构造一个 Authentication 对象塞进 SecurityContextHolder。无论哪种做法目的都是一样的让后续的业务代码不需要再去解析 JWT拿到的直接是用户身份。4. 有效期设计与Token续签token失效该怎么做4.1 有效期设多长合适Token 有效期这个参数设置短了用户用着难受设置长了安全风险变高。所以没有标准答案完全看业务性质。如果做一个普通的后台管理系统半小时到两小时算比较常见的区间。我的一般做法是访问 Token 定 30 分钟管理和后台系统也差不多稍微长一点到 2 小时也可以。如果做的是 App 或 SPA 的登录态结合刷新机制的话访问 Token 可以短到 15 分钟刷新 Token 放到 7 天甚至 30 天。核心原则是先想清楚Token 被偷走后你希望通过短过期来缩小攻击面还是通过刷新机制来兼顾体验两者不可兼得只能取舍。4.2 滑动续签的实现方案jwt实现token续签 是很多搜索词里的高频问题。续签方案里最简单直观的是滑动续签用户在系统的有效期内持续操作只要每次请求时检查剩余有效期当剩余时间低于某个阈值就顺手签发一个新 Token 返回给前端前端下次请求用新 Token。配合 Spring Boot 的 Filter实现思路大致是这样验签通过后取出exp字段计算剩余时间long remainingMillis expiration.getTime() - System.currentTimeMillis(); long renewThreshold 10 * 60 * 1000L; // 剩余不足10分钟就续签 if (remainingMillis 0 remainingMillis renewThreshold) { String newToken TokenGenerator.generateToken(userId, username, role); response.setHeader(X-New-Token, newToken); }前端在请求完成后检查响应头如果存在X-New-Token就把它替换成本地新的 Token继续后面的请求。这种方案的好处是不用引入刷新 Token 的概念实现成本低缺点是 Token 在有效期内基本都是无限续签的状态对安全要求极高的系统不合适。更严谨的做法是双 Token 方案短期的 Access Token 和长期的 Refresh Token。Access Token 过期后前端拿 Refresh Token 去请求一个刷新接口换取新的 Access Token。刷新接口要再校验一边 Refresh Token 的有效性同时可以在这里做是否还在白名单里Refresh Token 是否已吊销等逻辑。双 Token 的优点是控制更细刷新的时机完全掌握在后端手里缺点是实现量更大前端需要处理并发请求时的 Token 刷新竞态避免多个请求同时拿旧的 Refresh Token 换新后先换的 Token 失效了。4.3 主动失效黑名单、版本号与登出场景JWT 无状态是一把双刃剑因为有状态的服务端会话可以被主动删除JWT 一旦发出去服务端没有会话记录可删。要解决用户改密码了、被踢下线了、主动登出了Token 应立即失效这类问题就得引入一点半状态手段。最常见的做法是黑名单机制把需要失效的 Token 的 jtiJWT ID或者用户的 Token 版本号扔进 Redis并设置一个和 Token 过期时间一致的 TTL。每次验签通过后再查一次黑名单命中了就拒绝。这个方案多了一次 Redis 查询但换来了主动失效能力。对于权限敏感的系统这个代价完全值得。另一个思路是版本号在用户表里存一个token_version字段签 JWT 时把这个版本号放进 payload。验证 Token 时从数据库查出用户的当前版本号比对是否一致。不一致就说明 Token 是旧的。这个方案最灵活的地方在于修改用户密码或者管理员禁用账号时只要把版本号加一该用户所有已签发的 Token 立即全部作废。缺点则是每次验证要查一次数据库无状态优势打了几分折扣。4.4 登录态过期的前端处理token失效之后前端表现不好也是很多项目体验差的根源。正常流程应该是接口返回 401 时前端拦截器统一捕获清掉本地存储的 Token跳转到登录页。但这里有个常见毛病一个页面同时发了好几个接口请求全部 401跳转逻辑被触发了 N 次路由跳转重入页面状态混乱。比较稳妥的做法是做一个 401 去重定义一个布尔标志位第一次收到 401 时查标志位如果已经处理过就直接忽略避免重复跳转。同时注意保留当前路由登录成功后跳回原页面不要每次都被踢回首页这种体验细节很影响用户对系统的耐受度。5. 安全边界jwt伪造、密钥泄露与在线解析的陷阱5.1 jwt在线解析为什么会泄露信息网上搜jwt在线解析能找到一堆网站粘 Token 进去就能看到完整的 Header 和 Payload 明文。这个功能本身没问题问题在于很多人意识不到所有 JWT 的 Payload 都是公开可读的不需要什么破解能力只是 Base64URL 解码而已。你把 Token 贴给在线工具的同时等于把业务关键词、用户 ID、角色信息都展示给了第三方网站。我见过一些新人在调试接口时随手把真实环境的 Token 贴到在线解析网站结果 payload 里的手机号、邮箱全被看见了。虽然 JWT 里的敏感字段不至于直接被利用但这本质上是一次信息泄露。建议工具类需求用本地脚本解码或者只在对自己维护的解析服务中调试。JWT 是明文无加密的容器这个定位一定要刻到脑子里面。5.2 算法混淆攻击与jwt伪造的手段jwt伪造和jwt破解是安全测试人员最爱聊的两个话题。先澄清一个常见误解JWT 本身很难被破解因为签名的安全性建立在密钥上HS256 用足够长的随机密钥时暴力破解的代价是天文数字。真正的漏洞通常出在使用方配合上而不是算法本身。最经典的攻击是算法混淆。有些库在验证 Token 时会读取 Header 里的alg字段来决定验证方式。攻击者把alg改成none去掉签名部分一些没做防护的库居然会直接通过校验。或者把alg从RS256改成HS256让服务端用公钥当对称密钥去验签攻击者只要能拿到公钥就能自己算出合法的 HS256 签名。防住这类攻击其实很简单就一条原则验证时明确指定允许的算法绝不能依赖 Token Header 里的算法名。用 jjwt 时可以通过parserBuilder().setSigningKey(key)固定密钥并且不要引入不可信的解析方式从库层面就把这条路堵死。把alg改成none的伪造方式在 jjwt 这种主流库里基本已经免疫了但如果你在用的旧版库或者自研实现一定要检查是否有这个洞。RSA公钥误用为HMAC密钥的典型防范再看一个细节如果你的服务用 RS256对外暴露了 JWKS 或公钥接口当有人试图把 Token 的算法改成 HS256 提交过来时你的服务可能拿公钥字符串当作 HS256 的密钥做验签。攻击者知道公钥内容完全可以伪装成合法签名。要做到防范校验时明确只接受 RS256拒绝其他算法或者签出来的 Token 上加一个固定的 Header 值解析时先核对再往下走。这属于老生常谈但每次线上排查伪造 Token 的案例总结下来还是这类低级问题最致命。5.3 前端存储与会话风险控制Token 存哪里也是个值得展开的话题。很多 SPA 项目图省事直接把 Token 放 localStorage刷新页面不丢取用也方便。但 localStorage 的访问权限是任何同源 JavaScript 都能读的一旦页面被注入了一段恶意脚本Token 就像把钥匙挂在大门口一样被人顺手摸走。相比之下把 Token 放进 HttpOnly 的 Cookie 里JavaScript 完全读不到只能靠浏览器自动携带XSS 攻击拿它没办法。代价是无法用请求头方式传递对跨域场景要配置SameSite和 CORS 策略调试时也要多折腾几步。我的建议是如果你做的项目对安全性有一定要求优先考虑 HttpOnly Cookie 承载 JWT如果团队更习惯 Authorization Header 的写法且相信自己的 XSS 防护做得到位再考虑 localStorage。同时把这两件事也纳入检查清单里日志系统里绝不能打完整 Token打出来的话排错日志本身就成了泄露源。用户修改密码后旧 Token 要按 4.3 节的方式全部作废。登录接口要做限流防止别人拿用户名密码撞库后换取大量合法的 JWT Token。5.4 注册断言与回调接口的Token校验如果你的系统接入了第三方回调比如支付回调、外部登录回调回调 URL 上带不放业务 Token服务端接到回调时必须重新验签绝不能因为这个 URL 是配置好的就默认安全。这个环节用的还是同一套验证逻辑但要注意在回调场景中设置更严格的aud受众校验防止一个回调 Token 被拿到别的接口里复用。安全这块没有一劳永逸的解法能做的就是把这些边界一个个收紧。像 jwt伪造这种问题大多数时候不是算法被攻破而是密钥管理、算法白名单、日志泄露这类工程细节没做到位。把密钥藏好、把算法钉死、把 Payload 当明文看待、把日志里的 Token 清干净这几条守住JWT 这套方案在绝大多数业务场景下都能站得稳。本文还有配套的精品资源点击获取