Reducing occurrences of "Password login via OIDC-conformant clients" error

My company has been using Auth0 to handle OAuth2-based authenication and authorization for more and more of our production users (now many 10s of thousands per day). This is with a mixture of web (SPA), and mobile (native) applications.

We use a single, externally-hosted login page and the latest auth0-js & android/ios SDKs in the clients.

For months and months I’ve seen these errors occurring in production, and the number is growing: “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).” When this occurs to one of our users, we show them a custom error page that informs them (among other things) that bookmarking the login page does not work.

I’ve carefully reviewed existing community postings regarding this issue, including this most prominent one: "Password login via OIDC-conformant clients..."

I think I’ve finally figured out why so many of these occur every day, and I’d like some advice on how to best reduce them. I noticed that a large % of these (via the user agent string in the error log) are iOS or Mac OS X devices, using Safari. I believe these are coming from users who see the URL to one of our applications in their Safari browser’s list of windows open on other devices. Because we take our users automatically to our HLP after their session times out, this link (again, from another device in which they are logged in) includes all the ‘state’ for that instance of the HLP, on that (other) device. Thus, when a user loads that URL, it isn’t valid for the device on which they are currently browsing (thus producing this error if/when they login)

I believe one simple/easy way to eliminate this error is to toggle off the setting “OIDC Conformant” for a given app, in settings → advances → OAuth. My gut tells me this is a poor solution, because (I presume) that setting is primarily to help Auth0 customers who are migratig from old ‘non-conformant’ pipelines into the new era of being OIDC conformant, and not for this purpose. My specific question is: how bad is this solution in terms of introducing security risks?

My last question: any other ideas? One idea we’ve had is to stop taking our users to the HLP if/when their session times out, but rather popping up a ‘modal dialog’ like Google does in their (web-based) clients - that way, the URL for that window is still the ‘product url’ which does not include stateful CGI parameters.

3 Likes

were you able to find a better solution?

The only ‘good solution’ we found has been doing these 3 things (they are all independent of one another, but together they ‘add up’ to a better experience):

  1. Utilizing SSO & allowing users to stay logged in for > 1 days (of course you’ll have to gauge this setting based on your business/security needs)
  2. No longer taking the user automatically to the HLP if/when their SSO session is no longer valid, but rather prompting them with a (div-based) dialog that offers a link to the HLP. That way, the user only goes to the HLP when they ‘really intend to login’.
  3. Updating our custom error page to look for this error when it occurs, and offering the user a valid link to the HLP for the app they were attempting to log into (we look for the string ‘OIDC-conformant’ in the resulting error page’s query params).

Note that regarding #3, Auth0 fixed a bug (~ 2 months ago?) so that the query param “client_id” is now accurate. This was necessary for us to fulfill the ‘feature’ of providing a proper link-to-HLP in our custom error page.

I am also facing the same problem with Xamarin.Android.
Could you please point me to the right direction like how can i declare default redirect uri in codes ,in case any such errors…
Also want to point out this is happening sometimes with users with email and password

Hey there!

Sorry for such huge delay in response! We’re doing our best in providing you with best developer support experience out there, but sometimes our bandwidth is not enough comparing to the number of incoming questions.

Wanted to reach out to know if you still require further assistance?