{"meta":{"title":"ユーザー承認コールバック URL について","intro":"ユーザーが GitHub Appを承認した後にリダイレクトできる URL を指定できます。","product":"アプリ","breadcrumbs":[{"href":"/ja/apps","title":"アプリ"},{"href":"/ja/apps/creating-github-apps","title":"GitHub アプリの作成"},{"href":"/ja/apps/creating-github-apps/registering-a-github-app","title":"GitHub App の登録"},{"href":"/ja/apps/creating-github-apps/registering-a-github-app/about-the-user-authorization-callback-url","title":"コールバック URL"}],"documentType":"article"},"body":"# ユーザー承認コールバック URL について\n\nユーザーが GitHub Appを承認した後にリダイレクトできる URL を指定できます。\n\nGitHub Appを登録するときに、コールバック URL を指定できます。 Web アプリケーション フローを使用してユーザーの代わりに動作するためにユーザー アクセス トークンを生成すると、ユーザーは GitHub Appを承認した後、コールバック URL にリダイレクトされます。\n\nコールバック URL は最大 10 個指定できます。 複数のコールバック URL を指定する場合は、GitHub Appの承認をユーザーに求めるときに、`redirect_uri` パラメーターを使用して、ユーザーをリダイレクトするコールバック URL を指定する必要があります。\n`redirect_uri`を指定しない場合は、最初のコールバック URL が使用されます。\n`redirect_uri` パラメーターの使用の詳細については、「[GitHub アプリのユーザー アクセス トークンの生成](/ja/apps/creating-github-apps/authenticating-with-a-github-app/generating-a-user-access-token-for-a-github-app)」を参照してください。\n\nコールバック URL は、セットアップ URL とは異なります。 ユーザーは、 GitHub Appをインストールした後、セットアップ URL にリダイレクトされます。 ユーザーは、Web アプリケーション フローを介して GitHub App を承認すると、コールバック URL にリダイレクトされます。 詳しくは、「[セットアップ URL について](/ja/apps/creating-github-apps/registering-a-github-app/about-the-setup-url)」をご覧ください。\n\nユーザー アクセス トークンの生成の詳細については、「[GitHub アプリのユーザー アクセス トークンの生成](/ja/apps/creating-github-apps/authenticating-with-a-github-app/generating-a-user-access-token-for-a-github-app)」を参照してください。\nGitHub Appの登録の詳細については、[GitHub アプリの登録](/ja/apps/creating-github-apps/registering-a-github-app/registering-a-github-app) を参照してください。\nGitHub App登録の変更の詳細については、[GitHub アプリの登録の変更](/ja/apps/maintaining-github-apps/modifying-a-github-app-registration) を参照してください。\n\n## コールバックURLのワイルドカード照合\n\n必要に応じて、コールバック URL のワイルドカード 照合を有効にすることができます。 ワイルドカード照合が有効になっている場合、リダイレクト URL のホスト (サブドメインを除く) とポートはコールバック URL と完全に一致する必要があり、リダイレクト URL のパスはコールバック URL のサブディレクトリを参照する必要があります。 これは、コールバック URL のサブドメインまたはサブディレクトリが一致し、コールバック URL として許可されることを意味します。 たとえば、コールバック URL `https://example.com/path`に対してワイルドカード照合が有効になっている場合は、次のようになります。\n\n```\nCALLBACK: https://example.com/path\n\nMATCH: https://example.com/path\nMATCH: https://example.com/path/subdir/other\nMATCH: https://oauth.example.com/path\nMATCH: https://oauth.example.com/path/subdir/other\nFAIL:  https://example.com/bar\nFAIL:  https://example.com/\nFAIL:  https://example.com:8080/path\nFAIL:  https://oauth.example.com:8080/path\nFAIL:  https://example.org\n```\n\nワイルドカード照合が無効になっている場合、リダイレクト URL はコールバック URL と完全に一致する必要があります。 アプリの設定で、コールバック URL ごとにワイルドカード照合を有効または無効にすることができます。\n\n> \\[!WARNING]\n> ワイルドカード 照合を有効にすると、攻撃者がコールバック URL のサブドメインまたはサブディレクトリに承認コードを送信できるため、アプリがセキュリティ リスクにさらされる可能性があります。 ワイルドカード マッチングは、絶対に必要であり、コールバック URL のすべての可能なサブドメインとパスを完全に制御することが確実な場合にのみ有効にします。 詳細については、 [OAuth 2.0 のセキュリティのベスト カレント プラクティス](https://www.rfc-editor.org/info/rfc9700/#section-4.1.1-11)を参照してください。\n\n2026 年 3 月 3 日そのコールバック URL に対してワイルドカード照合が有効になっています。 これにより、ワイルドカード照合が構成可能な設定になる前に存在していたリダイレクト動作が保持されるため、すべての OAuth apps と、その日付より前に作成された一部の GitHub Apps でワイルドカード照合が有効になります。 アプリでワイルドカード 照合が必要ない場合は、無効にすることをお勧めします。"}