Mobile app failure - Password login via OIDC-conformant clients with externally-hosted login pages is unsupported

Problem Statement

I am logging in using Universal Login. At the login, sometimes I get the following error:

error code: access_denied

error description: Invalid state

Password login via OIDC-conformant clients with externally-hosted login pages is unsupported. Alternatively, login could have been initiated from the wrong place (e.g., a bookmark).

What could be the reason for this issue?


The user is redirected to the default login URI if it is configured application level or tenant level.


The following articles explain how to capture network traffics:

For iPhones:

Capturing and Inspecting iOS Traffic - Fiddler Everywhere.

For Android:

For Native Windows App:

For Regular web apps and SPAs:

And here are a few questions to understand the issue better:

  1. Do you experience this issue every time on your end, or is it happening randomly?
  2. Does clearing the cookies on your mobile browser help to resolve the issue?
  3. Does the issue only happen with Safari? Do you observe a different outcome if you change your default browser to Chrome on your phone? apple: How to change default browser on Apple iPhone


There isn’t a single reason for this issue. The state mismatch error on mobile apps usually happens due to cookie failures. As we don’t log cookies in our logs due to security concerns, we aren’t able to find out cookie-related issues, unfortunately.

Here are the most common scenarios where the state mismatch issue can happen:.

  1. The browser discards the Auth0 Session cookie. Here are a few potential reasons for this.
    a. The user’s first-party cookies are disabled.
    b. The total cookie size and number exceeds the supported size number of the browser. Here is a related link for this issue: What is the maximum size of a web browser's cookie's key? - Stack Overflow. If you are using the custom, a user visiting some pages on may set some cookies on the browser which are accessible on the login subdomain ( Then the mobile app opening the login domain on the same browser may cause the Auth0 cookies (named auth0, auth0_compat) not to get set, which could cause this issue.
    c. Apple’s Safari ITP blocks first-party cookies when it detects/thinks that the cookies are for tracking purposes. Check the “What is Intelligent Tracking Prevention” section in this doc.

  2. The user bookmarks the login page and opens the login page directly. (This usually happens for web apps)

  3. Multiple login pages are opened simultaneously on the same browser. (This usually happens for web apps)

  4. The user clicks the back button on the login page. (This usually happens for web apps)

There are a few things we recommend:

  1. If you use a custom domain, the cookies from the base domain shouldn’t ideally be available for the sub-domain used with your custom login domain. This is possible to implement with the host-only cookie type see: jakarta ee - What is a host only cookie? - Stack Overflow
  2. Check if you are within the cookie limits: What is the maximum size of a web browser's cookie's key? - Stack Overflow.
  3. For native iOS apps, using the ephemeral sessions may also be helpful as the Auth0 cookies are removed every time after the login is completed, which can help to have the browser in a good state for these cookies. Auth0.swift/ at master · auth0/Auth0.swift · GitHub