ユーザーをリダイレクトする

リターンURLの値を保存するために、クッキーやブラウザーセッションを使用することができます。この方法は簡単ですが、クッキーが保持されていない場合は問題が起きる可能性があります。この状況では、2つの別々のユーザーセッションが開始されます。それぞれの目的は異なっており、希望するユーザーエクスペリエンスを実現するために注意が必要です。

• Auth0提供のSSOセッション：Auth0は、シングルサインオン（SSO）を有効にするためのセッションを提供しており、ユーザーが一度だけ資格情報を入力すれば、認証セッションを維持できるようにします。このセッションは、Auth0によって維持され、テナントドメイン（またはCNAME）に関連付けられたクッキーバウンドとして参照されます。Auth0セッションの長さを決定するテナント設定は2つあります。

  • idle_session_lifetimeは、ユーザーが操作しない状態でセッションがどれだけ長く保持されるかを示します。

  • session_lifetimeは、セッションが保持される最長期間です。

  これらの設定は、テナント内のすべてのアプリケーションに適用され、ユースケースに一致するセキュリティモデルに適合している必要があります。

• アプリケーションセッション：アプリケーションにはセッションのコンセプトも含む必要があります。ユーザーセッションを通して、アプリケーションは追加トークンの要求、または有効期限切れトークンの更新をする必要があるかもしれません。これらのトークンをアプリケーション内に保存し、セキュアクッキーを使用してブラウザーに返されたIDで参照する必要があります。

ユーザーがAuth0で認証したら、このセッションがどれだけ保持されるかはアプリケーションによります。

別の方法として、stateパラメーターを使用してディープリンクを作成し、コールバックで解釈し、転送先のパスを決定できます。この方法は、実装に多少の時間がかかりますが、リダイレクトが完了した際に、アプリケーションが必要な情報を確実に保有しているようにします。詳細ついては、「OAuth0 2.0の状態パラメーターを使って攻撃を防ぎ、ユーザーをリダイレクトする」をお読みください。

この方法を使用すると、認証要求を開始する際にランダムな値を送り、応答を処理する際に受け取った値を検証します（これはクライアントアプリケーション側でセッションや他の媒体に検証を行うための情報を保存しておくことを意味します）。状態が一致しない応答を受け取る場合は、受信者側が望んでいない要求に対する応答か、真の応答を偽造しようとしていることになるため、攻撃の標的になっているかもしれないと推測することができます。

アプリケーションタイプは、アプリの応答検証を許可するデータを保存する最適な場所を決定します。たとえば、進行中のウェブアプリがSPAフレームワークを利用している場合、ローカルストレージにこの情報を保存することができます。一方、従来のWebアプリフレームワークでは、サーバー側のセッションに保存することになります。