> ## Documentation Index
> Fetch the complete documentation index at: https://docs-staging-feat-sdk-reference-docs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> 認証データの正当性を検証するために、カスタム URL スキームではなくUniversal Linksを使用する方法について説明します。
# アプリケーションのなりすまし対策
ネイティブアプリケーションは、[PKCE を使用した Authorization Code フロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)を認証フローとして使用し、ログイン後に制御をアプリケーションへ戻すために `redirect_uri` を使用します。URI がデバイスのブラウザーで読み込まれると、通常はアプリケーションが自動的に開き、ユーザーはそのまま操作を続けられます。
従来、モバイルアプリケーションでは [カスタム URI スキーム](https://developers.google.com/identity/protocols/oauth2/native-app#installed_app_redirect_methods) (例: `com.mycompany.myapp://oauth2redirect`) が使われてきました。しかし、カスタム URI スキームには、デバイス上の複数のアプリケーションが同じスキームを登録できてしまうというリスクがあります。モバイル OS には、リダイレクトを受け取るアプリケーションが意図したものであることを保証する組み込みの仕組みがありません。このような場合、悪意のあるアプリが正規のアプリケーションになりすまして認可レスポンス (トークンを含む) を受け取ってしまうおそれがあり、しかもユーザーはそれに気づけません。特に、以前の正規のセッションがあることでシングルサインオン (SSO) が有効になっている場合は、追加のユーザー操作が不要なため、このリスクはさらに高まります。こうしたケースでは、PKCE は実質的にあまり役に立ちません。悪意のあるアプリケーションでも、ユーザー操作なしでログインフローを開始し、コールバックを受け取るのを待ててしまうからです。
ローカルマシン上で動作するアプリケーション (例: デスクトップアプリ、CLI) も、コールバックにループバックインターフェース (例: [http://127.0.0.1:51089/callback](http://127.0.0.1:51089/callback) または [http://localhost:61024/callback](http://localhost:61024/callback)) を使用する場合、同様のリスクがあります。この場合、同じマシン上の別のアプリケーションが同じポートで待ち受けて、レスポンスを傍受できる可能性があります。
カスタム URI スキームとループバック URI は、いずれのケースでも認可サーバーが受信側のアプリケーションを検証できないため、総称して Non-Verifiable Callback URI と呼びます。
モバイルアプリケーション向けの推奨対策
検証済み HTTPS URI (Universal Links / App Links)
最新のモバイル OS は **検証済み HTTPS URI** をサポートしており、これを使うと、自分で管理しているウェブサイトのドメインをモバイルアプリに関連付けることができます。検証済み HTTPS URI は、次の名称で知られています。
* iOS では Universal Links
* Android では App Links
検証済み HTTPS URI を使用すると、関連付けられた callback URL を処理できるのは対象のアプリケーションのみとなり、機密性の高い認証データへの不正アクセスを防ぐことができます。
Auth0 は、すべてのネイティブアプリケーションで、リダイレクト URI として検証済み HTTPS URI を使用することを **強く推奨** しています。
* iOS: [Support Universal Links](https://developer.apple.com/documentation/xcode/allowing-apps-and-websites-to-link-to-your-content/#Support-universal-links) を確認してください。
* Android: [Android App Links](https://developer.android.com/training/app-links) を確認してください。
すべてのアプリケーションに推奨される緩和策
次の場合、Auth0 は認証トランザクションの結果を受け取るアプリケーションが正当なものかどうかを検証できません。
* 古いモバイル OS バージョンとの互換性を維持する必要があり、アプリケーションが検証済み HTTPS URI をサポートできない
* アプリケーションがデスクトップアプリケーションまたは CLI アプリケーションである
[OAuth2 for Native Apps](https://datatracker.ietf.org/doc/html/rfc8252#section-8.6) 仕様で定義されているとおり、Auth0 にはユーザーに確認プロンプトを表示する仕組みがあります。ユーザーは、認証結果を受け取るアプリケーションが、自分がアクセスしようとしていたものであることを確認します。検証できないコールバック URI が使用されている場合、ユーザーは認証トランザクションごとにアプリケーションの確認を求められます。
確認画面は、次の場合に表示されます。
1. リクエストに含まれる `redirect_uri` が、検証できない URI (つまり、カスタム URI スキームまたはループバック URI) を使用している。
2. 現在のログイントランザクションで、ユーザーにまだ他の画面が表示されていない (たとえば、サードパーティアプリケーションで[同意画面](/docs/ja-jp/get-started/applications/third-party-applications/user-consent-and-third-party-applications)が表示される場合や、MFA が必要な場合) 。
このような場合、エンドユーザーには確認プロンプトが表示されます。
確認プロンプトは、従来の OIDC 非準拠フローでは表示されません。テナントとアプリケーションの保護を強化する方法については、[OIDC 準拠の認証を採用する](/docs/ja-jp/authenticate/login/oidc-conformant-authentication)を参照してください。
プロンプトのカスタマイズ
確認プロンプトでは、サードパーティアプリケーション向けの既存の同意画面に対して定義した、カスタムのブランディングと設定が使用されます。詳しくは、[Customize Universal Login Page Templates](/docs/ja-jp/customize/login-pages/universal-login/customize-templates) の Prompts セクションを参照してください。
本番環境では、この保護を無効にしないことを Auth0 は**強く推奨**しています。デバイス上の悪意あるアプリケーションが、ユーザーの操作や何かが起きたことを示す表示が一切ないまま、`id_tokens` や `access_tokens` を要求できてしまう可能性があります。
確認プロンプトは、テナント全体の設定として、またはアプリケーションレベルで設定できます。アプリケーションレベルの設定は、テナント全体の設定より優先されます。
**アプリケーションレベル**
1. [Auth0 Dashboard > アプリケーション > Application Settings > Advanced > OAuth に移動します](https://manage.auth0.com/#/applications/settings)。
2. **Non-Verifiable Callback URI End-User Confirmation** 設定までスクロールします。
3. プロンプトを有効にするにはトグルをオンにし、無効にするにはトグルをオフにします。
**グローバル**
1. [Auth0 Dashboard > Settings > Advanced に移動します](https://manage.auth0.com/#/tenant/advanced)。
2. **Non-Verifiable Callback URI End-User Confirmation** 設定を探します。
3. プロンプトを有効にするにはトグルをオンにします。
