Skip to main content
本主题提供了一个来自 SimpleHttp 客户端示例的 XSTS 令牌示例,它通过 Game Service 示例 进行处理。 此令牌是针对合作伙伴中心中的以下信赖方和设置生成的:

示例令牌

拆分和处理外部令牌

令牌的各个部分可以按如下方式分解。

外部令牌标头

因此,例如,标头组件为:
您可以将标头放入 https://jwt.io 上的 JSON Web 令牌 (JWT) 工具,即可看到解码后标头的以下内容。
这表明这是一个 JWT,用于加密内容加密密钥的证书的缩略图为 0004A3A12C1D5E59307A308D6D02E83978E2A9AE,您可以通过使用 Base64URL 解码 x5t 值来获得。 AASjoSwdXlkwejCNbQLoOXjiqa4 -> Base64Url 解码为字节数组 -> [ 00-04-A3-A1-2C-1D-5E-59-30-7A-30-8D-6D-02-E8-39-78-E2-A9-AE ] -> 转换为字符串并删除 '-' 字符

解密内容加密密钥 (CEK)

使用与指纹匹配的信赖方证书的私钥,我们可以解密内容加密密钥 (CEK):
使用 base64Url 解码返回以下字节数组:
然后,我们可以使用 RSA 私钥解密 Base64URL 解码后的值,这将返回完全解码的 CEK。

获取 HMAC、AES 和 IV(初始化向量)以解密有效负载

然后可以将 CEK 分为 hmacKeyaesKey。 HMAC 密钥是 CEK 的前半部分,AES 密钥是后半部分。
我们需要用来解密外部令牌有效负载的最后一部分是初始化向量。 IV 可以简单地从外部令牌的第三部分进行 base64 解码。

解密有效负载

有了上述密钥,我们现在可以将外部令牌的有效负载解密为如下。 有关执行此解密的代码,请参阅 Game Service 示例 的 XstsUtilities.cs 中的 DecryptAsyncDecrypt API。
解压缩此字节数组,我们得到内部 JWT 令牌。 有关更多信息,请参阅 Game Service 示例 的 XstsUtilities.cs 中的 DecompressAsync

处理已解密的内部令牌

在解压缩外部令牌有效负载的已解密字节数组后,我们现在有了一个标准的 JSON Web 令牌 (JWT),其中包含在信赖方中定义的用户、游戏和设备的声明和信息。
使用位于 https://jwt.io 的 JWT 解码工具,我们可以看到这些声明。
有关可以包含在您的信赖方配置中的声明的更多信息,请参阅 XBOX services 安全令牌声明

验证内部令牌

要验证内部令牌的内容,您的服务应遵循 JWT RFC 7516 中定义的标准验证 JWT 的签名。 此示例令牌在合作伙伴中心中配置为 JKU 签名验证,因此内部令牌的标头给我们以下信息:
kid 值标识用于生成签名的特定 XBOX Live 签名密钥。 jku 值指向可以下载公钥并用于验证签名的 URL。 如果 jku 的域名不是 “xsts-keys.auth.xboxlive.com”,则不应信任该令牌。 建议在运行时缓存密钥,因为签名密钥会经常更改。 这也使您的服务具有弹性,能够在密钥动态更新时处理获取新密钥,而无需停机或维护。 如果您正在使用现有的 JWT 开源解决方案,则在将 JKW 公钥传递给 JWK 解码 API 时会自动进行签名验证。 在验证签名后,您的服务可以信任证书及其中的数据是真实的。 有关 XBOX Live 签名 JWK 和 XBOX Live 签名证书的内部令牌验证的详细信息,请参阅 内部令牌标头和签名验证

识别令牌中的正确用户

令牌将包含在客户端创建令牌时所有主动登录的 XBOX Live 用户的用户身份。 因此,您的服务需要使用 HTTP 授权标头中的用户哈希值,并在用户身份中找到匹配的 ush 值。 对于此示例令牌,Authorization 标头的用户哈希为 18026470712427541036。 由此我们可以看到,此用户哈希(Gamertag 为 2 Dev 079574836)有相关的声明。 尽管此令牌在令牌声明中只有一个用户身份,但我们仍应验证它是否与标头中的用户哈希匹配。

另请参阅

XBOX services 安全令牌声明 XBOX Live 安全令牌示例 游戏服务的 XBOX services 身份验证
最后修改于 2026年8月25日