DAT (Distributed Access Token)
DAT の導入背景
今日、多くのシステムが JWT を採用していますが、実際の運用環境では次のような構造的な限界が存在します。
これらを解決するために、新しいトークン仕様である DAT を設計しました。
🧩 セキュリティ仕様の断片化と強制力の欠如
JWT は JWE のような暗号化標準を提供していますが、その使用は強制されていません。
そのため多くの開発現場では暗号化が省略されたり、非標準の方法でデータが送信されたりして、セキュリティ上の脆弱性を招いています。
🔑 固定キー (Static Key) の使用によるセキュリティリスク
署名キーのローテーション (Key Rolling) が義務付けられていないため、単一のキーが長期間使い続けられることが頻繁にあります。これはキーが漏洩した場合にシステム全体のセキュリティ崩壊につながる可能性があり、実際に大規模なコマースサイトでこれによる侵害事故が発生しています。
📉 オーバーヘッドによるパフォーマンス低下
JWT はリクエストごとに JSON パース処理を行い、相当量の CPU リソースを消費します。高い性能が求められる環境では、このパースコストがシステム全体のボトルネックになり得ます。
DAT の核心哲学
DAT は、セキュリティは選択ではなく強制であるべきであり、パフォーマンスは妥協できないという原則のもとに設計されています。
⚡ 軽量かつ高速
DAT は上記のように、ピリオド (.) で区切られた 5 つの固定フィールドだけを持ちます。フィールドの位置が仕様で定められているため、JSON パースなしに区切り文字を探すだけで各値を切り出せます。
🔐 強制されるセキュリティ
DAT はデータ送信時に平文 (Plain) と暗号化 (Secure) の領域を物理的に分離します。
機密情報は必ず暗号化されるよう強制され、すべての処理は証明書に宣言された標準アルゴリズム (ECDSA、AES-GCM など) で保護されます。
暗号化アルゴリズムはトークンではなく証明書が決定します。トークンにはアルゴリズム情報が含まれないため、JWT の alg ヘッダーに起因するアルゴリズム混同攻撃の攻撃面が存在しません。
🔄 強制されるキーローリング
DAT 証明書は、トークンの発行と失効だけでなくキーのライフサイクルを直接管理します。
証明書には「いつからいつまで発行できるか」が仕様のレベルで埋め込まれているため、その期間を過ぎるとその証明書では新しいトークンを作れません。管理者の不注意によって 1 つのキーを何年も使い続けるという状況が、構造的に発生しません。
⏱️ 発行期間と有効期間の分離
「証明書がトークンを発行できる期間」と「発行されたトークンが生きている期間」は互いに異なる値です。
そのおかげで、証明書が発行を停止した後でも、すでに発行済みのトークンは自らの寿命を全うでき、その間にクラスタは次の証明書へ自然に移行します。
認証メカニズムの比較
| 分類 | DAT | JWT | セッション |
|---|---|---|---|
| 認証方式 | 分散検証 | 分散検証 | 中央集中型 |
| データ構造 | Raw Bytes (固定オフセットベース) | JSON (キー・バリューのテキストベース) | Serialized Object (オブジェクトのシリアライズ) |
| パース機構 | バイトデータの即時マッピング | JSON パースと型キャストが必要 | オブジェクトのデシリアライズと I/O が発生 |
| 処理性能 | 最高 (パースオーバーヘッドを最小化) | 普通 (JSON 処理性能に依存) | 低い (ネットワーク/ディスク I/O) |
| 暗号化 | 標準で提供 | JWE を別途実装する必要あり (複雑) | 該当なし |
| キー管理 | システムによる強制ローリング (セキュリティ強制) | 自前で実装 (管理不注意のリスク) | 該当なし |
| キー有効期間 | キー仕様内で強制的に明示 | 任意 (未管理の場合は永久) | 中央サーバーが管理 |
| アルゴリズム選択 | 証明書が決定 (トークンには含まれない) | トークンヘッダーの alg | 該当なし |
| 有効期限 | 仕様上の必須フィールド | 任意クレーム (exp) | サーバーが管理 |