Help with OIDC Complicance on Hosted Log In page

Help
, ,
1

I have recently purchased an authentication plan from Auth0 as that initial step in developing a web application in which the customers for my organization will eventually be able to place and view their orders. At this point I have created a very primitive web app that uses Node and Express to serve the client a couple of very preliminary webpages as I wanted to tackle user authentication as the first stage of my application’s development.

For my application, I decided to use Auth0’s hosted Log In page as this was supposed to be:

“the most secure way to easily authenticate users for your applications.”

The application is currently structured so that when started it serves a temporary Home page where potential users have access to a Log In button. This Log In button then takes the user to:

https://adfoam.auth0.com/login?client=Oy40QSA74pvo765skJ4F53LAnoHF8hod

which has been identified as the “LogIn URL” when viewing the Preview tab of Auth0’s documentation about their Hosted Pages. The documentation that I am talking about can be found in the following link:

https://manage.auth0.com/#/login_page

At this point in this process, when I attempt to sign in using the email address and password that I use when logging on to my Auth0 account all works well. However, whenever I try to sign up with a new user I receive an “Oops, something went wrong” webpage from this url:

https://adfoam.auth0.com/login/callback

The webpage states that:

There could be a misconfiguration in the system or a service outage. We track these errors automatically, but if the problem persists feel free to contact us. Please try again.

When the “Technical Details” tab of this page is clicked it provides us with the following information:

access_denied: Password login is disabled for clients using externally hosted login pages with oidc_conformant flag set.  TRACKING ID: 2fd21e96f189bf2c6111

Because of this I went visited Auth0’s “Client Settings” page for our application:

https://manage.auth0.com/#/clients/Oy40QSA74pvo765skJ4F53LAnoHF8hod/settings

Once on this page, I opened the “OAuth” tab in “Advanced Settings” and toggled the “OIDC Conformant” button off. I then tried to Sign Up for my application with a previously unused Username and Password, and all was well. I was able to Log In to the part of the application that I was unable to visit previously under any username and password other than the one with which I had created the account.

To ensure that I wasn’t compromising the security or usability of the site I then read up on Auth0’s documentation on OIDC Conformance and it became clear to me that:

Any new Auth0 features, examples and documentation moving forward will target only the OIDC-conformant pipeline. All Auth0 SDK versions that depend on the legacy pipeline are deprecated and will not receive updates for new features or non-critical security issues, and will eventually be discontinued.

Because I would like to future-proof how my users Sign Up for and Log In to my application I want to be able to integrate this OIDC conformance in the simplest and most secure way possible using the “Hosted Log In” page as previously discussed. How do I do this as I can find no clear way of how to resolve this issue when navigating Auth0’s site?

2

The short answer is that the login URL you’re using is incorrect; the one you obtained through the Dashboard is meant only for preview purposes in the cases where you’re customizing the hosted login page and want to check the progress. It’s not meant to be directly used from client applications integrating end-user authentication.

The entry point for a client application wanting to integrate end-user authentication according to an OIDC/OAuth2 redirect-based flow it’s the /authorize path.

If you have a Node.js traditional web application my recommendation would be for you to follow the Node.js quickstart.

If the end goal is to have a SPA application being served by Node.js then the recommendation would be to follow the quickstart available for the SPA framework of your choice. If your SPA framework is not listed I would still recommend looking at the plain JavaScript quickstart.

3

@jmangelo When an app sends a user to the /authorize path, they are immediately redirected to a /login path, which is an “incorrect” path for entry, so if a user bookmarks the signin page and comes back to try and sign in again later, they can get the same error (“access_denied: Password login is disabled for clients using externally hosted login pages with oidc_conformant flag set.”)

Bookmarking the sign-in page for an app doesn’t seem like such a crazy thing to do… do you know if there is a way to avoid this?

4

@jmangelo When an app sends a user to the /authorize path, they are immediately redirected to a /login path, which is an “incorrect” path for entry, so if a user bookmarks the signin page and comes back to try and sign in again later, they can get the same error (“access_denied: Password login is disabled for clients using externally hosted login pages with oidc_conformant flag set.”)

Bookmarking the sign-in page for an app doesn’t seem like such a crazy thing to do… do you know if there is a way to avoid this?

5

What you mention (bookmarking the login page) used to be a perfectly sensible thing to do before all the OIDC/OAuth related authentication coming into picture. Now the end page where the end-user submits credentials is usually associated to an OAuth transaction that is non-repeatable so bookmarking those pages is not advisable. Having said that, we should be providing a better experience for when end-users insist on doing that; I can let you know that improvements to that flow have been discussed and we want to make them, but at this time there is not yet definitive information on dates.

6

Hello @jmangelo, I am running into the same issue even though I try to access the page from the /authorize route? And we are using hosted page. Here is the : https://predqa.auth0.com/login?client=joxU56p2xipgLnK411f2jYY5d7RtWVEv&protocol=oauth2&redirect_uri=http%3A%2F%2Flocalhost%3A4200%2Fcallback&response_type=token%20id_token&scope=openid%20email%20profile%20app_metadata%20user_metadata%20groups%20permissions%20roles&audience=urn%3Aauth0-authz-api&nonce=O0kntpdYrDq8S82GZeT10PSdFXN6XQBR&auth0Client=eyJuYW1lIjoiYXV0aDAuanMiLCJ2ZXJzaW9uIjoiOC4xMC4xIn0%3D&state=VYNV3K3Axb23aAEC4Er4RLW26t-4EP7M

7

@jmangelo @jmangelo1 any pointers?