認証トークンとは何ですか？
次のような状況を想像してください。あなたはニューヨークで午前9時に企業アプリケーションへログインしました。30分後、誰かが東京からあなたのアカウントにアクセスします。パスワードは一度も変更されていません。多要素認証（MFA）トークンは机の上に置いたままです。しかし攻撃者は、盗まれた認証トークンを使って、正面玄関から入り込むように侵入しました。
認証トークンは、企業システム全体であなたの身元を検証するデジタルバッジです。これらは暗号学的な認証情報であるため、リクエストとともにパスワードが送信されることはありません。NIST Special Publication 800-63B-4によると、これらのトークンは現代のサイバーセキュリティアーキテクチャにおけるデジタルアイデンティティ保証の基盤を確立します。
上記のシナリオは仮説ではありません。2023年、脅威アクターがOkta's customer support systemにアップロードされたサポートファイルからセッショントークンを抜き取り、それを使って5社の顧客のライブセッションを乗っ取りました。パスワードが破られたわけではありません。MFAプロンプトに応答したわけでもありません。有効なトークンが提示され、システムは設計どおりに動作しただけです。
トークンがどのように機能するのか、どこで破綻するのか、そしてどのように保護するのかを理解することが、持ちこたえる認証基盤と、攻撃者に鍵を渡してしまう基盤を分けます。このページでは、その3つすべてを解説します。
認証トークンがセキュリティ上の標的となる理由
トークンは、アイデンティティセキュリティと アクセス制御アーキテクチャの交点に位置します。どのシステムに認証する場合でも、実際の認証情報をすべてのリクエストで持ち回ることはありません。代わりに、「この人物はすでに本人確認を済ませている」と示すトークンを受け取ります。
トークンを盗めば、攻撃者は認証を完全に回避できます。偽造すれば、正当なユーザーになりすませます。トークンの検証方法を操作すれば、認可されたアカウントを一度も保持することなく権限昇格できます。
これを誤るコストは十分に文書化されています。IBM's 2026 Cost of a Data Breach Reportでは、世界全体の平均侵害コストは499万ドルで、過去最高となっています。Verizon's 2026 Data Breach Investigations Report (DBIR)では、レポートの19年の歴史で初めて、脆弱性の悪用が盗まれた認証情報を上回り、侵害の主要な侵入口となったことが示されました。認証情報は今年までその位置を占めており、盗まれたトークンは、すでに正面玄関を通過した認証情報です。
これらのリスクを理解するには、セキュリティチームはまず、組織が展開しているさまざまなトークンの種類と、それぞれがどのように固有のセキュリティ上の考慮事項をもたらすかを認識する必要があります。
認証トークンの種類
組織は、セキュリティ要件とユースケースに応じて異なる種類のトークンを展開します。
- JSON Web Tokens (JWTs): ヘッダー・ペイロード・署名の構造でエンコードされたクレームを保持する自己完結型トークンです。JWTは、サーバーがデータベース参照なしでトークンを検証するステートレスな検証を可能にするため、分散マイクロサービスアーキテクチャに適しています。
- OAuth 2.0 Tokens: OAuthフレームワークでは、2種類のトークンが連携して使用されます。アクセストークンはAPI呼び出し用の短命な認証情報を提供し、リフレッシュトークンは再認証なしで新しいアクセストークンを取得します。この分離により、トークン窃取時の被害を限定できます。
- SAML (Security Assertion Markup Language) Assertions: エンタープライズシングルサインオン向けに、アイデンティティプロバイダーとサービスプロバイダーの間で交換されるXMLベースのトークンです。SAMLは、レガシーなエンタープライズ環境やB2Bフェデレーションのシナリオで依然として主流です。
- Session Tokens: ブラウザーをサーバー側のセッション状態に関連付ける、サーバー生成の識別子です。ステートレスなJWTとは異なり、セッショントークンはサーバー側の保存を必要としますが、即時失効機能を提供します。
- FIDO2/Hardware Tokens: WebAuthn APIを通じて公開鍵暗号方式を使用する物理認証子です。これらのトークンは、暗号学的なオリジンバインディングによってフィッシング耐性を提供し、認証情報が正規サイトでのみ機能することを保証します。
各トークンタイプは異なる目的に対応しますが、セキュリティ態勢を決定する共通のアーキテクチャ要素を共有しています。強化はそれらのコンポーネントから始まります。
認証トークンの中核コンポーネント
認証トークンには、そのセキュリティ態勢と機能的能力を決定する特定の要素が含まれています。
- トークン構造: JWTは3つのセクションで構成されます。ヘッダー（RS256やES256などの署名アルゴリズムを指定）、ペイロード（クレームを含む）、署名（暗号学的完全性を保証）です。SAMLアサーションは、OASIS SAML V2.0仕様に従ったXML形式のステートメントを使用します。
- トークンメタデータ: トークンはペイロード内にメタデータを保持します。有効期限タイムスタンプ（expクレーム）は有効期間を定義し、発行時刻クレーム（iat）はトークンの経過時間を確立し、JWT ID（jti）は失効追跡のための一意識別子を提供し、オーディエンス制限（audクレーム）はサービス間でのトークン再利用を防ぎます。
- セッションエントロピー: Webアプリケーションのセッショントークンには、暗号学的に安全な疑似乱数生成器（CSPRNG）によって生成される 最小エントロピーが必要です。
- ハードウェアトークンの暗号技術: FIDO2トークンは、WebAuthnブラウザーAPIとClient to Authenticator Protocol（CTAP）を組み合わせます。秘密鍵がセキュアエレメントから出ることはなく、暗号学的なオリジンバインディングにより、認証情報が正規のWebサイトでのみ機能することが保証されます。
これらのコンポーネントはワークフローに組み合わされ、そのワークフローこそがトークンセキュリティの成否を分ける場所です。以下のセクションでは、トークンが多要素認証とどのように相互作用するかを含め、各フローをたどります。
認証トークンの仕組み
認証トークンは、種類と展開コンテキストに応じて異なるワークフローに従います。
- JWT認証フロー: 認証サーバーに認証情報を送信します。サーバーは認証情報を検証し、有効期限、オーディエンス、発行者クレームを含むJWTを生成して暗号学的に署名し、それをクライアントに返します。以降のリクエストでは、AuthorizationヘッダーにJWTを含めます。リソースサーバーは署名を検証し、アクセスを許可する前にクレームを確認します。
- OAuth 2.0 認可コードフロー: 保護されたリソースへのアクセスを要求します。認証と同意の後、サーバーは認可コードを発行し、アプリケーションはそれをアクセストークンとリフレッシュトークンに交換します。API呼び出しには短命なアクセストークンを使用し、必要に応じてリフレッシュトークンを新しいアクセストークンに交換します。
- SAML WebブラウザーSSO: サービスプロバイダーのアプリケーションにアクセスしようとすると、アイデンティティプロバイダーにリダイレクトされます。認証後、IdPは署名付きSAMLアサーションを生成してサービスプロバイダーに送信し、認証済みセッションを確立するとともに、複数アプリケーション間でのシングルサインオンを可能にします。
- トークンのリフレッシュとローテーション: 短命なアクセストークンは頻繁に期限切れになるため、リフレッシュの仕組みが必要です。トークンローテーションでは、使用のたびに新しいリフレッシュトークンを生成し、リプレイ攻撃を防ぎます。誰かがリフレッシュトークンを再利用した場合、システムは侵害の可能性を検知し、トークンファミリー全体を失効させることができます。
- ハードウェアトークン認証: デバイスのセキュアエレメント内で鍵ペアを生成して、FIDO2認証子を登録します。認証時には、サービスが暗号学的チャレンジを送信し、認証子が秘密鍵でそれに署名します。サービスは登録済み公開鍵を使用して署名を検証します。
正しく実装されれば、これらのワークフローはその複雑さに見合う価値を発揮します。ここでその効果が現れます。
認証トークンのユースケース
認証トークンは、エンタープライズ環境全体にわたる特定のセキュリティ要件と運用要件に対応します。
- エンタープライズシングルサインオン: SAMLアサーションにより、従業員は一度認証するだけで、繰り返しログインすることなく数十のアプリケーションにアクセスできます。Okta、Azure AD、Ping Federationのようなアイデンティティプロバイダーが、サービスプロバイダーに信頼されるトークンを発行し、パスワード疲れを軽減するとともにアクセスガバナンスを一元化します。
- APIおよびマイクロサービスのセキュリティ: OAuth 2.0アクセストークンは、分散アーキテクチャにおけるサービス間通信を保護します。各microserviceは受信トークンを独立して検証し、共有セッションストアなしでステートレスなスケーラビリティを実現します。
- サードパーティ認可: OAuth 2.0は、ユーザーがパスワードを共有せずにアプリケーションへデータアクセスを許可する「Googleでログイン」のようなシナリオを可能にします。認可サーバーは、アプリケーションがアクセスできる範囲を制限するスコープ付きトークンを発行します。
- モバイルアプリケーションのセッション: JWTはモバイルアプリ向けに持続的な認証を提供します。iOS KeychainまたはAndroid KeyStoreに保存されたトークンはアプリ再起動後も保持され、プラットフォーム固有のセキュアストレージによってセキュリティを維持しながら、シームレスなユーザー体験を提供します。
- マシン間認証: 自動化システムやIoTデバイスは、APIアクセス用トークンを取得するためにクライアント認証情報グラントを使用します。これらのトークンは、人の操作なしで、スケジュールジョブ、監視システム、デバイス通信を認証します。
このパターンはそれらすべてに共通しています。トークンは、繰り返し認証情報を送信する代わりに、受信側システムが単独で検証できるクレームへ置き換えます。
認証トークンの主な利点
トークンベース認証は、従来のセッション管理よりも次の4点で優れています。
- ステートレスなスケーラビリティ: トークンベースのシステムはサーバー側セッション保存の要件を排除し、共有状態なしで個々のサービスが独立して認証情報を検証できるマイクロサービスアーキテクチャを実現します。
- クロスドメインのシングルサインオン: SAML 2.0アサーションとOpenID Connectはシングルサインオンを可能にします。ユーザーは一度認証するだけで、繰り返しログインすることなく複数のアプリケーションにアクセスでき、認証ガバナンスを一元化できます。
- APIセキュリティと ゼロトラスト: OAuth 2.0クライアント認証情報と署名付きJWTを使用したサービス間認証により、不正なサービスが信頼されたサービスになりすますことを防止でき、ゼロトラストアーキテクチャに不可欠です。
- 攻撃対象領域の縮小: 標準ベースの実装は特定の攻撃から保護します。HttpOnly cookieはJavaScriptによるアクセスを防ぎます。SameSite属性はCross-Site Request Forgery（CSRF）攻撃を阻止します。FIDO2トークンは暗号学的オリジンバインディングによってフィッシング耐性を実現します。
ただし、これらの利点にはトレードオフが伴います。スケーラビリティと柔軟性を可能にする同じアーキテクチャ上の判断が、セキュリティチームが対処しなければならない課題も生み出します。
認証トークンの課題と制限
トークンベース認証は、慎重なアーキテクチャ設計を必要とする特定の運用上およびセキュリティ上の課題をもたらします。
- トークン失効の複雑さ: スケーラビリティ上の利点をもたらすステートレス性は、即時のアクセス停止に課題を生みます。ステートレスなトークンは期限切れになるまで有効なままであるため、リフレッシュのオーバーヘッドを増やす短い有効期間、ステートレス性の利点を打ち消すブラックリスト基盤、または失効遅延ウィンドウの受容のいずれかが必要になります。
- トークン有効期間管理のトレードオフ: 短いアクセストークン有効期間は侵害時の潜在的被害を限定しますが、継続的なリフレッシュトークン交換を必要とします。長い有効期間はユーザー体験を改善しますが、トークンが盗まれた場合の露出ウィンドウを拡大します。
- プラットフォーム間での安全なトークン保存: ページ内で実行されるあらゆるスクリプトはlocalStorageとsessionStorageを読み取れるため、単一のCross-Site Scripting (XSS)の欠陥によって、どちらも有効なトークン一覧に変わってしまいます。広く採用されているハイブリッドアプローチでは、リフレッシュトークンをHttpOnly cookieに保存し、アクセストークンをメモリ内に保持し、リフレッシュエンドポイントにCSRFチェックを適用します。メモリ内のアクセストークンは、ホストが侵害された場合のメモリダンプには依然としてさらされますが、それは エンドポイントセキュリティが対処する領域です。モバイルアプリケーションにはプラットフォーム固有の保存が必要です。iOS Keychainはトークンを直接保持し、AndroidはAndroid Keystore内の鍵でそれらを暗号化します。サーバー間通信は、HashiCorp VaultやAWS Secrets Managerのようなシークレット管理システムに属します。
- 鍵ローテーションと暗号管理: 本番環境での鍵ローテーションは調整の複雑さをもたらします。組織はローテーション期間中に複数の有効な署名鍵を維持し、分散サービス全体でローテーションを調整し、鍵識別子（kid）の検証を適切に処理する必要があります。
これらの実装上の課題は、攻撃者がエンタープライズ環境で積極的に悪用する特定の脆弱性を生み出します。
よくある認証トークン実装ミス
認証トークン侵害の大半は、暗号上の欠陥ではなく実装ミスに起因します。こうした一般的な誤りを理解することで、セキュリティチームは強化の優先順位を付けやすくなります。
- 安全でないクライアント側保存: 認証トークンをブラウザーのlocalStorageまたはsessionStorageに保存することは、最も一般的な実装ミスの1つです。ページコンテキスト内で実行されるあらゆるJavaScriptコードが認証トークンへ直接アクセスして外部送信できるため、XSS攻撃に対して即座に脆弱になります。
- 署名検証の失敗: JWT署名を適切に検証しないと、悪用可能な認証バイパス脆弱性が生じます。アルゴリズム混同攻撃では、アルゴリズムヘッダーをRS256（非対称）からHS256（対称）へ操作し、その後公開鍵をHMACシークレットとして使用してトークンに署名します。脆弱なシステムはこれらの改変トークンを受け入れ、権限昇格を許してしまいます。この脆弱性は、CVSS 9.1 CRITICALの重大度評価を持つCVE-2024-54150で文書化されています。一部の実装では、「alg: none」を指定したトークンを受け入れ、事実上、署名なしトークンを有効として処理してしまいます。
- 過度に長いトークン有効期間: トークン有効期間を長く設定しすぎると、持続的なセキュリティリスクが生じます。長寿命トークンは攻撃者に長い機会の窓を与えます。XSSや中間者攻撃によって侵害されると、過度に長い有効期間を持つトークンは、数分ではなく数日から数週間にわたる不正アクセスを可能にします。
- トークン失効メカニズムの欠如: トークン失効機能がないことは、重大なアーキテクチャ上の欠落です。Azure ADのようなSSO実装で使用されるPrimary Refresh Tokens（PRTs）の侵害は、特に問題になります。失効メカニズムがなければ、組織は侵害されたセッションをリアルタイムで終了できず、自然なトークン期限切れに頼らざるを得ません。
- 安全でない鍵管理: 鍵管理の失敗はシステム全体の脆弱性を生みます。鍵取得メカニズムにおけるSQL injection脆弱性により、アプリケーションがkidパラメータ経由でJWT鍵を取得するために脆弱なSQLクエリを使用している場合、署名鍵が露出する可能性があります。JWTペイロードに機密情報を保存すると、JWTクレームはbase64でエンコードされているだけで（暗号化されていないため）、トークンにアクセスできる誰にでも容易に読めてしまい、不必要なデータ露出を生みます。
これらの失敗には名前と日付があります。2022年4月、攻撃者はHeroku and Travis CIから盗まれたOAuthトークンを使用して、npmを含む数十の組織からプライベートリポジトリをダウンロードしました。このページ冒頭で説明したOktaのセッショントークン窃取も同じ仕組みでした。つまり、有効なトークンが誤った主体によって提示され、疑われることなく受け入れられたのです。
これらの失敗はすべて防止可能であり、対策はすでに文書化されています。確立された標準に基づく多層防御が、攻撃者が頼りにするギャップを塞ぎます。
認証トークンのベストプラクティス
認証トークンを保護するには、 NIST SP 800-63B-4、 OWASP、およびIETF仕様などの権威あるセキュリティ標準に基づく多層防御戦略を実装する必要があります。
- HttpOnlyおよびSecure cookieを展開する: HttpOnly cookieに保存したリフレッシュトークンと、メモリ内に保持したアクセストークンを組み合わせます。cookie内容へのJavaScriptアクセスを防ぐHttpOnlyフラグを設定します。HTTPS接続でのみ送信されることを保証するSecureフラグを構成します。CSRF保護のためにSameSite属性を実装します。
- 短命なアクセストークンとローテーションを実装する: リスク許容度に基づいてアクセストークンの有効期間を構成します。トークンローテーションでは、使用のたびに新しいリフレッシュトークンを生成し、リプレイ攻撃を防ぎます。発行したすべてのリフレッシュトークンをjtiクレームで追跡し、ローテーション成功直後に以前のトークンを無効化します。
- 厳格な署名検証を強制する: ヘッダーで「alg: none」が指定されたトークンを明示的に拒否します。署名アルゴリズムが期待される型と一致することを検証し、RSA/HMAC混同攻撃を防ぎます。鍵取得にはパラメータ化クエリを使用してSQL injectionを防止します。
- トークンバインディングを展開する: Conditional Accessポリシーを構成してトークンバインディングを強制し、Trusted Platform Module（TPM）またはSecure Enclave統合を通じて、トークンが元々発行されたデバイス以外で機能しないようにします。
- 失効基盤を実装する: jtiクレームを使用したデータベース支援のトークンファミリー追跡を構築します。セッション失効のための管理インターフェースを作成し、侵害が疑われる際にユーザーがすべてのセッションを失効できる「どこでもログアウト」機能を展開します。
これらのベストプラクティスを導入していても、高度な攻撃者は引き続きトークン侵害の方法を見つけます。防御が持ちこたえないときに重要なのは、不正利用をどれだけ早く可視化できるか、そしてどれだけ早く対処できるかです。
SentinelOneがアイデンティティベースの攻撃を検知する方法
Singularity™ Platformは、エンドポイント、クラウドワークロード、アイデンティティ基盤全体にわたって自律型の検知と対応を提供します。2024 MITRE ATT&CK Evaluations: Enterpriseにおいて、SentinelOneは100%の検知率を記録し、評価対象ベンダー全体の中央値と比べてアラート数を88%削減しました。これは、アナリストが処理できるアラートキューと、放棄せざるを得ないアラートキューの違いです。Purple AI™は、調査そのものを加速します。アナリストは平易な言葉で質問し、文脈付きのアラート要約を受け取ることができ、脅威ハンティングを最大80%高速化できます。
Singularity Identityは、Active DirectoryとEntra IDを アイデンティティ脅威から防御します。その検知は、盗まれたKerberosチケットや偽造されたKerberosチケットを用いたラテラルムーブメントや権限昇格を含め、これらの環境を直接標的とする認証情報攻撃に対して発火します。Storyline™テクノロジーは、進行中の攻撃を再構築し、認証イベントをエンドポイントの挙動と相関付けます。単一のアラートではなく、攻撃チェーン全体を確認できます。検知が発火すると、自律型レスポンスが脅威を封じ込め、ホストを隔離し、 ランサムウェアが暗号化を完了する前に、1-Click rollbackで被害を巻き戻します。
SentinelOneのデモをリクエストして、自社環境でアイデンティティベースの検知がどのように機能するかをご確認ください。
ハイブリッド環境全体でリアルタイムのアイデンティティ保護とエンドツーエンドの可視性を実現し、露出の検出、認証情報の悪用防止、アイデンティティリスクの低減を行います。
重要なポイント
冒頭の東京からの攻撃シナリオですか。あれは、盗まれたトークンがパスワードやMFAプロンプトに一切触れることなく認証を回避したときに起こります。設定ミスのあるトークンは現実的な露出を生みますが、それでもトークンは不可欠です。各タイプには役割があります。JWTはステートレスなマイクロサービス向け、OAuth 2.0はAPI認可向け、SAMLはエンタープライズSSO向け、FIDO2はフィッシング耐性のある認証向けです。どれも、不注意に実装されれば攻撃ベクトルになります。
対策リストは短くまとまっています。リフレッシュトークンはHttpOnly cookieに保存し、アクセストークンはメモリ内に保持し、署名を厳格に検証し、リフレッシュのたびにローテーションします。このページにある失敗の大半は、そのいずれかが未実施であることに加え、構築するより先送りしやすい2つ、すなわち失効基盤と鍵管理に起因します。
XDRとアイデンティティ脅威の検知と対応（ITDR）を追加すれば、誤った手に渡ったトークンは、6か月後の監査指摘ではなく検知として表面化します。 CVE-2024-54150と、 MITRE ATT&CK's October 2024 updateで追跡されている8つの国家支援グループは、トークン悪用が現在進行形で活発であることを示しています。それを止めるための対策はすでに存在しており、あとは導入するだけです。
よくある質問
認証トークンは、ユーザー名とパスワードを繰り返し送信することなく、エンタープライズシステムに対してユーザーの身元を検証する暗号学的な認証情報です。アプリケーションにログインすると、サーバーは認証が正常に完了したことの証明としてトークンを発行します。
デバイスは以降の各リクエストでこのトークンを提示し、サーバーは再度ログインすることなくユーザーの身元を検証できます。一般的な形式には、JSON Web Tokens（JWT）、OAuth 2.0 tokens、SAML assertions、FIDO2 tokens があります。
アクセストークンは、保護されたリソースにアクセスするための短期間有効な認証情報を提供し、通常はNISTの推奨に従って数分以内に期限切れになります。リフレッシュトークンは、現在のトークンの有効期限が切れた際に、認証を繰り返し要求することなく新しいアクセストークンを取得できるようにし、通常は数日から数週間有効です。
このデュアルトークンのアプローチは、アクセストークンの短い有効期間によるセキュリティとユーザーエクスペリエンスのバランスを取ります。トークンローテーションでは、使用のたびに新しいリフレッシュトークンが生成され、前のトークンは無効化されるため、リプレイ攻撃を防止できます。
攻撃者は、localStorageからトークンを抽出するXSS攻撃、送信を傍受する中間者攻撃、侵害されたエンドポイントでのメモリダンプ、CI/CDパイプラインの悪用、CSRFによるセッションハイジャックを通じてトークンを窃取します。
APT28、APT29、APT41、Kimsuky、MuddyWater、OilRig、Sandworm Team、Turlaを含む8つの国家支援グループが、2024年にトークン攻撃機能を更新しました。保護には、HttpOnly Cookie、HTTPSによる安全な送信、デバイスへのトークンバインディング、および異常な使用パターンを検出する振る舞い監視が必要です。
リフレッシュトークンは、JavaScriptによるアクセスとCSRF攻撃を防ぐHttpOnly、Secure、SameSite Cookieに保存します。短期間有効なアクセストークンは、XSSベースの窃取を避けるため、localStorageやsessionStorageではなくメモリに保持します。
モバイルアプリでは、iOS KeychainまたはAndroid KeyStoreを使用します。サーバー間通信では、環境変数や設定ファイルではなく、HashiCorp VaultやAWS Secrets Managerのようなシークレット管理システムを使用します。
JWTにはbase64でエンコードされたクレームが含まれており、トークンにアクセスできる人なら誰でも読み取れます。機密データには、RSA-OAEP-256やAES-GCMなどの標準を通じてペイロード暗号化を提供するJWE (JSON Web Encryption) を使用します。
ただし、より良い実践は、トークンのペイロードに機密データを決して含めないことです。ユーザーIDやロールのような非機密の識別子のみを保存します。機密属性はバックエンドデータベースに保持し、トークン識別子を使用してサーバー側で取得します。
トークン バインディングは、認証トークンを発行先の特定のデバイスに暗号学的に関連付けることで、攻撃者が盗んだトークンを別のシステムで再利用することを防ぎます。トークンは、暗号学的証明を通じて、デバイスの Trusted Platform Module (TPM) または Secure Enclave にバインドされます。
トークンが提示されると、サーバーはトークン署名とデバイス バインディングの両方を検証します。Microsoft Conditional Access や同様のエンタープライズ identity管理ソリューションは、高セキュリティ環境向けにトークン バインディングをサポートしています。
