使用其他认证机制时，识别用户和账户的配置位于服务器配置文件中。JWT 认证 使用 JSON Web Tokens (JWT) 来描述支持的各种实体。当客户端连接时，服务器使用 NKey 验证请求的真实性，下载账户信息并验证信任链。用户不由服务器直接跟踪，而是验证为属于一个账户。这使得可以在不需要服务器配置更新的情况下管理用户。
实际上，JWT 改进了账户并提供了分布式配置范式。以前，每个用户（或客户端）都需要事先在服务器配置中声明并授权，需要服务器管理员修改和更新服务器配置。现在，这些繁琐的工作被消除了。用户创建甚至可以由完全不同的实体执行。
注意：此方案改进了账户。隔离或定义账户之间的导出/导入等功能仍然存在！它将账户、导出/导入或用户及其权限的配置从服务器移动到几个受信任的 JSON Web Tokens (JWT) 中，这些 JWT 单独管理，因此无需在每个服务器中配置这些实体。它还增加了过期和撤销等功能，用于去中心化账户管理。
JSON Web Tokens (JWT) 是一种开放且行业标准的 RFC7519 方法，用于在双方之间安全地表示声明。
声明是一种在 主体 上断言信息的奇特方式。在本文中，主体 是被描述的实体（不是消息主题）。标准 JWT 声明通常经过数字签名和验证。
NATS 通过要求 JWT 必须满足以下条件来进一步限制 JWT：
NKey 角色包括：
角色是分层的，并形成信任链。运营商颁发账户，账户又颁发用户。服务器信任特定的运营商。如果一个账户由受服务器信任的运营商颁发，则通过信任链，账户下的用户也受信任。
当 用户 连接到服务器时，它会提供由其 账户 颁发的 JWT。用户通过使用其私钥对服务器颁发的加密挑战进行签名来证明其身份。签名验证机制验证了签名是否可归因于用户的公钥。接下来，服务器检索颁发该用户的相关账户 JWT。它验证 用户 颁发者是否与引用的账户匹配。最后，服务器检查是否由受信任的 运营商（服务器配置的运营商）颁发了 账户，完成信任链验证。
从授权角度来看，账户提供了 从其他账户导入的消息主题（包括任何相关的辅助授权）以及导出到其他账户的消息主题 的信息。账户还可以带有限制，例如它们应该具有的最大连接数。用户 JWT 可以表达对其可以发布或订阅的消息主题的限制。
当向账户添加新用户时，账户配置无需更改，因为每个用户可以并且应该有自己的用户 JWT，只需通过解析其父账户即可验证。
需要牢记的一个关键细节是，虽然在其他系统中 JWT 用作会话或认证证明，但 NATS JWT 仅用作描述以下内容的配置：
认证是一个公钥加密过程——客户端对 nonce 进行签名以证明身份，而信任链和配置提供授权。
服务器永远不会知道私钥，但可以验证签名者或颁发者是否确实匹配指定或已知的公钥。
最后，所有 NATS JWT（运营商、账户、用户和其他）都期望使用 Ed25519 算法进行签名。如果不是，它们会被系统拒绝。
在 nats-server 上启用运营商 JWT 安全性的配置非常少，一旦服务器初始配置完成，认证和授权任务通常通过使用 nsc 管理工具在本地完成，并与内置在 nats-server 中的账户解析器同步。
配置分为几个独立的步骤。根据组织需求，这些步骤可以由相同或不同的实体执行。
实际上，JWT 配置是使用 nsc 工具完成的。它可以设置为为所有 nkey 角色颁发 NKey 和相应的 JWT：运营商/账户/用户（示例用法）。尽管账户和用户创建不在服务器配置中进行，但在此模型（示例用法）中是集中式认证和授权设置。
在已有组织信任关系的情况下，也可以使用 nsc 导入账户或用户公钥 NKey 并颁发相应的 JWT。这样，运营商可以颁发账户 JWT，而单独的实体可以颁发与其账户关联的用户 JWT。两个实体都不必知道对方的 Nkey 私钥。这不仅允许用户在服务器之外的地方配置，而且可以由完全不同的组织配置。比如 NATS 服务器的管理员控制运营商，为管理自己用户的各个生产/开发团队颁发账户 JWT。这是一个完全去中心化的授权设置！
有了运营商 JWT，需要配置服务器信任它（通过指定 operator）。此外，服务器需要一种获取账户 JWT 的方式。这可以通过默认为运营商 JWT 中指定的解析器或手动指定解析器来完成。你可能需要设置一个账户服务器，具体取决于你的配置。
更多信息可在深入指南中找到。