IAP セッションの管理

このページでは、Identity-Aware Proxy（IAP）が期限切れセッションのリクエストを処理する方法を説明します。また、AJAX アプリのリクエストと WebSocket リクエストが成功するようにする方法についても説明します。

IAP セッションフロー

標準の IAP ログインフローを使用すると、ユーザーは Google ログインセッションを参照するセッション Cookie を受信します。IAP は、この Cookie を使用して、ユーザーが引き続きログイン状態であることを確認します。IAP は、IAP で保護されたアプリにアクセスする前にユーザーがログインすることを要求します。

IAP セッションは定期的に更新されます。ただし、ユーザーが Google アカウントを使用してログインする場合、IAP セッションもユーザーの Google ログインセッションに関連付けられます。この場合、IAP では次のいずれかの状況に限り、ユーザーが再度ログインする必要があります。

ユーザーが自分のアカウントからログアウトした
アカウントが停止している
アカウントのパスワードのリセットが必要

ユーザーがログアウトすると、IAP は数分以内に Google アカウントの状態を検出します。検出すると、IAP はセッションを無効にします。

IAP は、有効なセッション中にすべてのリクエストの Identity and Access Management（IAM）承認を再確認します。IAP で保護されたアプリの IAM アクセスポリシーの更新には、数分かかる場合があります。

IAP のセッション有効期限

Google アカウントを使用したログインフローの場合、IAP セッションはもとになった Google ログインセッションに関連付けられ、認証ヘッダーで送信された JWT 内の exp クレームに関係なく、そのセッションが期限切れになった場合のみ期限切れになります。

プログラムによる認証の場合、IAP は認証ヘッダーで送信された JWT の exp クレームを処理します。

Identity Platform のログインフローでは、ユーザーがログアウトしてから 1 時間後まで IAP セッションが有効です。

WebSocket リクエスト

IAP は、最初のリクエストに対してのみ WebSocket をサポートし、承認を継続的にチェックしません。WebSocket リクエストを受信すると、HTTP Upgrade リクエストで開始します。IAP は、これを標準の HTTP GET リクエストとして評価します。リクエストが承認されると、IAP はリクエストをサーバーに渡して、永続的な接続を開きます。その後、IAP はリクエストのモニタリングやセッションの更新を行いません。

期限切れセッションのレスポンス

IAP は、リクエストのタイプに応じて、期限切れセッションに対して異なるレスポンスを返します。

AJAX 以外のリクエスト

AJAX 以外のリクエストの場合、ユーザーはログインフローにリダイレクトされ、セッションが更新されます。ユーザーがまだログインしている場合、このリダイレクトは透過的です。

AJAX リクエスト

Chrome などのブラウザは、サードパーティ Cookie を段階的に廃止しています。サードパーティの Cookie が無効になっていると、このページにある AJAX リクエストを行う際の推奨事項は使用できません。ただし、AJAX リクエストのソースとターゲットの両方が同じサイトからのものである場合、推奨事項は提示されます。

Chrome でサードパーティの Cookie を管理する手順については、Chrome で Cookie を削除、許可、管理するをご覧ください。

IAP は Cookie を使用してユーザーセッションを管理します。また、ログインフローの一環としてセッションを確立するための一連のリダイレクトを利用します。アプリケーションがクロスオリジンリソースシェアリング（CORS）を使用して、IAP で保護されたアプリケーションに対して AJAX リクエストを行う場合、セッションの確立が常に可能とは限りません。

IAP で保護されたアプリケーションへの CORS リクエストを正常に行うには、帯域外で IAP セッションを確立する必要があります。target_domain が IAP で保護されたアプリケーションをホストしている source_domain->target_domain から CORS リクエストを送信する AJAX リクエストでは、target_domain で確立されたセッションが存在する必要があります。source_domain と target_domain の間で Cookie を共有する方法はありません。

target_domain でセッションが確立されたら、デベロッパーはリクエストで送信される認証情報を有効にする必要があります。デフォルトで、JavaScript メソッドはリクエストに Cookie を添付しません。リクエストで認証情報を有効にするには、XMLHttpRequest オブジェクトを使用して送信されるリクエストで withCredentials プロパティを true に設定し、Fetch API では、credentials オプションを include または same-origin に設定する必要があります。

次のガイドでは、ウェブデベロッパーが IAP セッションを正常に確立して更新できるようにするためのパターンをおすすめしています。

IAP レスポンスについて理解する

AJAX リクエストの場合、IAP は HTTP 401: Unauthorized ステータスコードを返します。AJAX リクエストの検出は完全には行えません。AJAX リクエストに対して 401 ステータスコードではなく 302 ステータスコードのレスポンスが返される場合、値が "XMLHttpRequest" の X-Requested-With ヘッダーを AJAX リクエストに追加できます。これは、リクエストが JavaScript から発生したものであることを IAP に伝えます。

HTTP `401` AJAX レスポンスの処理

アプリケーションが HTTP 401 を受信した後に IAP セッションを確立するために、アプリケーションは、URL target_domain + ?gcp-iap-mode=DO_SESSION_REFRESH の新しいウィンドウを開くことができます。これは、target_domain で IAP セッションを確立するための特別なハンドラです。ウィンドウが開いたままになっている場合、セッションが定期的に更新され、必要に応じてユーザー入力を求めます。必要に応じて、ユーザーはウィンドウを閉じることもできます。デベロッパーコードの HTTP 401 ステータスのハンドラは、必要に応じてセッションの更新用のウィンドウを再度ポップアップします。

ステップ 1: アプリのコードを変更する

次の例では、HTTP 401 ステータスコードを処理し、ユーザーにセッションの更新リンクを提供するようにアプリのコードを変更する方法を示します。

if (response.status === 401) {
  statusElm.innerHTML = 'Login stale. <input type="button" value="Refresh" onclick="sessionRefreshClicked();"/>';
}

ステップ 2: onclick ハンドラをインストールする

次のサンプルコードでは、セッション更新後にウィンドウを閉じる onclick ハンドラをインストールします。

var iapSessionRefreshWindow = null;

function sessionRefreshClicked() {
  if (iapSessionRefreshWindow == null) {
    iapSessionRefreshWindow = window.open("/?gcp-iap-mode=DO_SESSION_REFRESH");
    window.setTimeout(checkSessionRefresh, 500);
  }
  return false;
}

function checkSessionRefresh() {
  if (iapSessionRefreshWindow != null && !iapSessionRefreshWindow.closed) {
    fetch('/favicon.ico').then(function(response) {
      if (response.status === 401) {
        window.setTimeout(checkSessionRefresh, 500);
      } else {
        iapSessionRefreshWindow.close();
        iapSessionRefreshWindow = null;
      }
    });
  } else {
    iapSessionRefreshWindow = null;
  }
}