> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> 認証データの正当性を検証するために、カスタム URL スキームではなくユニバーサルリンクを使用する方法について説明します。
# アプリケーションのなりすまし対策
ネイティブアプリケーションでは、認証フローとして [PKCE を使用する認可コードフロー](/ja/docs/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 URIs と呼びます。
## モバイルアプリケーション向けの推奨対策
### 検証済み HTTPS URI (Universal Links / App Links)
最新のモバイル OS は **検証済み HTTPS URI** をサポートしており、管理下にある Web サイトのドメインをモバイルアプリに関連付けることができます。検証済み HTTPS URI は、次の名称で知られています。
* iOS では Universal Links
* Android では App Links
検証済み HTTPS URI を使用すると、関連付けられたコールバック 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 にはユーザーに確認プロンプトを表示する仕組みがあります。これにより、ユーザーは認証結果を受け取るアプリケーションが、自分がアクセスしようとしていたものであることを確認できます。検証できない callback URI が使用されている場合、各認証トランザクションでアプリケーションを確認するようユーザーに求めるプロンプトが表示されます。
確認画面は、次の場合に表示されます。
1. リクエスト内の `redirect_uri` が検証できない URI (つまり、カスタム URI スキームまたはループバック URI) を使用している。
2. 現在のログイントランザクションで、ユーザーにまだ他の画面が表示されていない (たとえば、サードパーティアプリケーションに対して[同意画面](/ja/docs/get-started/applications/third-party-applications/user-consent-and-third-party-applications)が表示される場合や、MFA が必要な場合) 。
このような場合、アプリケーションはエンドユーザーに確認プロンプトを表示します。
レガシーな非 OIDC 準拠フローでは、確認プロンプトは表示されません。テナントとアプリケーションに対する保護を強化する方法については、[OIDC 準拠認証の導入](/ja/docs/authenticate/login/oidc-conformant-authentication)を参照してください。
#### プロンプトのカスタマイズ
確認プロンプトでは、サードパーティアプリケーション向けに使用される既存の同意画面に定義されたカスタムのブランディングと設定が使用されます。詳しくは、[Customize Universal Login Page Templates](/ja/docs/customize/login-pages/universal-login/customize-templates) の Prompts セクションを参照してください。
Auth0 は、本番環境でこの保護を無効にしないことを**強く推奨**します。デバイス上の悪意のあるアプリケーションが、ユーザーの操作や、何らかの処理が行われたことを示す他の兆候なしに、`id_tokens` と `access_tokens` を要求できる可能性があります。
確認プロンプトは、テナント全体の設定として、またはアプリケーションレベルで設定できます。アプリケーションレベルの設定は、テナント全体の設定よりも優先されます。
**アプリケーションレベル**
1. [Auth0 Dashboard > Applications > 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. トグルをオンにしてプロンプトを有効にします。
