メインコンテンツへスキップ
ネイティブアプリケーションでは、認証フローとして PKCE を使用する認可コードフロー を使用し、ログイン後にアプリケーションへ制御を戻すために redirect_uri を用います。URI がデバイスのブラウザーで読み込まれると、通常はアプリケーションが自動的に開き、ユーザーはそのまま操作を続行できます。 従来、モバイルアプリケーションでは カスタム URI スキーム (例: com.mycompany.myapp://oauth2redirect) が使われていました。しかし、カスタム URI スキームには、デバイス上の複数のアプリケーションが同じスキームを登録できるというリスクがあります。モバイル OS には、リダイレクトを受け取るアプリケーションが意図したものであることを保証する組み込みの仕組みがありません。このような状況では、悪意のあるアプリが正規のアプリになりすまして認可レスポンス (トークンを含む) を受け取り、ユーザーはそれに気付かない可能性があります。特に、以前の正規セッションが存在してシングルサインオン (SSO) が有効になっている場合は、追加のユーザー操作が不要なため、このリスクは高まります。このようなシナリオでは、PKCE も実質的にはあまり役に立ちません。悪意のあるアプリケーションがログインフローを開始し、ユーザー操作なしでコールバックを受け取るのを待ててしまうためです。 ローカルマシン上で実行されるアプリケーション (例: デスクトップアプリ、CLI) も、コールバックにループバックインターフェイス (例: http://127.0.0.1:51089/callback または http://localhost:61024/callback) を使用する場合、同様のリスクがあります。この場合、同じマシン上の別のアプリケーションが同じポートで待ち受け、レスポンスを傍受できる可能性があります。 このドキュメントでは、カスタム URI スキームとループバック URI の両方を、いずれのシナリオでも認可サーバーが受信側アプリケーションを検証できないことから、Non-Verifiable Callback URIs と呼びます。 最新のモバイル OS は 検証済み HTTPS URI をサポートしており、管理下にある Web サイトのドメインをモバイルアプリに関連付けることができます。検証済み HTTPS URI は、次の名称で知られています。
  • iOS では Universal Links
  • Android では App Links
検証済み HTTPS URI を使用すると、関連付けられたコールバック URL を処理できるのは自分のアプリケーションのみとなり、機密性の高い認証データへの不正アクセスを防止できます。
Auth0 は、すべてのネイティブアプリケーションでリダイレクト URI として検証済み HTTPS URI を使用することを強く推奨しています。
次の場合、Auth0 は認証トランザクションの結果を受け取るアプリケーションの正当性を検証できません。
  • 古いモバイル OS バージョンとの互換性が必要なため、アプリケーションが検証済み HTTPS URI をサポートできない
  • アプリケーションがデスクトップアプリケーションまたは CLI アプリケーションである
OAuth2 for Native Apps 仕様で定義されているとおり、Auth0 にはユーザーに確認プロンプトを表示する仕組みがあります。これにより、ユーザーは認証結果を受け取るアプリケーションが、自分がアクセスしようとしていたものであることを確認できます。検証できない callback URI が使用されている場合、各認証トランザクションでアプリケーションを確認するようユーザーに求めるプロンプトが表示されます。 確認画面は、次の場合に表示されます。
  1. リクエスト内の redirect_uri が検証できない URI (つまり、カスタム URI スキームまたはループバック URI) を使用している。
  2. 現在のログイントランザクションで、ユーザーにまだ他の画面が表示されていない (たとえば、サードパーティアプリケーションに対して同意画面が表示される場合や、MFA が必要な場合) 。
このような場合、アプリケーションはエンドユーザーに確認プロンプトを表示します。
アプリのなりすまし対策 - 確認プロンプト
レガシーな非 OIDC 準拠フローでは、確認プロンプトは表示されません。テナントとアプリケーションに対する保護を強化する方法については、OIDC 準拠認証の導入を参照してください。

​
プロンプトのカスタマイズ

確認プロンプトでは、サードパーティアプリケーション向けに使用される既存の同意画面に定義されたカスタムのブランディングと設定が使用されます。詳しくは、Customize Universal Login Page Templates の Prompts セクションを参照してください。
Auth0 は、本番環境でこの保護を無効にしないことを強く推奨します。デバイス上の悪意のあるアプリケーションが、ユーザーの操作や、何らかの処理が行われたことを示す他の兆候なしに、id_tokens と access_tokens を要求できる可能性があります。
確認プロンプトは、テナント全体の設定として、またはアプリケーションレベルで設定できます。アプリケーションレベルの設定は、テナント全体の設定よりも優先されます。 アプリケーションレベル
  1. Auth0 Dashboard > Applications > Application Settings > Advanced > OAuth に移動します。
  2. Non-Verifiable Callback URI End-User Confirmation 設定までスクロールします。
  3. プロンプトを有効にするにはトグルをオンにし、無効にするにはトグルをオフにします。
Auth0 Dashboard>Settings>Advanced
グローバル
  1. Auth0 Dashboard > Settings > Advanced に移動します。
  2. Non-Verifiable Callback URI End-User Confirmation 設定を探します。
  3. トグルをオンにしてプロンプトを有効にします。
Auth0 Dashboard>Tenant Settings>Advanced>Skip Custom URI toggle