Auth0 Home Blog Docs

Suddenly getting error "Password login is disabled for clients using externally hosted login pages with oidc_conformant flag set" when using Hosted Login Page, possibly after changing "Default Directory" setting

password
oidc
hosted-login-page
default-directory

#1

Hello all

After months of trouble free use, one of our Auth0 tenants is suddenly returning "Password login is disabled for clients using externally hosted login pages with oidc_conformant flag set"
This is occurring while using postman to get an Access Token, using “Authorization Code” grant.
We do not use an external login page - we use the absolute default hosted page from Auth0 (we are not even customizing it).

The strangest part is that logging in actually works about once an hour or so, and then for the next hour we get these errors again. This seems to be time based. It doesn’t matter how many attempts we try.

This is affecting every client on this tenant - so essentially this Auth0 tenant can no longer be used for any authorization. We’re in trouble… :frowning:

Note that there was one change on this tenant today, and it was around-ish the time that things became unstable. We added a new client to do “Resource Owner Password Grant”, and as per https://auth0.com/docs/api-auth/tutorials/password-grant#configure-your-tenant we set the tenant’s “Default Directory” to the default Auth0 authorization database.

We have since deleted the new client, as well as removed the “Default Directory” setting on the tenant. I wouldn’t expect this to be related, but it is otherwise quite a coincidence.

In summary

  • Authorization Code grant type has worked for us for months without issue (using the OIDC Compliant flag)
  • Note that clearing the OIDC flag does allow the login to work; but then the access_token is in the wrong format, so removing the OIDC flag is not an option for us
  • We use the hosted Auth0 login page, without customization
  • We set the tenant’s “Default Directory” setting today, but have since deleted it
  • Authorization now only succeeds on this tenant a very small percentage of the time - typically we get the “Password Login Disabled” error, as per above
  • We have two other tenants configured identically, and they still continue to work 100%. It is only this tenant experiencing the problem. This is the only tenant we added and then removed the “Default Directory” setting on.

We are pretty desperate to get this tenant working again - would appreciate any ideas from anyone! Thank you :slight_smile:


#2

posting as an answer as it was too long for a comment

Given this is highly specific to a single tenant your best bet is to capture a full HTTP trace of the failed transaction (from the request to /authorize until the error). Also be sure to capture with a tool that captures the full response bodies as Chrome HAR exports, for example, tend to skip on those which makes it really problematic for troubleshooting some issues. For example, a tool like Fiddler with HTTPS capture enabled is a good option and you can still try to redact some sensitive data.

In addition, you can also share it in a password protected file and make the password available through sharelock.io and only to @auth0.com email addresses.


#3