今日、多くのシステムがJWTを採用していますが、実際の本番環境では以下のような構造的な限界が存在します。
これらの問題を解決するために、新しいトークン仕様であるDATが設計されました。
JWTはJWEのような暗号化標準を提供していますが、その使用は強制されていません。
その結果、多くの開発環境では暗号化を省略したり、非標準の方法でデータを送信したりして、セキュリティの脆弱性を招いています。
署名キーのローリングが義務付けられていないため、単一のキーが長期間使用されることが多くあります。これはキーが漏洩した場合にシステム全体のセキュリティ崩壊につながる可能性があり、実際に大規模なECサイトでこれによる侵害事件が発生しています。
JWTはリクエストごとにJSONパース処理を行い、大量のCPUリソースを消費します。高性能が求められる環境では、このパース処理のコストがシステム全体のボトルネックになる可能性があります。
DATは、セキュリティはオプションではなく必須であり、パフォーマンスは妥協できないという原則のもとに設計されています。
expire.cid.plain.secure.signature
DATは上記のような軽量なデータ構造を持っています。
DATはデータ送信時にプレーンテキスト（Plain）と暗号化（Secure）領域を物理的に分離します。
機密情報は必ず暗号化されるよう強制し、全プロセスはDatKeyを通じて標準化されたアルゴリズム（P256、AES-GCMなど）で保護されます。
DATシステムの核心であるDatKeyは、トークンの発行と失効だけでなく、キーのライフサイクルを直接管理します。
システムレベルで定期的にキーをローテーションするよう設計されており、管理者の不注意による「静的キーセキュリティ事故」を根本から防止します。
| 分類 | DAT | JWT | セッション |
|---|---|---|---|
| 認証方式 | 分散検証 | 分散検証 | 集中型 |
| データ構造 | Raw Bytes (固定オフセットベース) | JSON (キー・バリュー テキストベース) | Serialized Object (オブジェクトシリアライズ) |
| パース機構 | バイトデータの即時マッピング | JSONパースと型キャストが必要 | オブジェクトのデシリアライズとI/O発生 |
| 処理性能 | 最高（パースオーバーヘッドを最小化） | 普通（JSON処理性能に依存） | 低（ネットワーク/ディスクI/O） |
| 暗号化 | デフォルト提供 | JWEの別途実装が必要（複雑） | 該当なし |
| キー管理 | システム強制ローリング（セキュリティ強制） | 直接実装が必要（管理不注意のリスク） | 該当なし |
| キー有効期間 | キー仕様内で強制明示 | オプション（未管理時は永久） | 中央サーバーで管理 |