Test Social Connections with Auth0 Developer Keys

When using any of the available social identity providers, you need to register your application with the relevant identity provider in order to obtain a Client ID and Client Secret.

Auth0 developer keys are not available in Private Cloud deployments.

For production environments, make sure to follow the steps for your chosen provider to obtain the Client ID and Client Secret from the provider to avoid the limitations of using developer keys. For instructions on converting Google developer keys to production keys, read this Auth0 Developer Lab.

The Auth0 developer keys are to be used for testing purposes so there are a few caveats you need to be aware of when using them. These may cause your application to behave differently--or some functionality to not work at all--depending on whether you use your own Client ID and Client Secret, or whether you use the Auth0 developer keys.

When using the Auth0 developer keys, the authentication flow for the various identity providers may display Auth0's name, logo, and information to your users. When you register your own application, you have the opportunity to use your own logo and other application information instead.

If you are using the Classic Login experience - and in some circumstances, the Universal Login Experience - the follow limitations also apply:

1. You cannot use developer keys with custom domains.

2. Single Sign-On will not function properly when using the Auth0 developer keys. The reason for this is that the Auth0 developer applications with all the relevant Identity Providers are configured to call back to the URL https://login.auth0.com/login/callback instead of the callback URL for your own tenant, for example https://{yourDomain}/login/callback. This results in the SSO cookie not being set on your own tenant domain, so the next time a user authenticates, no SSO cookie will be detected, even if you configured your application to Use Auth0 instead of the Identity Provider to do Single Sign-on (legacy tenants only).

3. Redirecting users from Rules will not function properly. This is because redirect rules are resumed on the endpoint https://{yourDomain}/continue. When using Auth0's developer keys, the session is established on a special endpoint that is generic and tenant agnostic, and calling /continue will not find your previous session, resulting in an error.

4. Federated Logout does not work. When using the Auth0 developer keys, calling /v2/logout?federated will sign the user out of Auth0, but not out of the Social Identity Provider.

5. prompt=none won't work on the /authorize endpoint. Auth0.js' checkSession() method uses prompt=none internally, so that won't work either.

6. If Auth0 is acting as a SAML Identity Provider, and you use a social connection with the Auth0 developer keys, the generated SAML response will have some errors, like a missing InResponseTo attribute or an empty AudienceRestriction element.

7. Multi-Factor Authentication will not function properly. When MFA authentication is successful, a post will generate in https://{yourDomain}/mf. When using Auth0's developer keys, the session is established on a special endpoint that is generic and tenant agnostic, and calling /mf will not find your previous session, resulting in an error