本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 安全地解析用户池令牌 亚马逊 Cognito 代币的索赔集未修复。您的令牌所携带的声明因身份验证流程、用户的群组成员资格、身份提供商以及您在用户池中启用的功能而异。随着时间的推移，Amazon Cognito 会增加新的声明：它引入了新的密钥，但它不会重命名、更改其类型或删除本指南中记录的现有声明。这些规则适用于 ID 令牌和访问令牌。 不要自己编写令牌解析器。使用 JSON 网络令牌 (JWT) 库和 JSON 解析器，这些解析器可以随着令牌的增长而继续工作。阻止几乎所有现实世界中断的两条规则是以下前两条：容忍你不认识的说法，并对你阅读的每项声明的类型和基数做出正确的假设。 忽略你不认识的说法 阅读您的应用程序需要的声明，其余的就不用管了。当代币包含本指南中未列出的声明时，请勿拒绝、失败或抛出错误。添加了新的索赔，并且包含未列出的索赔的代币仍然有效。 按其记录类型阅读每项索赔 JSON 解析器从 JSON 本身识别每个值的原始类型，因此风险在于您的代码随后对该值的假设。将每项索赔视为本指南为其记录的类型和基数。记录为数组的声明始终是一个数组，即使它当前包含单个值也是如此。不要将其折叠成字符串。例如，`cognito:groups``cognito:roles`、和始终`identities`是数组。同样的原则适用于其他规格所定义的索赔。例如，如果存在`amr`，则是 IETF 网站上的 [RFC 8176](https://tools.ietf.org/html/rfc8176) 中定义的字符串数组，因此请使用该类型进行阅读。 不要过度验证索赔格式 验证索赔规范的要求，仅此而已。例如，`sub`是一个唯一的字符串，但不能保证采用任何特定的 UUID 格式。自定义声明中的某些值（例如序列化为字符串，而不`identities`是 JSON 布尔值或数字），并且不透明的值不能保证为任何特定的长度。强加比文档规定的更严格的格式会导致有效令牌失败。 不要假设索赔的数量或其顺序 代币中的索赔可以按任何顺序出现，并且计数可能会在代币之间以及随着时间的推移而变化。按名称而不是位置处理每个声明，并将令牌解析为通用 JSON 对象而不是固定结构。 代币规模增长预算 由于索赔集增加，代币的总体大小也随之增长。不要假设缓冲区、列宽、标题或 Cookie 中的标记大小是固定或最大的。 `openid-configuration`发现文件遵循同样的加法、向前兼容的方法。有关安全解析该文档的更多信息，请参阅[为发现文档的更改做好准备](federation-endpoints.md#user-pool-oidc-discovery-parse-safely)。