I have existing clients that are using lock’s that are not associated to OIDC. Now having to conform to OIDC when using a lock on my own hosted server I receive the error:
“access_denied: Password login is disabled for clients using externally hosted login pages with oidc_conformant flag set.”.
However, Having to move to using Auth0 hosted login page (which I don’t mind) there is no clear instruction on using this workflow therefore my only assumption is to activate custom login for Hosted page, click on Preview to then be provided the URL to redirect users? When redirecting users to this URL they are presented with a lock hosted by Auth0 however then redirect to auth0 hosted callback showing a misconfiguration and additional details again show:
access_denied: Password login is disabled for clients using externally hosted login pages with oidc_conformant flag set.
So what am I missing? I am using PHP and happy to either redirect users to Auth0 hosted or to host my own lock.
The recommendation is to use the hosted login page (HLP) as that will get you the most features with the least work. However, the way you navigate the end-users to the HLP needs to meet a certain criteria. In particular, the preview functionality in the Dashboard is not meant to give you an URL that you point your end-users to. The preview is only meant for you to have a quick way to review any visual customization you performed to your hosted login page.
In conclusion, you’ll need to redirect the end-users to the /authorize endpoint with the applicable parameters. The current PHP quickstart makes use of Auth0.js to perform the navigation to that endpoint on the client-side, but if you prefer you can also do it with a server-side redirect as long as you also set the necessary parameters-
If i’m not mistaken, if an user create a browser bookmark on the hosted login page, he will get this error after login. Any way to fix this or at least to have an more user friendly message in that case ?
Thank you for your reply jmangelo. That makes sense. I was unaware the quick start was related to the hosted login. This has now been resolved.
Thanks again.
If i’m not mistaken, if an user create a browser bookmark on the hosted login page, he will get this error after login. Any way to fix this or at least to have an more user friendly message in that case ?
Yes, bookmarking can also create a similar situation. I know that there were discussions about improving the outcome in order to better cater for these scenarios and based on the information I have those changes are planned, but I have no definitive data in terms of dates.
Has anyone seen this error in the Auth0 logs when a user is trying to log in from the Auth0 Cordova app and the browser has cookies disabled?