サイレント認証の設定

サイレント認証を使用して、ユーザーのアプリケーションへのログイン状態を維持する方法を説明します。

OpenID Connect protocol は、認証リクエストで prompt=none パラメーターをサポートしており、アプリケーションはこれによって 認可サーバー がユーザー操作 (認証、同意、または MFA など) を一切表示してはならないことを示せます。Auth0 は、要求されたレスポンスをアプリケーションに返すか、ユーザーがまだ認証されていない場合や、続行前に何らかの同意またはプロンプトが必要な場合はエラーを返します。

SPA で Implicit Flow を使用すると、明示的な緩和策が必要となるセキュリティ上の課題が生じます。SPA でセッションを更新するには、Silent Authentication と組み合わせて Authorization Code Flow with PKCE を使用できます。

ブラウザーにおけるユーザープライバシー制御の最近の進展により、サードパーティ Cookie へのアクセスが妨げられ、ユーザーエクスペリエンスに悪影響が生じています。そのため、ブラウザーベースのフローでは リフレッシュトークンローテーション を使用する必要があります。これにより、SPA でリフレッシュトークンを安全に使用できるほか、ITP のようなブラウザープライバシー技術による UX の中断を招くことなく、エンドユーザーはリソースにシームレスにアクセスできます。

​

サイレント認証リクエストを開始する

サイレント認証リクエストを開始するには、ユーザーを Auth0 の認証 API の /authorize エンドポイント にリダイレクトする際に、prompt=none パラメーターを追加します。 (認証リクエストに含まれる各パラメーターは、アプリの要件に応じて異なります。)

例:

prompt=none パラメーターを指定すると、Auth0 は指定された response_mode を使用して、成功またはエラーのいずれかの結果を、指定された redirect_uri (コールバック URL) に直ちに返します。

該当する Rules は、サイレント認証プロセスの一部として実行されます。

​

レスポンスモード

response_mode パラメーターは、Auth0 が認可レスポンスをアプリケーションにどのように返すかを指定します。サイレント認証では、次のモードを使用できます。

