如今，许多系统采用了 JWT，但在实际生产环境中存在以下结构性限制。
为了解决这些问题，设计了新的令牌规范 DAT。
JWT 提供了 JWE 等加密标准，但其使用并非强制。
因此，许多开发环境省略了加密或使用非标准方式传输数据，导致了安全漏洞。
由于签名密钥轮换不是强制性的，单一密钥被长期使用的情况十分常见。如果密钥被泄露，这可能导致整个系统安全崩溃；事实上，大型电商网站已经因此发生过安全事故。
JWT 对每个请求都要进行 JSON 解析，消耗大量 CPU 资源。在高性能环境中，这种解析开销可能成为整个系统的主要瓶颈。
DAT 的设计原则是：安全必须是强制性的而非可选的，性能不能妥协。
expire.cid.plain.secure.signature
DAT 具有如上所示的轻量级数据结构。
DAT 在数据传输过程中将明文（Plain）和加密（Secure）区域物理分离。
强制要求敏感信息必须加密，整个过程通过 DatKey 使用标准化算法（P256、AES-GCM 等）进行保护。
DatKey 作为 DAT 系统的核心，直接管理密钥生命周期以及令牌的颁发和过期。
它被设计为在系统层面定期轮换密钥，从根本上防止由管理员疏忽造成的"静态密钥安全事故"。
| 分类 | DAT | JWT | Session |
|---|---|---|---|
| 认证方式 | 分布式验证 | 分布式验证 | 集中式 |
| 数据结构 | Raw Bytes （固定偏移量） | JSON （键值文本） | 序列化对象 （对象序列化） |
| 解析机制 | 字节数据即时映射 | 需要 JSON 解析和类型转换 | 需要对象反序列化和 I/O |
| 处理性能 | 最高（最小解析开销） | 中等（依赖 JSON 处理性能） | 低（网络/磁盘 I/O） |
| 加密 | 默认内置 | 需要单独实现 JWE（复杂） | 不适用 |
| 密钥管理 | 系统强制轮换（强制安全） | 需要自行实现（存在疏于管理的风险） | 不适用 |
| 密钥有效期 | 在密钥规范中强制明确 | 可选（未管理时永久有效） | 由中央服务器管理 |