概要
重要なコンセプト
- Auth0の開発者キーにある制限を確認する
Auth0では、Auth0開発者キーを使用して、独自のクライアントIDとクライアントシークレットを指定せずにソーシャルIDプロバイダーをテストすることができます。これにより、ソーシャルIDプロバイダーをすばやく有効にしてテストすることができますが、運用で使用することはできません。
カスタム開発者キー
いくつかの接続では、開発やテストのみを使用の対象としたAuth0開発用鍵が使われています。同意ページにAuth0ではなく貴社のロゴを表示して、接続にシングルサインオン(SSO)を構成するために、接続は独自の開発者キーを使って構成されるべきです。Auth0開発用鍵を運用環境で使用することは推奨しません。
クライアントIDとクライアントシークレット
クライアントID/クライアントシークレットの呼称は、IDプロバイダーによって異なる可能性があります。たとえば、Xでは、コンシューマーキー/コンシューマーシークレット、LinkedInではAPIキー/シークレットキーと呼ばれています。
開発者キーの制限事項
Auth0開発キーは、テスト目的での使用を想定しているため、利用に際して注意すべき事項がいくつかあります。クライアントID・クライアントシークレットを使うか、Auth0開発者キーを使うかによって、アプリケーションの動作が異なったり、一部の機能が動作しなかったりする可能性があります。 Auth0開発者キーを使った場合は、各IDプロバイダーの認証フローで、Auth0の名前やロゴ、情報が表示されることがあります。独自のアプリケーションを登録していれば、自社のロゴやアプリケーション情報を表示することが可能です。
ユニバーサルログイン使用時における開発者キーの制限事項
クラシックログインエクスペリエンスを使用している場合、また状況によってはユニバーサルログインエクスペリエンスを使用している場合は、次の制限も適用されます。- カスタムドメインでは開発者キーを使用できません。
- シングルサインオンは、Auth0開発者キーを使用していると正常に機能しません。その理由は、関連するすべてのIDプロバイダーを備えたAuth0開発者アプリケーションが、独自のテナント(
https://{yourDomain}/login/callback
)への コールバックURL ではなく、URLhttps://login.auth0.com/login/callback
へのコールバックを行うように構成されているためです。 その結果、SSOクッキーがテナントドメイン上で設定されず、アプリケーションで シングルサインオンを実行するためにIDプロバイダーではなくAuth0を使用 するように構成した場合でも、ユーザーの次回認証時にSSOクッキーが検出されなくなります(レガシーテナントのみ)。 - ルールからのユーザーのリダイレクトは正常に機能しません。これは、リダイレクトルールがエンドポイント
https://{yourDomain}/continue
で再開されるためです。Auth0の開発者キーを使うと、セッションは、汎用でテナントに依存しない特別なエンドポイントで確立され、/continue
を呼び出しても以前のセッションが見つからないため、エラーが発生します。 - フェデレーションログアウトは機能しません。Auth0開発者キーを使用するときに、
/v2/logout?federated
を呼び出すとユーザーはAuth0からサインアウトしますが、ソーシャルIDプロバイダーからはサインアウトしません。 prompt=none
は/authorizeエンドポイントでは動作しません。Auth0.jsのcheckSession()メソッドはprompt=none
を内部で使用するため、これも動作しません。- Auth0がSAML IDプロバイダーの役目を果たし、Auth0開発者キーでソーシャル接続を使用した場合、生成されるSAML応答には、
InResponseTo
属性が欠落していたり、AudienceRestriction
要素が空であったりするなどのエラーが含まれます。 - 多要素認証は適切に機能しません。MFA認証が成功した場合、投稿は
https://{yourDomain}/mf
に生成されます。Auth0の開発者キーを使うと、セッションは、汎用でテナントに依存しない特別なエンドポイントで確立されるので、/mf
を呼び出すと以前のセッションが見つからないため、エラーが発生します。