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.
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 for testing using any of the following methods:
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.For a high-level overview of how to do this, see Authorization Code Flow. For detailed implementation instructions, see our tutorial, Add Login Using the Authorization Code Flow.
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.
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.
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. To learn more, read Configure Test SMTP Email Server.Auth0 does not allow certain “false” domains commonly used during testing. Use real email addresses to avoid disruption or errors.