Hello. I’m totally confused now with getting Lock to work with 2 client apps - each one is configured to be OIDC Conformant via administrative setting (OAuth tab in advanced settings - OIDC Conformant toggle is true for both client apps). I have 2 client apps (each one is Angular 4 SPA): admin app and client app. Each app consumes the same API resource for data. I’m using Lock 10 in each client app to authenticate the user attempting to use the app. The admin app will allow social connections to authenticate. However, the client app is invitation only and is limited to UserName/Password to authenticate the user. The admin app creates an invitation and uses Auth0’s Management API to create the user and then sends invitation via email.
I have this flow working, however, when I go to log the invited user into the client app, I get this error message:
Password login is disabled for clients using externally hosted login pages with oidc_conformant flag set.
I turned off OIDC Conformant toggle in admin area just for client app, however, Auth0 in this configuration does not return a JWT access token. It returns a very small string instead (I think it’s referred to as an opaque token??).
It seems I’m stuck. I cannot login using username/password for my OIDC Conformant client app and if I turn that off, I do not receive a JWT token. I’ve seen other posts suggesting using a hosted login page. I played around with the preview of the hosted login page for each client app and received the exact same error message from above.
I’m totally stuck and confused. Can someone please help provide a direction?
My requirements are as follows:
- Admin app accessible via username/password or social networks
- Client app accessible by only username/password
- Access to client app is by invitation only
- admin & client apps are Angular 4 SPA using Lock version 10
- I prefer to be able to use Lock in each client app as I really like the UI Lock provides and it’s easy to configure.
Thanks for your help.
Have in mind that the preview functionality for the hosted login page is mostly to check the UI aspects of it and you should not try to derive the available functionality from what you get in the preview.
At this time, the use of Lock embedded directly in your client application and with OIDC conformance enabled or API authorization (aka audience parameter) is not yet documented or considered final so you should not be using for a final implementation.
If you want OIDC conformance and/or API Authorization, the current recommendation is for you to use Auth0.js v8, in particular, the authorize method and redirect to the hosted login page where you can still use Lock. Given that each client application uses different connection, the Lock shown on the hosted page will reflect that and show only the applicable connections for the client application that initiated the request.
We’re working on increasing the possibilities available and allow the use of Lock within the client applications themselves even when OIDC or API Authorization come into play, however, at this time, this is still not yet fully available.
Are you saying that any use of the OIDC within Auth0 is not considered final, or just the use of “Lock”?
The use of Lock (embedded in the client application itself) alongside OIDC or API Authorization is still not final. You can already fully leverage both OIDC and API Authorization with Auth0.js (v8) for example; it’s just a limitation for Lock when used in the client application itself.
+1 for allowing oidc via lock. I have essentially the same requirements as the OP, took the same route, and encountered the same limitation.
@jmangelo
When is this expected to be resolved or documented?
We are also using Lock alongside OIDC to receive JWT access_token.
Thank you.
@jmangelo
When is this expected to be resolved or documented?
We are also using Lock alongside OIDC to receive JWT access_token.
Thank you.
I’m afraid I still don’t have a definitive date for its availability.
@jmangelo nowhere in the docs that I reviewed today is the hosted login page referred to as ‘preview’. Is it finally official and therefor this thread should be updated, or is it still in preview and therefore the docs should be updated? (If it does in fact say somewhere that it is in preview, it is not clear/obvious enough!)
@jmangelo nowhere in the docs that I reviewed today is the hosted login page referred to as ‘preview’. Is it finally official and therefor this thread should be updated, or is it still in preview and therefore the docs should be updated? (If it does in fact say somewhere that it is in preview, it is not clear/obvious enough!)
I may not have expressed myself correctly, but I was referring to the preview option available in the dashboard in association to the customization of a hosted login page. The hosted login page is fully-working, but you should not try to perform full authentication scenarios from within that preview option as that may not reflect with 100% fidelity the behavior of the login page when triggered as part of a real authentication flow.