In certain cases (described below), Auth0 may need to redirect back to the application’s Login Initiation endpoint, using OIDC third-party initiated login. To learn more, read Initiating Login from a Third Party at the OpenID Foundation. You can configure these URIs with the Dashboard in Application Settings or Tenant Advanced Settings or with the . 
curl --request PATCH \
  --url 'https://{yourDomain}/api/v2/clients/{yourClientId}' \
  --header 'authorization: Bearer API2_ACCESS_TOKEN' \
  --header 'cache-control: no-cache' \
  --header 'content-type: application/json' \
  --data '{"initiate_login_uri": "<login_url>"}'
The login_url should point to a route in the application that ends up redirecting to Auth0’s /authorize endpoint, e.g. https://mycompany.org/login. Note that it requires https and it cannot point to localhost. login_url can include query parameters and a URI fragment. As per the OIDC Third Party Initiated Login specification, the iss parameter containing Issuer Identifier will be added as a query string parameter to login_url before redirecting.

​
Redirect default login route scenarios

​
Users bookmark login page

When an application initiates the login process, it navigates to https://{yourDomain}/authorize with a set of required parameters. Auth0 then redirects end-users to an https://{yourDomain}/login page, with a URL that looks like: https://{yourDomain}/login?state=g6Fo2SBjNTRyanlVa3ZqeHN4d1htTnh&... The state parameter points to a record in an internal database where we track the status of the authorization transaction. Whenever the transaction completes, or after a set time passes, the record is deleted from the internal database. If you are using Organizations and the end-user bookmarks the organization login prompt, Auth0 also includes the organization parameter when it redirects the user to the default login route. Sometimes users bookmark the login page, and when they navigate to the bookmarked /login URL, the transaction record is no longer there and Auth0 cannot continue with the login flow. In that case, Auth0 will redirect to the default client URL if configured, or the tenant level URL if not. If no default login URL is set, Auth0 will render an error page.

​
Complete password reset flow

After completing the password reset flow and the default URI for the application or tenant is configured, users will see a button that will let them navigate back to the login page. This behavior only happens when you enable the experience. With Classic Login, you need to configure the redirect URL in the Change Password template. To learn more, read Customize Email Templates. For tenants using Universal Login, the /post-password-change endpoint supports redirecting users back to a specific application. When client_id is specified and the application’s login URI is set, users will see a button sending them back to the application after completing a password reset. 
curl --request POST \
  --url 'https://{yourDomain}/api/v2/tickets/password-change' \
  --header 'authorization: Bearer MGMT_API_ACCESS_TOKEN' \
  --header 'content-type: application/json' \
  --data '{ "user_id": "A_USER_ID", "client_id": "A_CLIENT_ID" }'

​
Complete email verification flow

As part of the signup process, users who choose email as their identifier receive an email to verify their email address. If they click on the link, they will land on a page that says that the email was verified, with a button to go back to the application. When clicked, users will be redirected to the login page, and if they already have a valid session, they’ll end up being redirected to the application. This behavior only happens when the Universal Login experience is enabled. With Classic Login, you need to configure the redirect URL in the Verification Email template.

​
Invite organization members

When users are invited to join an Organization, they receive an invitation link by email. If they select the link, they are redirected to the configured default login route with invitation-specific parameters appended. For example, if you have an organization-enabled application with an Application Login URI set to https://myapp.com/login, then the link sent in the email invitation that an end-user receives will be: https://myapp.com/login?invitation={invitation_ticket_id}&organization={organization_id}&organization_name={organization_name}. Thus, the route in your application must accept invitation and organization parameters through the query string. To start the invitation acceptance transaction, it should forward both parameters along with the end-user to your Auth0 /authorize endpoint.

​
Disabled cookies

If a user navigates to https://{yourDomain}/authorize with cookies disabled in their browser, Auth0 redirects the user to the application login URI. If the application login URI is not set, the redirect is sent to the tenant login URI instead. Sending the user back to the login page can potentially cause a redirect loop. To avoid this issue, use a landing page to check the availability of cookies; if disabled, warn the user to enable them if they wish to continue.

​
Learn more