Skip to main content

​
セッションの動作

委譲セッションは、通常の Auth0 セッションとはいくつかの点で異なります。
  • 認可コードフローのみ。 委譲セッションの確立に SAML、WS-Federation、Implicit フローは使用できません。
  • リフレッシュトークンなし。 委譲セッション中に発行されるトークンには、offline_access スコープは含まれません。
  • 対話型プロンプトなし。 委譲セッション中は、MFA、同意、登録のプロンプト (たとえば、パスキーや MFA 認証要素の登録) を完了できません。これらのいずれかがトリガーされた場合、ユーザーにプロンプトを表示する代わりに、リクエストは interaction_required で失敗します。
  • 既存のセッションは委譲アクセスをブロックします。 ブラウザーにアクティブな Auth0 セッションがすでに存在する場合、委譲セッションの試行は、先にログアウトするようユーザーに求めるエラーページを表示して失敗します。これは、そのドメイン上のすべてのアクティブなセッション (対象ユーザー自身のセッション、または別のユーザー向けに確立された以前の委譲セッション) に適用され、対象ユーザーに属するセッションだけに限りません。これは、既存のセッションを取り消して続行する標準のネイティブからWebへのSSOとは異なります。詳細については、ネイティブからWebへのSSOとセッションを参照してください。
    たとえばサポート担当者などのアクターは、同じドメインで別のユーザー用の委譲セッションを確立する前に、現在の委譲セッションからログアウトする必要があります。
  • デフォルトでは一時的です。 セッション Cookie は非永続的に設定されるか、ブラウザーを閉じると破棄されます。
  • セッション有効期間は 2 時間に固定。 委譲セッションでは、絶対タイムアウトとアイドルタイムアウトの両方が 2 時間にハードコードされており、現在は設定できません。発行されるアクセストークンも同じく 2 時間で期限切れになります。
  • デバイスバインディング。 委譲セッションでは常に IP ベースのデバイスバインディングが適用されます。標準のネイティブからWebへのSSOで使用される設定可能なデバイスバインディングとは異なり、無効にしたり ASN に変更したりすることはできません。委譲セッションでは、信頼できる IP を判定する際に、ネイティブからWebへのSSOと同様に is_token_endpoint_ip_header_trusted および auth0-forwarded-for が考慮されます。
  • アクターは単一レベルのみ。 Session Transfer Token は、アクターを 1 レベルのみ受け入れます。Custom Token Exchange のアクセストークンでは最大 5 レベルまで許可されるネストされたアクターは、Session Transfer Token では拒否されます。
  • 委譲セッションでもクライアントユーザーレコードは書き込まれます。 Action で ID トークンにカスタムクレームを設定した場合、それらは対象ユーザー自身の通常のセッションからの /userinfo 呼び出しにも表示されます。
  • ユーザーグラントは自動作成されません。 委譲セッションによる永続的な副作用を残さないよう、session.actor が存在する間は作成されません。
  • 最終ログイン、ログイン回数、最終ログイン IP は更新されません。
  • ウェルカムメール は送信されません。

​
Actions

event.session.actor は、委任セッション中のPost-Login Actionsで使用でき、Session Transfer Token の発行時に setActor() に渡された アクター object がそのまま含まれます。

​
モニタリング

委譲セッションでは、専用のテナントログイベントタイプが生成されます。 これらの各ログエントリには、監査用としてログの詳細にアクターの sub が含まれます。また、ターゲットクライアントで allow_delegated_access が有効になっていないために委譲セッションがブロックされた場合は、警告 (w) ログも出力されます。詳細については、ターゲット Web アプリケーションを設定するを参照してください。