Please confirm: can or cannot use implicit grant via username/pasword with OIDC conformant pipeline

Help
,
1

My app is an SPA using implicit grant flow.

I thought I had the OIDC conformant pipeline working last week, but when I get back to work this morning, it’s suddenly not working (see bottom of post for explanation of this “it was working, now it’s not” phenomenon).

Now, in my Auth0 logs (i.e. the logs on the Auth0 website), it says:

Password login is disabled for clients using externally hosted login pages with oidc_conformant flag set.

What do you mean by “externally hosted”?

I’m trying to use the Auth0 username/password login, hosted by Auth0. So is Auth0 referring to its own login page as “externally hosted” here? Or do I have some other mis-configuration that I don’t understand.

There’s a lot of information floating around on your sites regarding the OIDC stuff and its getting very confusing:

Single sign-on (SSO) can only be performed from Auth0-hosted login pages

You can still perform a resource owner password grant which is somewhat equivalent

The recommended approach for OIDC conformant clients is to use the Auth0 hosted login page

Here’s an example of the login page I want to have work with my application (it is shown by Auth0-lock, v 10.18.0):

![example login page][1]

So is that login page:

  • (1) “auth0 hosted login page” as mention by (A)
  • (2) “customized hosted login page” as referred to in your web GUI (which I do not currently have enabled)
  • (3) “externally hosted login page”
  • (4) “custom login screen”

Note: for the purposes of the rest of this post, when I use “auth0 hosted login page” - I’m referring to that dialog.

(A) and (C) imply to me that I should still be able to use the Auth0 login form (pictured above). But (B) seems to imply that the only thing you can do is use a password grant (i.e. not an implicit grant).

I don’t want to do a password grant flow, and I don’t want to host the login page myself if I can avoid it. I liked that the password never went near our servers; it’s a load off the mind, like simplifying PCI-DSS compliance by having payment details never be transmitted to your own servers.

If the answer is “No - you cannot use any form of hosted login page with with OIDC right now” - is there a plan for that in the future?

Also worth noting fo anyone testing out OIDC:

If you turn off the OIDC flag, then login with the hosted login page, it will work and you will be issued a bearer token as normal. Then turn OIDC back on and refresh your application - you will be able to continue using your previous username/password based login as long as the Authl0 session is valid.

That is, if you try to login to your app after you’ve switched OIDC on but while your Auth0 session is still active, the auth0 dialog will show you a prompt to login like this:

![auth0 continue login][2]

If you choose to continue with that login, Auth0 will issue you a bearer token as normal. If you choose “Not your account” and try to login with username/password, you will then start getting the Auth0 error page and the Auth0 logs will start showing the “cannot user username/password” error.

I don’t think it’s necessarily a security issue, but it’s confusing as hell for people trying to switch over to OIDC. First you think your site is back to working and you think “well, that was painless, well done Auth0”, but then it just stops working later on (after your Auth0 session has timed out). And then you get stuck trying it figure out if this is even meant to work or not.

2

I have recently upgraded my implementation is OIDC conformant, I picked up a few issues when creating a new Client, even before switching on the OIDC option, with regards to grant types, I needed to add these to the Client (via the api online) which managed to get things working, this answer should lead to how that is done:
http://community.auth0.com/answers/5132/view

Maybe this is what needs to be done?
yes, its confusing as hell :slight_smile:

3

Thanks.

But before I try it, I think I’ll wait until I get an official answer from Auth0 on whether this is supposed to work or not. I don’t want to waste any more time on this if I’m trying to do something that’s not even supposed to work in the first place.

4

According to this Auth0 support answer1, users are not currently supposed to be using Lock at all with OIDC - so I guess that’s the answer: “Not supported yet”.

I’d actually go so far as to say people should be very cautious about the OIDC functionality for the moment.