认证与授权的方式早Yi发生了翻天覆地的变化。曾几何时我们习惯了在服务端的内存中小心翼翼地维护着一个个Session，生怕服务器重启导致用户掉线。那时候，客户端手里仅仅握着一把没有任何意义的钥匙，所有的故事dou发生在服务器端。但如今JSON Web Token 横空出世，彻底改变了这个游戏规则。它把数据——或者说“声明”——直接塞进了令牌本身，发给了用户。这就像把身份证直接发给了对方，而不是只给一个排队号码。

而Zui核心、Zui灵魂的部分，莫过于 Claims。hen多人觉得Claims不就是JSON里的键值对吗？Ru果你也这么想，那可就大错特错了。今天我们就像拆解精密钟表一样，从源码、标准以及安全实践的角度，好好聊聊JWT Claims到底有哪些特点，以及为什么它值得我们如此关注。

一、 Claims的本质：JWT的“有效载荷”

我们要搞清楚Claims在JWT里扮演什么角色。Ru果把JWT比作一封通过数字签名密封的信，那么Claims就是信纸上的内容。它是JSON对象中的一组键值对，用于在各方之间安全地传递信息。这些信息不是杂乱无章的，每一个Claimdou代表着特定的含义和作用。

从源码的视角来kan，比如在Java生态中非常流行的 JJWT 库，设计者为了让我们方便地设置这些声明，专门设计了一系列方法。它要求我们传入一个实现了 Map 接口的数据结构。在这个接口中，我们Ke以清晰地kan到与Claims相关的方法往往有两个重载版本，这足以说明开发者对灵活性的重视。

简单来说Claims就是JWT的Payload部分。它承载了用于验证和识别令牌持有者的关键信息。没有了Claims，JWT就只是一个毫无意义的签名字符串。

二、 Claims的三大阵营：标准、公开与私有

虽然我们Ke以随意定义键值对，但根据JWT的标准，Claims其实有着严格的“阶级”划分。理解这一点，对于设计一个安全且易于 的系统至关重要。

1. Registered Claims：那些“名门正派”的标准声明

这类Claims是JWT标准预定义的，你Ke以把它们理解为编程语言中的“保留字”。它们具有特定的含义，所有的JWT实现库dou会自动识别并处理它们。使用这些标准字段，Neng让你的令牌具有通用性和标准化的语义。

2. Public Claims：公开但需注册的声明

这些是Ke以由使用JWT的各方自由定义的claims。但是这里有个坑：为了避免命名冲突，IANA建议我们在 IANA JSON Web Token Registry 中注册这些字段，或者使用防冲突命名空间。说实话，在实际的工程落地中，这类claims其实比较少见，大家geng倾向于直接用私有声明。

3. Private Claims：私下约定的“暗号”

这是我们在日常开发中Zui常打交道的类型。它们是共享信息的各方之间私下约定的自定义claims。比如 nameadminuserId 等等。这类声明与标准claimsZui大的区别在于：JWT库会自动验证标准claims，而私有claims需要接收方明确知道验证规则，否则它们只是一堆普通的数据。

{
  "name": "Tom",
  "admin": true,
  "userId": "10086"
}

三、 深度剖析：标准Claims的七种武器

既然Registered Claims如此重要，我们就得把这几个“保留字”一个个掰开揉碎了讲。每一个字段背后dou藏着安全设计的巧思。

1. iss ：签发者是谁？

这个字段用于标识签发JWT的主体。它Ke以是一个包含字符串或URI的服务名称。试想一下Ru果你收到了一张支票，你 得kan是谁签发的，对吧？验证方必须检查此claim，以确保令牌确实来自预期的、可信的身份认证服务器，而不是某个伪造的第三方。

2. sub ：令牌是给谁的？

在JWT的主体中编码的信息被称为claims，而 sub 无疑是其中的核心。它标识了JWT的主题，通常也就是用户的唯一ID。这是JWT中Zui关键的claim之一，用于识别令牌到底代表了哪一位“爷”。系统在后续的业务逻辑中，往往通过这个字段来关联具体的用户数据。

3. aud ：谁应该接收它？

这个字段标识了JWT的目标接收者。Ru果接收方发现自己不在这个claim的值里那就应该果断拒绝这个令牌。它Ke以是单个字符串，也Ke以是字符串数组。这就好比快递送货，单子上写着“只限张三签收”，李四就算拿到了也没用。在微服务架构中，这个字段特别有用，Ke以防止Token被乱用到其他服务上。

4. exp ：何时寿终正寝？

这是安全性的重要保障。它定义了JWT的过期时间，是一个UNIX时间戳。一旦过了这个点，令牌将不再有效。为什么要这么设计？为了防止长期有效的令牌被滥用！Ru果令牌永久有效，一旦泄露，攻击者就Neng永远冒充用户。所以设置合理的过期时间，是开发者的必修课。

5. nbf ：何时生效？

这个字段定义了JWT开始生效的时间，同样是一个UNIX时间戳。在此时间之前，令牌不应被接受。这就像电影票上写的“开场时间”，你早去了也没用。这个字段在某些需要定时发布权限或者延迟生效的场景下非常有用。

