サイレント認証を設定する

サイレント認証を使用して、ユーザーをアプリケーションにログインしたままにする方法を学びます。

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

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

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

​

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

サイレント認証リクエストを開始するには、ユーザーを Auth0 の Authentication 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 を使って結果をアプリケーションに返します。これにより、ページのリダイレクトをユーザーに見せることなく、状態を失わずにサイレント認証を行えます。

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

​

認証成功時のレスポンス

ユーザーがすでに Auth0 にログインしていて、ほかに対話的なプロンプトが必要ない場合、Auth0 は、ユーザーがログインページから手動で認証した場合とまったく同じ形で応答します。レスポンスの形式は、使用する response_mode によって異なります。

web_message

Authorization Code Flow with PKCE (response_type=code) で response_mode=web_message を使用する場合、Auth0 は認可コードをアプリケーションに post する HTML ページを返します。

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

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

<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 はクエリ文字列にコードを含めてリダイレクトします。

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 にログインしていないため、サイレント認証はできません。このエラーは、テナント レベルの ログイン セッション管理 設定の構成によって発生することがあります。特に、次の時間経過後にログインを要求 設定で指定された期間を過ぎると発生する可能性があります。詳しくは、セッション有効期間設定を構成する を参照してください。
consent_required	ユーザーは Auth0 にログインしていますが、アプリケーションを認可するには同意が必要です。
interaction_required	ユーザーは Auth0 にログインしており、アプリケーションも認可していますが、認証を完了する前に別の場所にリダイレクトされる必要があります。たとえば、redirect rule を使用している場合です。

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

​

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

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

​

Access Token の有効期限

アクセストークン はアプリケーションからは中身を参照できません。つまり、アプリケーションは Access Token の内容を確認して有効期限を判断することはできません。

Access Token の有効期限を確認する方法は 2 つあります。

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

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

expires_in パラメータは、Access Token が有効な秒数を示すもので、Access Token の期限切れを事前に把握するために使用できます。

​

エラーレスポンス

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

​

checkSession() でポーリングする

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

今後この呼び出しでレート制限の問題が発生するのを避けるため、checkSession() の確認間隔は、呼び出しごとに少なくとも15分空けるようにしてください。

​

Multi-factor Authentication によるサイレント認証

状況によっては、同じブラウザーからログインするたびに、ユーザーに Multi-factor Authentication (MFA) を求めるのを避けたい場合があります。その場合は、MFA がセッションごとに一度だけ行われるようにルールを設定します。これは、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 })
  }
};

詳しくは、認証リクエストの頻度を変更するをご覧ください。

​

さらに詳しく

• Refresh Tokenのローテーション
• Refresh Tokenのローテーションを設定する