I’m using an externally-hosted login page with the Auth0 SDK webAuth.signup to register users, and a user got this error message. I’m unable to reproduce on my end. Any ideas?
“Password login via OIDC-conformant clients with externally-hosted login pages is unsupported.”
Are other users experiencing this or is it just the one? Usually this problem occurs when users bookmark the /login URL that /authorize redirects to and attempt to log in directly. You mentioned signup, was this with a new user or an existing user?
Hi Kim,
Thanks for your response. This was only experienced by one user so far since migrating to an externally-hosted flow, in which we have a custom registration page. This was a new user who was unable to login after signing up. I haven’t been able to reproduce the issue myself.
Here is a brief description of our new user signup flow. Please let me know if I"m doing something wrong. Upon submitting our custom registration form, we do the following (using Auth0.js v9):
webAuth.signup( connection, email, password )
if Step 1 succeeds, we immediately automatically call webAuth.login(email, password, realm) so that when the new users click on the confirmation link in their email, when they are redirected to our app they will be already signed in. This is an important UX experience we’d like to maintain.
This has worked fine for several other new signups, as well as all tests I’ve performed. I’m 99.9% sure this user did not bookmark the page as they had the issue immediately upon signing up. (they were unable to login after registering). Thanks for any assistance you may provide!
Joe
In the meantime, I’ve switched the OIDC-Confirmant switch off for my clients, since it sounds like maybe I shouldn’t be using the webAuth.login call if I have the switch on? (which makes me wonder why it worked at all for most users)
We are also seeing this issue for 1 user in particular. We also use the hosted login page, as well as the Auth0 Cordova npm module (from native). So the user is not bookmarking anything associated with the login page. Any other advice @kimcodes?
We are also having this issue using Auth0.js v9 (9.4.2 in particular) on the hosted login page. Up to 10% of logins fail with with the error “Password login via OIDC-conformant clients with externally-hosted login pages is unsupported. Alternatively, login could have been initiated from the wrong place (e.g., a bookmark).”.
This has been happening since the very day we moved over to Auth0 and so it’s impossible for users to have bookmarked the log in page. I am unable to reproduce the error, but multiple people in the team have had it occur during a normal flow (being redirected to /authorize which then redirects to /login). The user is logged in even though the error occurs, silent authenticating the user after the error succeeds.
It seems that sometimes the hosted login page is believed to be an external login page causing the error, since turning off OIDC Conformance fixes the issue. We are also using a custom domain if that makes any difference.
Is it possible that, when initializing Auth0.js in the hosted login page, you are leaving out the config.internalOptions values? It’s important to put these values in the options object as shown in the default template, so that the server can maintain the proper state during the authentication transaction:
var config = JSON.parse(
decodeURIComponent(escape(window.atob('@@config@@')))
);
var params = Object.assign({
domain: config.auth0Domain,
clientID: config.clientID,
redirectUri: config.callbackURL,
responseType: 'code'
}, config.internalOptions);
We are initialising Auth0.js like so:
var config = JSON.parse(
decodeURIComponent(escape(window.atob('@@config@@')))
);
const params = Object.assign({
domain: config.auth0Domain,
clientID: config.clientID,
redirectUri: config.callbackURL,
responseType: 'code',
overrides: {
__tenant: config.auth0Tenant,
__token_issuer: config.auth0Domain
}
}, config.internalOptions);
const webAuth = new auth0.WebAuth(params);
Which matches what you put, and what’s on the documentation for using a custom domain with universal login.
We are seeing similar issues as mentioned above in our hosted page using Auth0.js. We were seeing it without custom domain too.
If you are still having this issue, please attach a .HAR file that includes the relevant sequence of steps that causes the issue. Make sure you remove any sensitive information such as passwords.
I’ve followed all of the necessary steps to become OIDC compliant; however, I the other users in this thread, I am getting the same error page. It only happens with username/password signup (username-password authentication) flow. When we deactivate OIDC-conformant the issue goes away. Any progress on a fix or work around?
Also looking for a fix here… Followed all previous steps.
Same here, we have a lot of users that bookmark the login page after all it’s the first page they see of our app.
would be great if we can have a default callback page.
Some apps break with this flag on. We noticed it as a problem as more people signed up., Can i turn the flag off without any issues? I want to turn it off but fear it will impact existing users. Any ideas. Thanks! Need to know asap since we have a campaign running!
found out that it’s possible to redirect to a default page in this situation by setting initiate_login_uri it can’t be done using the UI only through the API:
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.