モード	配信方法	ユースケース
query	クエリ文字列 (?code=...)	サーバー側で処理する Authorization Code フロー
fragment	URL フラグメント (#access_token=...)	Implicit フロー (レガシー)
web_message	postMessage() API	SPA に推奨 - ページ遷移は不要

web_message を使用する場合、Auth0 は非表示の iframe 内に HTML ページをレンダリングし、HTML5 Web Messaging API を使用して結果をアプリケーションに返します。これにより、画面に表示されるページリダイレクトや state の消失なしで、サイレント認証を実行できます。

response_mode=web_message を使用するには、アプリケーション設定 の Allowed Web Origins フィールドにアプリケーションの URL を追加する必要があります。すべてのレスポンスモードの詳細については、OAuth 2.0 Authorization Framework を参照してください。

​

認証成功時のレスポンス

ユーザーがすでに Auth0 にログインしており、追加のインタラクティブなプロンプトが不要な場合、Auth0 は、ユーザーがログインページから手動で認証した場合とまったく同じレスポンスを返します。レスポンスの形式は、使用する response_mode によって異なります。

web_message

PKCE を使用する Authorization Code Flow (response_type=code) で response_mode=web_message を使用すると、Auth0 は authorization code をアプリケーションに postMessage する HTML ページを返します。

<script>
  window.parent.postMessage({
    type: 'authorization_response',
    response: {
      code: 'SplX...GT',
      state: 'your_state_value'
    }
  }, 'https://yourApp.com');
</script>

アプリケーション (または SDK) はこのメッセージを受信し、code をトークンに交換します。ユーザーに有効なセッションがない場合、Auth0 は代わりにエラーを postMessage します。

<script>
  window.parent.postMessage({
    type: 'authorization_response',
    response: {
      error: 'login_required',
      error_description: 'Login required',
      state: 'your_state_value'
    }
  }, 'https://yourApp.com');
</script>

fragment

response_mode=fragment (response_type=id_token token を使用する Implicit Flow のデフォルト) を使用すると、Auth0 は URL フラグメントにトークンを含めてリダイレクトします。

GET https://yourApp.com/callback
    #id_token=eyJhbG...&
    access_token=eyJhbG...&
    state=your_state_value&
    expires_in=86400

query

response_mode=query (response_type=code を使用する Authorization Code Flow のデフォルト) を使用すると、Auth0 はクエリ文字列に code を含めてリダイレクトします。

GET https://yourApp.com/callback
    ?code=SplX...GT&
    state=your_state_value

これらのレスポンスは、prompt=none パラメーターを使用せずに直接ログインした場合と形式上は同一です。唯一の違いは、prompt=none を使用すると、ユーザーの操作なしでレスポンスが即座に返されることです。

​

エラーレスポンス

ユーザーが シングルサインオン (SSO) でログインしていなかった場合、または SSO セッションの有効期限が切れていた場合、Auth0 は同じ response_mode を使ってエラーを返します。リダイレクトベースのモード (fragment または query) の場合:

GET https://your_callback_url/
    #error=ERROR_CODE&
    error_description=ERROR_DESCRIPTION&
    state=...

web_message モードでは、上記の例のように、エラーは postMessage() を通じて送信されます。

ERROR_CODE に指定可能な値は、OpenID Connect specification で定義されています。

Response	Description
login_required	ユーザーが Auth0 にログインしていないため、サイレント認証はできません。このエラーは、テナント レベルの Log In Session Management 設定の構成によって発生することがあります。特に、Require log in after 設定で指定した期間が経過すると発生する場合があります。詳しくは、Configure Session Lifetime Settings を参照してください。
consent_required	ユーザーは Auth0 にログインしていますが、アプリケーションを認可するには同意が必要です。
interaction_required	ユーザーは Auth0 にログインしており、アプリケーションも認可済みですが、認証を完了する前に別の場所にリダイレクトされる必要があります。たとえば、redirect rule を使用している場合です。

これらのエラーのいずれかが返された場合、認証するには、prompt=none パラメーターを付けずにユーザーを Auth0 のログインページにリダイレクトする必要があります。

​

期限切れのトークンを更新する

ユーザーが Auth0 で有効なセッションを引き続き保持している限り、サイレント認証リクエストを行って新しいトークンを取得できます。auth0.js の checkSession メソッド は、SPA 向けに response_mode=web_message を使用したサイレントトークンリクエストを hidden iframe で実行します。SPA では、Auth0.js が結果 (トークンまたはエラー code) を処理し、アプリケーションが指定したコールバック関数を通じてその情報を渡します。これにより、UX を損なうことなく処理できるため、ページの再読み込みや state の消失は発生しません。

​

アクセストークンの有効期限

アクセストークン はアプリケーションからは中身を確認できません。つまり、アプリケーションはアクセストークンの内容を調べて有効期限を判断できません。

アクセストークンがいつ期限切れになるかを判断する方法は 2 つあります。

• Auth0 から返される expires_in レスポンスパラメーターを確認する。
• 有効期限は考慮しない。代わりに、API がアプリケーションからのリクエストを拒否した場合 (401 など) にアクセストークンを更新する。

Implicit Flow の場合、expires_in パラメーターは、認証が成功すると Auth0 からハッシュパラメーターとして返されます。Authorization Code Flow with PKCE の場合は、認可コード交換の実行時にバックエンドサーバーに返されます。

expires_in パラメーターは、アクセストークンの有効期間 (秒数) を示すため、アクセストークンの有効期限切れを事前に把握するために使用できます。

​

エラーレスポンス

web_message 通信の実行中にタイムアウトが発生したことを示す timeout エラーレスポンスを受け取る場合があります。このエラーは通常、クロスオリジン認証へのフォールバックに関連しています。解決するには、Auth0 Dashboard を使用して、サイレント認証を実行するすべての URL を、アプリケーションの Allowed Web Origins フィールドに追加してください。

​

checkSession() を使用したポーリング

複数のアプリケーションをまたぐ一部のシナリオでは、シングルログアウトが必要になることがあります (あるアプリケーションでユーザーがログアウトした際に、他のアプリケーションでもログアウトさせる必要がある場合) 。このような場合、アプリケーションを設定して checkSession() を使って Auth0 に定期的に問い合わせ、セッションが存在するかどうかを確認できます。セッションが存在しない場合は、そのユーザーをアプリケーションからログアウトできます。同じポーリング方法は、SSO シナリオでサイレント認証を実装する場合にも使用できます。

将来この呼び出しにレート制限が適用された場合の問題を避けるため、checkSession() の呼び出し間隔は少なくとも 15 分空ける必要があります。

​

MFA を使用したサイレント認証

状況によっては、同じブラウザーからログインするたびにユーザーに 多要素認証 (MFA) を求めたくない場合があります。そのためには、セッションごとに MFA が 1 回だけ実行されるようルールを設定します。これは、allowRememberBrowser を true に設定しなくても、ユーザーのセッション中に SPA で有効期間の短いアクセストークンを更新するためのサイレント認証 (prompt=none) を行えるため、有用です。

exports.onExecutePostLogin = async (event, api) => {
  const authMethods = event.authentication?.methods || []

  const completedMfa = !!authMethods.find((method) => method.name === 'mfa')

  if (!completedMfa) {
    api.multifactor.enable('any', { allowRememberBrowser: true })
  }
};

詳細については、認証リクエストの頻度を変更するを参照してください。

​

詳細情報

• リフレッシュトークンローテーション
• リフレッシュトークンローテーションを設定する