6. iat ：出生证明

标识JWT的签发时间。它主要用于确定令牌的“年龄”。虽然它不直接控制有效性，但在排查问题、计算令牌生命周期时这个字段往往Neng提供关键线索。

7. jti ：唯一的身份证

为JWT提供唯一标识符。这个字段特别适用于防止重放攻击。每次生成的JWTdou应有不同的jti值。服务端Ke以缓存Yi经使用过的jti，Ru果发现有人拿着一个用过的jti再来请求，直接拒绝。这就像每张钞票dou有唯一的序列号，防止有人复印钞票花出去。

四、 代码实战：如何在Java中玩转Claims

光说不练假把式。我们来kankan在Java中，利用JJWT库是如何创建和解析这些Claims的。这里面的细节，往往决定了代码的健壮性。

1. 构建带有Claims的令牌

在创建Token时我们通常会先准备一个Map，或者直接使用Builder的链式调用。这里有个小细节，标准claim和自定义claim是Ke以混用的。

Map claims = new HashMap<>;
claims.put; // 标准claim：设置主题
claims.put;           // 自定义claim：用户名
claims.put;           // 自定义claim：是否管理员
String token = Jwts.builder
    .setClaims // 载入我们的数据
    .setExpiration + 3600000)) // 1小时后过期
    .signWith // 签名算法和密钥
    .compact;

你kan，代码逻辑其实hen直观。但是要注意，setClaims 会覆盖掉之前设置的标准字段，所以顺序hen重要，或者直接在Map里把所有东西dou准备好。

2. 解析与验证：火眼金睛辨真伪

解析Token不仅仅是把数据读出来geng重要的是验证签名和时效。JJWT库在解析时会自动校验签名，Ru果我们设置了过期时间，它也会帮我们检查 exp。

Claims claims = Jwts.parser
    .setSigningKey // 设置密钥，这是验证签名的前提
    .parseClaimsJws
    .getBody;
String userId = claims.getSubject; // 获取sub claim
String name =  claims.get; // 获取自定义claim
Boolean isAdmin =  claims.get; // 获取自定义claim

这里有个值得注意的地方：对于私有claims，库不会自动去验证它们的业务逻辑，这需要我们在业务代码里处理。但像 exp 这种标准字段，库会抛出异常Ru果令牌过期了。

五、 Go语言中的实现：异曲同工之妙

Java生态有JJWT，Go语言社区也有标准的 github.com/golang-jwt/jwt 包。虽然语法不同，但思想是一致的。我们来kankanGo中是如何定义结构的。

// MyClaims 自定义结构体，嵌入了标准Claims
type MyClaims struct {
    Name string `json:"name"`
    Age  int    `json:"age"`
    jwt.RegisteredClaims // 这里包含了标准的 iss, sub, exp 等
}
// 创建token
claims := &MyClaims{
    Name: params.Name,
    Age:  params.Age,
    RegisteredClaims: jwt.RegisteredClaims{
        ExpiresAt: jwt.NewNumericDate.Add), // 24小时后过期
        Issuer:    "my-auth-server", // 签发人
    },
}

在Go中，通过结构体嵌套 RegisteredClaims，我们Ke以非常优雅地同时管理标准声明和私有声明。这种强类型的约束，在编译期就Neng帮我们避免hen多低级错误。

六、 安全建议：别让Claims成为后门

虽然JWT Claims带来了极大的便利，但Ru果使用不当，它就是一颗定时炸弹。作为一名老司机，我有几条不得不说的安全建议。

始终验证标准Claims，特别是exp和iss不要只解析不验证！过期的Token必须作废，未知的签发者必须拒绝。这是底线。

敏感操作别只依赖JWT对于转账、修改密码等高危操作，建议增加二次验证。毕竟JWT一旦泄露，在过期前它dou是有效的。

HTTPS是必须的永远不要在非HTTPS的连接中传输JWT。否则，中间人攻击Ke以轻而易举地截获你的令牌，那里面所有的Claims就dou裸奔了。

设置合理的过期时间这是一个权衡。时间太短，用户频繁登录体验差；时间太长，泄露风险大。通常建议Access Token有效期短一些，配合Refresh Token使用。

考虑黑名单机制JWTZui大的痛点是“一旦签发，难以在服务端主动废除”。为了解决用户注销后Token依然有效的问题，Ke以考虑实现Redis黑名单，将注销的Token的jti存入缓存。

JWT Claims作为令牌的核心内容，其设计之精妙在于它用极简的JSON格式，解决了复杂的信任传递问题。从哈尔滨工业大学的统一身份认证系统，到硅谷初创公司的微服务网关，JWT因其简洁性和高效性而备受青睐。

通过合理使用和管理Claims，无论是Registered的标准字段，还是Private的业务字段，我们douNeng大大提升应用的安全性和用户体验。希望这篇文章Neng帮你从源码和原理的层面重新审视JWT Claims。别再把它仅仅当成Map了它是现代应用安全架构中一块不可或缺的基石。

---