Work with Auth0 Locally
In most cases, authenticating users through Auth0 requires an internet connection. However, you can still develop and test apps that use Auth0 locally. In some cases, you might not need access to an internet connection.
To learn how to structure your development, test, and production environments when using Auth0, see Set Up Multiple Environments.
Use JSON Web Tokens (JWT) with client-side applications
Because JSON Web Tokens (JWTs) are stateless (that is, the app that consumes them cares only about its contents, not any of its previous states), this is one of the easiest scenarios to test locally.
You can obtain JWTs for testing using any of the following methods:
Create a test user for a database connection, and programmatically log the user in. Essentially, you are using the Resource Owner Password Flow. For detailed implementation instructions, see Call Your API Using the Resource Owner Password Flow.
Use a browser bot (such as Selenium) to play the role of a user, log in and retrieve a JWT. While this approach may take some effort to develop and maintain, it will allow you to test any redirection rules or MFA prompts that you have configured.
Use sessions with server-side applications
Unless your server-side application allows the generation of artificial sessions for testing, you'll need a way to perform a login through Auth0 manually.
Use local domains with Auth0
If you're developing your application locally, you can use
localhost and other domains inaccessible by Auth0 (such as those on an intranet) as callback URLs. For example, during development you could use
http://localhost:3000/callback as the callback URL.
To set a callback URL, go to Auth0 Dashboard > Applications > Applications and click the application. Add the URL to the Allowed Callback URLs list.
Because Auth0's main identity protocol is OpenID Connect (OIDC), Auth0 never needs to directly call your application's server. Instead, Auth0 redirects users to your application's endpoint(s) with required information contained in a query string or hash fragment.
Divert emails for testing
If you want to test your local application and do not want the emails (creation, validation, etc.) to be delivered to the actual email address of the users your application creates or validates, Auth0 recommends using a custom email provider. For example, a service like Mailtrap or your own custom SMTP server implementation can apply whatever logic you require to trap the emails. This ensures that users do not receive emails but you can access them for validation and troubleshooting.
Auth0 does not allow certain "false" domains commonly used during testing. Use real email addresses to avoid disruption or errors.