OIDC のログアウトとセッション管理の実装:完全ガイド
OIDC 認証とセッション管理を深く探ります。安全なセッション処理のために OIDC の RP によるログアウト、IdP によるログアウト、バックチャネルログアウトの実装方法を学びましょう。
OIDC 認証とセッション管理を深く探ります。安全なセッション処理のために OIDC の RP によるログアウト、IdP によるログアウト、バックチャネルログアウトの実装方法を学びましょう。
OpenID Connect (OIDC) は OAuth 2.0 プロトコルの上に構築されたシンプルなアイデンティティ層です。これによりクライアントは、認可サーバーによって行われた認証を基にエンドユーザーのアイデンティティを確認し、エンドユーザーの基本的なプロファイル情報を相互運用可能かつ REST に似た方法で取得できます。
OIDC は使いやすく実装しやすいように設計されており、シンプルさと柔軟性に重点を置いています。ウェブアプリケーション、モバイルアプリ、API でのシングルサインオン (SSO) とアイデンティティ認証に広く使用されています。
OIDC における認証状態とセッション管理を理解することが重要です。この記事では、Identity Provider (IdP) とリライングパーティー (RP) またはサービスプロバイダー (SP) 間のインタラクションにおける OIDC セッションとユーザー認証状態の管理方法を説明します。
この記事ではいくつかの重要な用語を含んでいます。
OIDC セッションとユーザー認証状態管理をよりよく理解するために、ウェブアプリケーション向けの OIDC 認証フローを簡単に見てみましょう。:
ユーザーが IdP にログインするとサインインセッションが確立されます。このセッションは IdP でのユーザーの認証状態を追跡するために使用されます。このセッションには通常、ユーザーのアイデンティティ、認証時間、およびセッションの有効期限などの情報が含まれます。ユーザーが最初にログインした際に作成され、ユーザーがログアウトするか、セッションが期限切れになるまで維持されます。
セッション状態を維持するために、ユーザーのブラウザにセッションクッキーが安全に設定されます。ユーザーのセッションを識別し、以降の認証リクエストでユーザーを認証するために、セッションクッキーが使用されます。このクッキーは通常、クライアント側からのアクセスを防ぎ、安全な通信を確保するために HttpOnly と Secure フラグを設定されます。
ユーザーが異なるデバイスやブラウザからアクセスするそれぞれの RP に対して、別々のユーザーのサインインセッションが確立されます。これは、ユーザーの認証状態が各 RP ごとに個別に維持されることを意味します。ユーザーがある RP からログアウトしても、他の RP ではユーザーは認証されたままになります。この状態はセッションが期限切れになるか、ユーザーがすべての RP からログアウトするまで続きます。
この中央集権的なセッション管理により、IdP はユーザーのセッションがアクティブで同じユーザーエージェント(デバイス/ブラウザ)からの認証リクエストがある限り、複数の RP にわたって一貫した認証状態を維持できます。この仕組みは SSO 機能を可能にし、ユーザーが再ログインする必要なく複数の RP にアクセスできます。
OIDC では、クライアントアプリケーション (RP) は IdP が発行するトークンに依存してユーザーのアイデンティティと認証または認可の状態を確認します。クライアント側の "サインインセッション" は IdP によって発行されるトークンによって維持されます。
offline_access スコープが要求され承認されると、クライアントアプリケーションはリフレッシュトークンを受け取ることがあります。これはユーザーに再認証を要求することなくユーザーの認証状態を延長する手段を提供します。クライアントアプリケーションは現在のアクセストークンが期限切れたときに新しいアクセストークンを取得するためにリフレッシュトークンを使用できます。リフレッシュトークンが有効である限り、ユーザーの認証状態をユーザーの操作なしに維持できます。これらのトークンの組み合わせにより、クライアントアプリケーションはユーザーの認証状態を維持し、ユーザーに代わって保護されたリソースにアクセスできます。クライアントアプリケーションはこれらのトークンを安全に保存し、そのライフサイクルを管理する必要があります。(例: SPA アプリケーションの場合、トークンはブラウザのローカルストレージまたはセッションストレージに保存できます。ウェブアプリケーションの場合、トークンはサーバー側のセッションデータまたはクッキーに保存できます。)
OIDC ではサインアウトプロセスが複数の側面を持っており、中央集権的に IdP が管理するサインインセッションと分散したクライアント側のトークンの 2 つが関与しているためです。
クライアント側でユーザーの認証状態をサインアウトまたは無効化するのは比較的簡単です。クライアントアプリケーションはユーザーのブラウザまたはメモリから保存されたトークン( ID トークン、アクセストークン、リフレッシュトークン)を削除できます。このアクションにより、クライアント側でユーザーの認証状態が実質的に無効化されます。
独自にユーザーサインインセッションを管理するウェブアプリケーションの場合、追加のステップが必要になることがあります。これには、セッションクッキーおよび Identity Provider または IdP によって発行されたトークンなどのセッションデータをクリアすることが含まれ、ユーザーが完全にサインアウトされていることを確認します。
IdP は各ユーザーに対して中央集権的なサインインセッションを維持しています。このセッションがアクティブである限り、クライアント側のトークンをクリアした場合でも、ユーザーは自動的に再認証される可能性があり、クライアントアプリケーションに新しいトークンを再発行することが可能です。
IdP からユーザーを完全にサインアウトするには、クライアントアプリケーション (RP) が IdP にサインアウトリクエストを行うことができます。アプリケーション (RP) はユーザーを IdP の エンドセッションエンドポイント にリダイレクトし、サインインセッションを終了してセッションクッキーをクリアする必要があります。これにより、同じ中央集権的なセッションを共有するすべてのアプリケーション (RPs) 間での完全なサインアウトを確保します。サインインセッションが終了した後、IdP が同じセッションを共有する任意のリンクされた RP からトークンリクエストを受け取った場合、IdP はユーザーに再認証を促します。
場合によっては、あるアプリケーション (RP) からユーザーがサインアウトした際に、それと同時に他のすべてのアプリケーション (RPs) からも自動的にサインアウトされたい場合があります。これには バックチャネルログアウト メカニズムを使用できます。
IdP が RP からサインアウトリクエストを受け取ると、サインインセッションをクリアするだけでなく、同じセッションを使用し、バックチャネルログアウトエンドポイントを登録したすべての RP にバックチャネルログアウト通知を送信します。
RPs がバックチャネルログアウト通知を受け取ると、ユーザーのセッションおよびトークンをクリアするために必要なアクションを実行し、すべてのアプリケーションからユーザーが完全にサインアウトされたことを確認します。