JWT签名通过，不能单独证明它适合当前服务使用。aud表示令牌的预期受众，服务还需要按照自己的令牌规则检查这一声明。KKCE的解析与验签页可以展示声明和签名结果，但业务接受与否属于另一层判断。
构造一个与业务受众不一致的样例
本次生成HS256演示令牌，声明中的aud写为demo-service-b，签名使用公开的教学密钥kkce-demo-key-only。假设接收方期待demo-service-a，即使它拥有相同验证密钥，也不能忽略受众差异。示例中的账号、服务名及密钥都是构造值，不承担任何真实登录或接口授权作用。
官网工作区展示了哪部分证据
将演示令牌填入解析页，再填写对应教学密钥，分别查看声明并执行签名验证。签名结果回答的是签名与所给数据、密钥及算法是否对应；它并没有获知假想服务自己的受众配置。读者应把截图中的aud值和验证结果分别理解，不能把绿色验证提示读成完整业务鉴权成功。
接收端要使用可信的验证配置
实际服务应固定允许的算法与可信密钥来源，按协议核对签发方、时间要求、受众和必要的业务声明。不能因为令牌自己声明了某个算法或来源，就无条件接受。aud还可能采用多个值的表示形式，应该使用所选库支持的验证选项，明确当前服务的匹配规则，而非简单搜索字符串是否出现。
把验签测试与授权测试分开记录
测试集可分别安排签名错误、目标受众不同、已过期及权限不足等情况，并记录每一层的拒绝原因。共享密钥能够验证多个教学样本，并不意味着生产中的不同服务应共享同一套秘密。KKCE适合检查构造令牌的内容与签名现象；生产授权应由部署端的验证库和业务策略共同完成。
演示说明：本次仅验证教学样例，没有调用受保护资源，也没有把页面验签当作登录或权限验证。
功能入口：JWT解析。
