ユニバーサルポータルのアーキテクチャ

ユニバーサルポータルでユーザーをサインインさせる方法、リソースサーバー向けのアクセストークンを取得する方法、ステップアップ認証やFormを処理する方法、セッションを管理する方法について説明します。

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 ドメインとカスタムドメインのどちらでも動作します。

exports.onExecutePostLogin = async (event, api) => {
    const { protocol } = event.transaction ?? {};
    const { hostname, body } = event.request ?? {};

    const isRefreshTokenExchange = protocol === "oauth2-refresh-token";
    const isMyAccountApi = body?.audience === `https://${hostname}/me/`;
    const deletesAuthenticator = body?.scope?.includes("delete:me:authentication_methods");

    if (isRefreshTokenExchange && isMyAccountApi && deletesAuthenticator) {
        api.authentication.challengeWithAny([{ type: "email" }, { type: "otp" }]);
    }
};

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に関するエラーを解決します。