メインコンテンツへスキップ
Portalは、Auth0がホストするサーバー側のアプリケーションです。Portalサーバーはユーザーのサインインを処理し、ユーザーのトークンを保持して、ユーザーに代わってリソースサーバーを呼び出します。アクセストークンやリフレッシュトークンがブラウザーに渡ることはなく、ブラウザーが保持するのは安全なセッションクッキーのみです。 以下のセクションでは、Portalに関わるアクター、ユーザーのサインイン方法、コンポーネントによるリソースサーバーの呼び出し方法、およびステップアップ認証、Form、セッションの仕組みについて説明します。 最初のPortalを作成するには、Universal Portalsクイックスタートを参照してください。アプリケーションからPortalを開くには、Portalにアクセスするを参照してください。Portalアプリケーションを構成するには、Universal Portals用にアプリケーションを構成するを参照してください。

アクター

  • ブラウザー:Portalとコンポーネントを表示します。
  • Portalサーバー:ユーザーのサインインを処理してトークンを保存し、コンポーネントからの呼び出しをリソースサーバーへプロキシします。
  • Auth0:ユーザーのサインインを処理し、トークンを発行する認可サーバーです。
  • My Account APIとMy Organization API:コンポーネントの呼び出し先となるリソースサーバーです。
  • Formsバックエンド:Auth0 Formsとそのフローを実行します。

シングルサインオンでのアクセス

ユーザーがポータルのURLを開くと、ポータルサーバーはProof Key for Code Exchange (PKCE) を使った認可コードフローを開始します。ユーザーがすでにAuth0のセッションを持っている場合、Auth0はログインプロンプトを表示せずに認可コードを返します。ポータルサーバーはこのコードをIDトークン、アクセストークン、リフレッシュトークンと交換して保存し、続いてセッションクッキーを設定します。 ユーザーにAuth0のセッションがない場合、Auth0はコードを返す前にログインページを表示します。

セッション転送トークンを使用したアクセス

ネイティブアプリケーションは、ポータルのURLにセッション転送トークンを含めて渡すことができます。ポータルサーバーはこのトークンを/authorizeに転送します。Auth0はトークンを検証すると、と同様に、プロンプトを表示せずにユーザーをサインインさせ、コードを返します。セッション転送トークンは1回限り有効で、60秒で期限切れになります。Auth0がトークンを拒否した場合は、ユーザーにログインページが表示されます。 このシナリオを実装するには、ネイティブアプリケーションからPortalを開くを参照してください。

コンポーネントからリソースサーバーへの呼び出し

コンポーネントがブラウザーからリソースサーバーを直接呼び出すことはありません。代わりに、必要なオーディエンスとスコープを指定して、ポータルサーバーの /portals/{slug}/proxy/... にリクエストを送信します。ポータルサーバーはアクセストークンを付与したうえで、リクエストを API に転送します。

アクセストークンの発行

ポータルでは常にが必要です。ポータルサーバーは、コンポーネントが呼び出す各リソースサーバー向けのアクセストークンを発行する主な仕組みとして、このリフレッシュトークンを使用します。オーディエンス間の切り替えにはMulti-Resource Refresh Token (MRRT) を利用するため、ユーザーは1回サインインするだけで済みます。ポータルはアクセストークンを有効期限が切れるまで再利用し、期限が切れると新しいトークンを発行します。 ポータルアプリケーションには、リソースサーバーごとに2つの設定が必要です。スコープを許可するクライアントへの認可と、トークン交換を許可するリフレッシュトークンポリシーです。詳細については、「Multi-Resource Refresh Token」をお読みください。

許可されるリソースサーバー

コンポーネントからの呼び出し先は、テナントの My Account API と My Organization API に限られます。さらに、そのうちポータルアプリケーションがクライアントへの認可を持つ API のみが対象となります。推奨される設定では、両方の API に認可を付与します。それ以外のオーディエンスに対するリクエストは、ポータルサーバーによって 403 で拒否されます。

レート制限

多要素認証 (MFA) またはパスキーのコンポーネントがデータを読み込む際にMy Account APIから429 Too Many Requestsが返された場合、Portalはそのコンポーネントの代わりに「Too many requests」というメッセージと再試行ボタンを表示します。

ステップアップ認証

オペレーションに MFA が必要かどうかは、テナントのポリシーとアクションによって決まります。たとえば、テナントに次の post-login アクションが設定されているとします。このアクションは、リフレッシュトークン交換で、認証方法を削除するスコープを含む My Account API へのアクセスが要求された場合に、MFA チャレンジを求めます。ドメインはリクエストのホスト名から取得されるため、このアクションは Auth0 ドメインとカスタムドメインのどちらでも動作します。
Portal がそのオーディエンスとスコープのアクセストークンをリクエストすると、Auth0 はアクションを実行してユーザーに認証要素の選択を求め、mfa_required を返します。Portal はポップアップで MFA チャレンジを開始し、ユーザーがチャレンジを完了すると元のリクエストを再試行します。詳しくは、「Action Triggers: post-login - API object」をお読みください。

Formsの送信

Auth0 Formはポータルページ内に表示されますが、そのリクエストはポータルサーバーを経由せず、ブラウザーからFormsのバックエンドへ直接送信されます。フローを実行するのはFormsのバックエンドです。フローがAPIを呼び出す際は、Forms vault接続の認証情報が使用されます。このAPIはリソースサーバーで、通常はManagement APIですが、任意のAPIを指定することもできます。 Formは、Portalの読み込み時にユーザーのIDトークンからコンテキストを受け取ります。詳しくは、「Formsコンテキスト変数」を参照してください。

セッションとトークンの有効期間

Portal には 2 つのセッションと 2 種類のトークンがあります。
  • Auth0 セッション:ユーザーがサインインすると Auth0 によって設定されます。テナントのセッション設定で制御されます。
  • Portal セッション:Portal のセッションクッキーです。無操作状態が 1 時間続くか、サインインから 1 日が経過するかのいずれか早い時点で終了します。
  • リフレッシュトークン:Portal サーバーがアクセストークンを発行するための認証情報です。すべての API 呼び出しがこれに依存するため、有効期間は Portal セッションに合わせて設定してください。
  • アクセストークン:コンポーネントが必要とする時点で発行され、有効期限が切れるまで再利用されます。有効期間は、セキュリティポリシーに従ってリソースサーバーで設定してください。
Portal セッションが終了すると、Portal はユーザーを Auth0 にリダイレクトし、再度サインインを求めます。 リフレッシュトークンの有効期限がポータルのセッションより先に切れると、ユーザーが再度サインインするまでAPI呼び出しは失敗します。これを防ぐには、Universal Portals用にアプリケーションを設定するに記載されている有効期間を設定してください。

次のステップ

Universal Portalsのクイックスタート

数分で最初のPortalを作成できます。

Universal Portals用にアプリケーションを構成する

アクセストークンの発行に必要なクライアントグラントとリフレッシュトークンのポリシーを設定します。

Portalsにアクセスする

アプリケーションからユーザーをPortalへ誘導します。

Universal Portalsのトラブルシューティング

サインイン、セッション、APIに関するエラーを解決します。