prompt=noneパラメーターをサポートしているので、アプリケーションは、認証サーバーにユーザーとのやりとり（認証や承諾、など）を一切表示しないよう指示できます。Auth0は要求された応答をアプリケーションに返すか、ユーザーがまだ認証されていない場合や、処理を進める前に何らかの同意やプロンプトが必要な場合はエラーを返します。
SPAで暗黙フローを使用すると、明示的な緩和策を必要とするセキュリティ上の課題につながります。PKCEを使った認可コードフローをサイレント認証と組み合わせて使用することで、SPAのセッションを更新できます。
近年、ブラウザーのユーザープライバシー制御機能が発達し、サードパーティクッキーがブロックされることでユーザーエクスペリエンスに悪影響を与えています。そのため、ブラウザーベースのフローは、リフレッシュトークンのローテーションを使用しなければなりません。これにより、SPAで安全にリフレッシュトークンが使用できる一方で、ブラウザーにあるITPなどのプライバシー保護技術にUXを阻害されることなく、エンドユーザーがリソースにシームレスにアクセスできます。
サイレント認証要求を開始する
サイレント認証要求を開始するには、Auth0の認証APIのエンドポイント/authorizeにユーザーをリダイレクトする際に、prompt=noneパラメーターを追加します。（認証要求の個々のパラメーターは、アプリの特定のニーズに応じて異なります）。
例：
prompt=noneパラメーターにより、Auth0は指定されたredirect_uri（コールバックURL）に、指定されたresponse_modeを使用して、成功またはエラーの2つのうちいずれかの応答を即座に送信します。
適用可能なルールはすべて、サイレント認証処理の一部として実行されます。
認証成功の応答
ユーザーがすでにAuth0にログインしており、他の対話型プロンプトが不要な場合、Auth0は、ユーザーがログインページから手動で認証を受けた場合とまったく同じように応答します。 たとえば、暗黙フロー（シングルページアプリケーションで使用されるresponse_type=id_token token）を使用すると、Auth0は次のように、要求されたトークンを返します。
cURL
prompt=noneパラメーターを使用せずに直接ログインした場合と区別がつきません。
エラーの応答
ユーザーがシングルサインオン（）経由でログインしていなかった場合、またはSSOセッションが期限切れとなっていた場合、Auth0は次のように、指定されたredirect_uri（コールバックURL）にエラーとともにリダイレクトします。
ERROR_CODEが取り得る値は、OpenID Connect仕様によって次のように定義されています。
| 応答 | 説明 |
|---|---|
login_required | ユーザーがAuth0でログインしていないため、サイレント認証は不可能です。このエラーは、テナントレベルの Log In Session Management（ログインセッション管理） 設定の構成方法に基づいて起こります。特に、 Require log in after（後にログインが必要） 設定で指定された期間後に起こります。詳細については、セッションライフタイム設定の構成をご覧ください。 |
consent_required | ユーザーはAuth0でログインしましたが、アプリケーションの認可に同意が必要です。 |
interaction_required | ユーザーはAuth0でログインし、アプリケーションを認可しましたが、認証が完了する前にどこか他にリダイレクトされる必要があります。たとえば、リダイレクトルールを使用している場合などです。 |
prompt=noneパラメーターなしでAuth0のログインページにリダイレクトされて、認証を受ける必要があります。
期限切れトークンを更新する
ユーザーがAuth0で有効なセッションを保持している限り、新しいトークンを取得するためにサイレント認証要求を行うことができます。auth0.jsのメソッドcheckSessionは、SPA用にresponse_mode=web_messageと組み合わせてサイレントトークン要求を使用して、要求が非表示のiframe内で実行されるようにします。SPAでは、Auth0.jsが結果処理（トークンまたはエラーコード）を処理し、アプリケーションが提供するコールバック関数を通じて情報を渡します。これにより、UXが中断されること（ページの再読み込みや状態の喪失）はありません。
Safariブラウザーに関する他の重要な制限事項や回避方法については、「Safariを使ってトークンを更新する」を参照してください。
アクセストークンの有効期限
アクセストークンはアプリケーションに対して不透明です。つまり、アプリケーションはアクセストークンの有効期限を判断するためにその内容を検査できません。 アクセストークンの有効期限を判断するには、2通りの方法があります。- Auth0から返される
expires_in応答パラメーターを読み取りる。 - 有効期限は完全に無視する。その代わりに、アプリケーションからの要求をAPIが拒否した場合（401など）にアクセストークンを更新する。
expires_inパラメーターがハッシュパラメーターとして返されます。PKCEを使った認可コードフローでは、認可コードの交換を行う際にバックエンドサーバーにこのパラメーターが返されます。
expires_inパラメーターは、アクセストークンが何秒間有効であるかを示し、アクセストークンの有効期限切れを予測するために使用できます。
エラーの応答
web_message通信の実行中にタイムアウトが発生したことを示すtimeoutエラー応答を受信することがあります。このエラーは通常、クロスオリジン認証へのフォールバックと関連しています。解決するには、を使用して、サイレント認証を実行したいすべてのURLを、アプリケーションの ［Allowed Web Origins（許可されているWebオリジン）］ フィールドに追加してください。
checkSession()でポーリングする
シングルログアウトが必要な一部のマルチアプリケーションのシナリオ（あるアプリケーションからログアウトするユーザーが他のアプリケーションからもログアウトする必要があるような場合）では、checkSession()を使用して定期的にAuth0をポーリングし、セッションが存在するかどうかを確認するようにアプリケーションを設定できます。セッションがない場合は、ユーザーをアプリケーションからログアウトさせることができます。同じポーリング方式を使用して、シングルサインオン（SSO）のシナリオにサイレント認証を実装することができます。
ポーリング間隔として、checkSession()の呼び出し間隔を15分以上に設定し、レート制限の問題が生じないようにします。
多要素認証によるサイレント認証
状況によっては、同じブラウザーを使ってログインしているユーザーに対し、多要素認証（MFA）を求めるプロンプトを毎回表示したくない場合があります。これを実行するには、セッションごとにMFAが1回だけ発生するようにアクションを設定します。これは、allowRememberBrowserをtrueに設定することなく、ユーザーのセッションの期間中に、SPA内で有効期限の短いアクセストークンを更新するためのサイレント認証（prompt=none）を行う場合に便利です。