> ## Documentation Index > Fetch the complete documentation index at: https://docs-dev-fix-docs-5528-php-updates.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Auth0開発者キーでソーシャル接続をテストする > ソーシャルIPプロバイダーにAuth0開発者キーを使用する際の注意点を見ていきます。 重要なコンセプト * Auth0の開発者キーにある制限を確認する 利用可能な[ソーシャルIDプロバイダー](/docs/ja-jp/authenticate/identity-providers/social-identity-providers)のいずれかを使用するときは、アプリケーションを関連IDプロバイダーで登録して、クライアントIDとクライアントシークレットを入手する必要があります。 Auth0では、Auth0開発者キーを使用して、独自のクライアントIDとクライアントシークレットを指定せずにソーシャルIDプロバイダーをテストすることができます。これにより、ソーシャルIDプロバイダーをすばやく有効にしてテストすることができますが、運用で使用することはできません。 Auth0開発者キーは、[プライベートクラウドデプロイメント](/docs/ja-jp/deploy-monitor)では利用できません。 運用環境では、開発者キーの使用に関する[制限](#limitations-of-developer-keys)を回避するために、必ず[選択したプロバイダーの手順に従って](/docs/ja-jp/authenticate/identity-providers)、プロバイダーからクライアントIDとクライアントシークレットを取得してください。Google開発者キーを運用キーに変換する手順については、[こちらの「Auth0 Developer Lab」を参照してください。](https://developer.auth0.com/resources/labs/authentication/google-social-connection-to-login#set-up-google-production-keys) いくつかの接続では、開発やテストのみを使用の対象としたAuth0開発用鍵が使われています。同意ページにAuth0ではなく貴社のロゴを表示して、接続にシングルサインオン（SSO）を構成するために、接続は独自の開発者キーを使って構成されるべきです。Auth0開発用鍵を運用環境で使用することは推奨しません。 クライアントID/クライアントシークレットの呼称は、IDプロバイダーによって異なる可能性があります。たとえば、Xでは、コンシューマーキー/コンシューマーシークレット、LinkedInではAPIキー/シークレットキーと呼ばれています。 ## 開発者キーの制限事項 Auth0開発キーは、テスト目的での使用を想定しているため、利用に際して注意すべき事項がいくつかあります。クライアントID・クライアントシークレットを使うか、Auth0開発者キーを使うかによって、アプリケーションの動作が異なったり、一部の機能が動作しなかったりする可能性があります。 Auth0開発者キーを使った場合は、各IDプロバイダーの認証フローで、Auth0の名前やロゴ、情報が表示されることがあります。独自のアプリケーションを登録していれば、自社のロゴやアプリケーション情報を表示することが可能です。 Consent screen ## ユニバーサルログイン使用時における開発者キーの制限事項 [クラシックログインエクスペリエンス](/docs/ja-jp/authenticate/login/auth0-universal-login/universal-login-vs-classic-login/classic-experience)を使用している場合、また状況によっては[ユニバーサルログインエクスペリエンス](https://auth0.com/docs/authenticate/login/auth0-universal-login/new-experience)を使用している場合は、次の制限も適用されます。 1. [カスタムドメイン](/docs/ja-jp/customize/custom-domains)では開発者キーを使用できません。 2. [シングルサインオン](/docs/ja-jp/authenticate/single-sign-on)は、Auth0開発者キーを使用していると正常に機能しません。その理由は、関連するすべてのIDプロバイダーを備えたAuth0開発者アプリケーションが、独自のテナント（`https://{yourDomain}/login/callback`）への **コールバックURL** ではなく、URL `https://login.auth0.com/login/callback`へのコールバックを行うように構成されているためです。 その結果、SSOクッキーがテナントドメイン上で設定されず、アプリケーションで **シングルサインオンを実行するためにIDプロバイダーではなくAuth0を使用** するように構成した場合でも、ユーザーの次回認証時にSSOクッキーが検出されなくなります（レガシーテナントのみ）。 3. [ルールからのユーザーのリダイレクト](/docs/ja-jp/customize/rules/redirect-users)は正常に機能しません。これは、リダイレクトルールがエンドポイント`https://{yourDomain}/continue`で再開されるためです。Auth0の開発者キーを使うと、セッションは、汎用でテナントに依存しない特別なエンドポイントで確立され、`/continue`を呼び出しても以前のセッションが見つからないため、エラーが発生します。 4. [フェデレーションログアウト](/docs/ja-jp/authenticate/login/logout)は機能しません。Auth0開発者キーを使用するときに、`/v2/logout?federated`を呼び出すとユーザーはAuth0からサインアウトしますが、ソーシャルIDプロバイダーからはサインアウトしません。 5. `prompt=none`は[/authorize](/docs/ja-jp/api/authentication/reference#social)エンドポイントでは動作しません。[Auth0.js](/docs/ja-jp/libraries/auth0js)のcheckSession()メソッドは`prompt=none`を内部で使用するため、これも動作しません。 6. Auth0がSAML IDプロバイダーの役目を果たし、Auth0開発者キーでソーシャル接続を使用した場合、生成されるSAML応答には、`InResponseTo`属性が欠落していたり​​、`AudienceRestriction`要素が空であったりするなどのエラーが含まれます。 7. [多要素認証](/docs/ja-jp/secure/multi-factor-authentication)は適切に機能しません。MFA認証が成功した場合、投稿は`https://{yourDomain}/mf`に生成されます。Auth0の開発者キーを使うと、セッションは、汎用でテナントに依存しない特別なエンドポイントで確立されるので、`/mf`を呼び出すと以前のセッションが見つからないため、エラーが発生します。