このブログはこちらの英語ブログの機械翻訳です。
デジタル技術がますます普及するにつれて、個人情報およびビジネス情報の保護がこれまで以上に重要になっています。アイデンティティは、企業および消費者アプリケーションの主要なセキュリティ境界として機能します。サイバー攻撃とデータ侵害が増加し続けるにつれて、機密データの保護は、個人と組織にとって重要な優先事項となっています。
によると、Verizon Data Breach Investigations Report（2024年） breaches（侵害）の86%は、パスワード、OAuth/OpenID Connectトークン、APIキーなどの盗まれた認証情報に起因しています。これらのトークンは通常、ユーザーを複数のWebサイトに対して認証および承認したり、ユーザーが長期間ログインしたままにしたり、Webサイトがユーザーエクスペリエンスをパーソナライズするために使用できるユーザーに関するプロファイル情報を取得したりするために使用されます。アプリケーションはこれらのトークンを使用して、APIや機密情報などの保護されたリソースにアクセスできます。
これらの特権アーティファクト（トークン）の保護は、ミッションクリティカルな要件となっています。以下に、OAuthとOpenID Connectのトークンを保護するために実装できるベストプラクティスを示します。
OAuth/OpenID Connectのトークンとアプリケーションの種類の簡単な入門
まず、さまざまなOAuthとOpenID Connectのトークンとアプリケーションの種類について説明します。
トークンの種類
トークンは、ユーザーのIDを検証し、保護されたリソースへのアクセスを許可するために使用される安全なデジタル認証情報です。トークンのペイロードには通常、ユーザープロファイル、アクセス許可、メタデータに関する情報が含まれており、認証と整合性のために暗号で署名されています。
IDトークン: 名前が示すように、IDトークンはプリンシパル（つまり、エンドユーザー）を識別するために使用されます。これらにはユーザーに関する情報が含まれており、OpenIDプロバイダーがユーザーの認証に成功したことを証明します。このトークンの対象者はOpenIDクライアント、つまりアプリケーション自体です。
アクセストークン: OpenID Connectは、認証目的でOAuth 2.0と連携して動作します。OAuth 2.0アクセストークンは、ユーザーに代わってバックエンドAPIを呼び出すアクセス許可をアプリケーションに委任します。トークンの対象者はバックエンドAPI（つまり、リソースサーバー）です。
リフレッシュトークン: アクセストークンとIDトークンは短命であり、一定期間後に有効期限が切れます。リフレッシュトークンは、アプリケーションが認証サーバーから新しいアクセストークンとIDトークンのペアを要求するために使用できる有効期間の長い許可です。リフレッシュトークンの対象者は認証サーバー自体です。
アプリケーションの種類
OAuth仕様によると、アプリケーションはconfidential（機密）またはpublic（公開）として分類できます。主な違いは、アプリケーションが認証情報（クライアントIDやシークレットなど）を安全に保持できるかどうかです。。
パブリックアプリケーション: これらのアプリケーションは、認証サーバーが提供するクライアントシークレットまたは認証情報を安全に保存できません。パブリックアプリケーションの例としては、ブラウザーで実行される最新のJavaScriptベースのクライアント側アプリケーション（シングルページアプリケーション）や、モバイルデバイスやデスクトップにインストールされるネイティブアプリケーションなどがあります。
機密アプリケーション: 一方、機密アプリケーションは、クライアント認証情報を安全に保存し、機密性を維持できます。これらのアプリケーションは安全なサーバー上で実行されるため、認証情報はエンドユーザーがアクセスできません。機密アプリケーションの例としては、従来のWebアプリケーションやバックエンドのサーバー間アプリケーションなどがあります。
トークンを保護するための5つのベストプラクティス
1. クライアント認証に非対称暗号を使用する
クライアント認証を使用すると、クライアントアプリケーションのIDを検証して、クライアントのなりすましを防ぎ、保護されたリソースへの安全なアクセスを有効にできます。パスワードが弱いユーザー認証要素と見なされるのと同じように、クライアントシークレットは弱いクライアント認証方法です。クライアントシークレットはリクエストの本文に含まれており、共有シークレットに依存しているためです。
クライアントシークレットとは異なり、mTLSや署名付きJSON Web Token（JWT）（private key JWTとも呼ばれます）などの非対称暗号化技術はネットワーク経由で送信されることがないため、キーの漏洩や中間者攻撃のリスクを大幅に軽減できます。クライアント認証は、機密クライアントにのみ適用されます。したがって、アプリケーションを構築する際は、特に機密情報を扱う場合は、堅牢なクライアント認証方法の使用を検討してください。クライアント認証方法の詳細をご覧ください.
2. パブリッククライアントにPKCEを採用する
モバイルおよびWebベースのアプリケーションの台頭により、パブリッククライアントが増加している可能性があります。クライアント認証はパブリッククライアントアプリケーションでは使用できないため、Proof Key for Code Exchange (PKCE)を使用すると、認証リクエストを開始した元のクライアントのみがコードをトークンと交換できるようになります。
PKCEにより、攻撃者が認証サーバーのトークンエンドポイントで盗まれた認証コードを悪用できなくなります。PKCEは当初パブリッククライアント向けに設計されましたが、OAuth 2.1では、認証コードインジェクション攻撃および傍受攻撃に対する追加の保護を提供するとして、クライアント認証に加えて機密クライアントにもPKCEを推奨しています。認証コードフローでのPKCEの詳細をご覧ください.
3. Proof of Possessionを実装する
Proof of Possessionは、OAuthアクセストークンの使用を許可されたクライアント（ブラウザーベースのアプリ）に制限する方法です。これは、トランスポートレベルでのmTLSベースのトークンバインディングまたはアプリケーションレベルでのDPoPベースのトークンバインディングの2つの方法で実現できます。mTLSのスケーラビリティ、デプロイのしやすさ、および使いやすさに関する課題を考慮すると、Proof of Possession（DPoP）を実証することが、Proof of Possessionを実装するための推奨される方法です。DPoPは、攻撃者がトークンを盗んで再生するのを防ぐため、OAuth 2.0セキュリティの大幅な改善を表しています。OAuth 2.0 DPoPの詳細をご覧ください.
4. トークンライフサイクル管理プロセスを検討する
侵害された場合、有効期間の長いトークンは、不正アクセスにつながる可能性のある悪意のあるアクティビティのためのより広い機会の窓を提供します。したがって、アクセストークンの有効期間を短く設定し、必要に応じて継続的に更新することをお勧めします。
漏洩したリフレッシュトークンに関連するリスクを軽減するために、使用するたびにリフレッシュトークンを安全にローテーションするリフレッシュトークンローテーションを検討してください。リフレッシュトークンをローテーションすると、リフレッシュトークンの再利用を検出するのに役立ちます。検出すると、認証サーバーはリフレッシュトークンと、ユーザーが認証されてから発行されたすべてのアクセストークンを無効にすることができます。これにより、トークンの侵害およびリプレイ攻撃からアプリケーションを保護します。リフレッシュトークンローテーションの詳細をご覧ください.
ユーザーがアプリケーションからサインアウトしたときにすべてのトークンを取り消すことも重要です。トークンが取り消されると、すぐに無効になり、そのトークンを使用して保護されたリソースにアクセスできなくなります。トークンの取り消しは、ユーザーがログアウトを開始したとき、または予期しないイベントが発生してユーザーのリスクプロファイルが上昇したときに発生する可能性があります。グローバルトークン取り消しを使用すると、外部のセキュリティプロバイダーおよび認証情報プロバイダーは、認証サーバーにユーザーの既存のすべてのトークンを取り消すように要求できます。このアクションでは、新しいトークンが発行される前に、ユーザーが再認証する必要があります。詳細については、グローバルトークン取り消しおよびユニバーサルログアウトをご覧ください。
5. 最小特権の原則を適用する
OAuth/OpenID Connectアプリケーションは、アプリケーションのセキュリティ体制を強化し、潜在的なリスクを最小限に抑えるために、最小特権の原則を使用して設計および実装する必要があります。アプリケーション固有のポリシーを活用して、特定の場所、デバイスの種類、リスクプロファイルなどから特定のアプリケーションに適切なユーザーのみがアクセスできるようにすることができます。
OAuthスコープを使用して、アクセストークンで特定のアクセス許可を付与できます。スコープは、アプリケーションが過剰なアクセス許可を要求しないように、可能な限り細かくする必要があります。動的に変化するきめ細かいアクセスを必要とするユースケースでは、OAuthフレームワークに基づいてモデル化することをお勧めします。これにより、トークンが過剰なスコープとクレーム関連情報で肥大化するのを防ぐことができます。詳細については、アプリケーションサインオンポリシー、エンタイトルメント、およびきめ細かい承認をご覧ください。
このブログでは、トークンセキュリティを強化するための重要な側面をいくつか紹介しましたが、OAuthワーキンググループは、セキュリティのベストプラクティスの網羅的なリストを作成しています。アプリケーションが最新のセキュリティトレンドおよびアイデンティティ標準に準拠していることを確認するために、公式仕様を定期的に確認してください。
このブログ投稿について質問がありますか？eng_blogs@okta.comまでご連絡ください。
Oktaの洞察力に富んだエンジニアリングブログで、知識をさらに深めてください。
Oktaの情熱的で優秀なエンジニアチームで働きませんか？採用情報ページをご覧ください。
Oktaは、最新かつ高度なアイデンティティ管理の可能性を解き放ちます。詳細は、セールス担当者にお問い合わせください。
