Universal Login missing features are undermining your whole Buy vs Build value-proposition and hurting our User Experience
Auth0 only makes sense if we you save us from building a custom solution. But Universal Login defaults to SIGN IN and cannot be changed to present a SIGN-UP form, which means we have to spend valuable time and engineering resources to build a custom solution.
The problem is that on our landing pages we encourage users to “Get Started” and “Apply Now” which can only link to a Sign Up form. So users unwittingly enter an email and password, only to hit an error message. Once they realize the system is trying to log them in, hopefully they’ll notice they need to click Sign Up and re-enter their credentials. That’s a terrible first impression. And the solution seems like such an easy fix. Just give us a way to start at the Sign Up tab!
Is there ANYTHING at all we could possibly do to help you fix this issue? We could supply funding and engineering effort to the problem if you need any help. Our UI and customer experience is hugely important to us, but Auth0 is making it very hard for us to improve our user experience. It’s extremely frustrating we can’t workaround this limitation. Is it really such a hard problem to fix?
The thing is we already implement the Universal login when we started our project months ago. We’ve started onboarding actual customers just recently, and the problems became apparent as user have complained. So now we need to spend extra hours reimplementing the solution with Lock, which costs additional engineering hours and has some downsizes too. It’s less secure and doesn’t look as nice, among others. Couldn’t your team probably implement a method to switch to the Sign In tab in about 40 minutes? Are there some major rabbit holes with your technology stack that make this especially intractable to solve? It just seems pointless that we might spend thousands of dollars to workaround this issue, when you’re engineers could push a fix that would solve this limitation for countless thousands of clients and their users.
Struggling with this as well. A signup button that leads to signup (and not login) is a key requirement for us to use the universal login. Would be really awesome if this could be implemented as it wouldn’t be that difficult?
Thanks for joining the discussion. I’m a Product Manager myself, and I’m sure when you guys set out to make Universal Login your intentions were to build a better experience all-around–in terms of design, security, and features. But by leaving out just this one critical feature–the ability to display a Sign Up form–you’ve also managed to make it very difficult for some of us to get onboard with Auth0 at all.
Could you help us understand:
Why the team decided many months ago to leave out the ability to display a Sign Up form from Universal? DIdn’t the Product Manager consider the ability to display a Sign Up form a major use-case for an accounts system? Was it simply a lack of engineering resources and shifting priorities? Or;
Is there something especially intractable about implementing this feature which makes it a prohibitively expense challenge for Auth0 to tackle?
Have you considered that this limitation might be hurting your own value-prop and preventing leads from adopting your solution (not to mention consuming company resources–like right now–that would be better invested elsewhere?
Can you give us any kind of estimate for when this might be implemented? 2 weeks? 2 months? 2 years? If not, is it possible you might never fix this at all? Understanding your product roadmap can help us make better decisions that affect our own objectives and goals.
First, let me acknowledge that I understand that being able to redirect to the signup page it’s an important requirement for several applications, and I’d love to stop everything and get it done. It’s also true that it also happens with a lot of other features.
When we started the implementation of our new Universal Login experience, we could have decided to not to ship it until we had a complete solution that had feature parity with the previous one. We decided to deliver value incrementally, and provide a solution that’s valuable for some customers, but not for others. We also clearly documented the limitations.
We still recommend users that find the new login experience limiting to use a custom login page with Lock or auth0.js, and being able to land in the signup page is one of those scenarios. I understand it’s very frustrating to find out later in the game that you need the feature and you don’t have it.
When prioritizing features for the new Universal Login flow, we try to understand how many users will benefit from it, and if it’s unblocking scenarios that are not currently possible with Auth0. For example, we’ve been investing in improving our MFA flows, because you can use a customized page using Lock or auth0.js for implementing login with high flexibility, but that wasn’t the case for MFA. We just shipped a way to customize the text anywhere in the Universal Login flow because it’s useful for every user of it.
In this specific scenario, when we shipped the new UL experience there wasn’t an standard way to communicate to the authorization server the intention of signing-up the user. That’s changing, as there’s a public draft do add that feature to OIDC https://openid.net/specs/openid-connect-prompt-create-1_0.html. The semantics are still not clear (e.g. if you redirect to prompt=create, should we give customers the option to also sign-in with an existing account? what if there’s already a session for that user? should we prompt anyway like we do with prompt=login).
We are going to implement the feature, but we currently don’t have it in our Q1/Q2 roadmap for 2020. Priorities can change, and adding product feedback is a good way to influence them.
I understand how this is frustrating for you, and I know that’s not the answer you were expecting it.
I certainly understand the idea to ship early and deliver additional value incrementally–we do this all the time. And yes, we actually knew that this feature was missing when we decided to implement Universal. We were in development for 12 months, so we expected the feature would be there by the time we launched. A bad assumption on our part.
Thanks for the tip off about the roadmap. That certainly helps us decide how to move forward.
Regarding the semantics of the OIDC “prompt” keyword
In requests to the OpenID Provider, a client MAY indicate that the desired user experience is for the user to immediately see the user account creation UI instead of the login behavior.
A value of create indicates to the OpenID Provider that the client desires that the user be shown the account creation UX rather than the login flow. Care must be taken if combining this value with other prompt values. Mututally exclusive conditions can arise so it is RECOMMENDED that create not be present with any other values.
MAY indicates it’s optional, and the spec indicates the client desires that the user be shown an account creation prompt (but we aren’t told we MUST show an account creation prompt). They seem to recognize there’s a bit of complexity here which should be carefully considered, which may be why they are intentionally vague.
So I think rather than make restrictive demands, they choose to defer those decisions to implementers, so that you can handle these cases in a way that makes sense to your contexts.
If there is already a session, you could:
prompt for credentials, and if the users proceeds to submit, you should expire the existing session and create a new one (that’s what mailchimp does at https://login.mailchimp.com/);
you could prompt to sign in as another user (Google gmail and gsuite allow multiple user accounts to have sessions simultaneously)
I think option 1 would be perfectly acceptable. It seems to work fine for Mailchimp. It would allow a user to switch accounts, whereas option 2 wouldn’t (they’d need an explicit “sign out” first.) I think option 3 is a exceptional choice as it’s quite rare for apps to allow multiple users sessions.
Given prompt=create semantics are not completely clear according to our RFC/protocos experts,
ae are considering another alternative, which is using a screen_hint parameter (e.g. screen_hint=singup) so it can be combined with ‘prompt=login’ which already provides semantics for forcing creating a new session or not.
We also desperately need this feature. Can’t use Lock because of the cross-domain issues and the limitation of one domain per tenant.
It would help if someone could tell us
how to know whether we are using the classic or new universal login
how to switch to classic if we’re using universal
how to directly bring up the signup screen in classic.
Various things seem to indicate that it CAN be done with Universal Classic, but so far nothing I’ve found clearly explains HOW.
Our current state is that we have implemented what I think is some form of Universal login by following the getting started tutorial for a React SPA.
The spec is designed to help; not to hurt. i’m absolutely sure the spec developers don’t intend for you to create an absolute train wreck of an onboarding experience for countless users. The spec recognizes there’s a bit of complexity here which should be carefully considered, which may be why they are intentionally vague. No one is stopping you from implementing a solution except your own lack of will.
We’re attempting to migrate thousands of customers to a rewrite of our application, but since we can’t send them to a SIGN UP form, many users try to login to the new system with their old credentials. We trusted Auth0 but it was a mistake. Our migration has been nightmare for our users, engineers, and customer support team because you refuse to make this fundamental and necessary feature a priority.