Universal Login could support a better onboarding experience with a Sign Up mode

, ,

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?

3 Likes

Hey there!

All depends on if you want to use classical or the new Universal Login experience. The solution suggested above will only work if you use hosted page:

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? :wink:

1 Like

Another concern is that we might spend thousands of dollars to migrate away from Universal as you recommend, and then 2 days later your team might finally add this feature to Universal!

Can we at least get a time frame to help us make our decision to wait or migrate away from Universal?

@zatziky in the post you linked to asked:

If it’s not possible with auth0 when do you plan to add this feature?

But six months later his question remains unanswered.

1 Like

Let me connect you guys with Universal Login - @andres.aguiar - product manager to address that!

1 Like

Hi @oskar.ahlroth,

Could you please submit your request here:

Maybe if enough of us make this request they will bump the priority. I’m going to ask as many people as I can to join our “petition”.

2 Likes

That’s also a good way fo advocating for your needs! Make sure to relay the feedback there as well but Andres should reach out to you once he’s online.

Thanks @maxhodges0 for the suggestion, submitted a request.

2 Likes

Thank you a lot and sorry for the inconvenience!

Hi @andres.aguiar @andres.aguiar1

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:

  1. 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;
  2. Is there something especially intractable about implementing this feature which makes it a prohibitively expense challenge for Auth0 to tackle?
  3. 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?
  4. 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.

Cheers!

Hi all,

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 Initiating User Registration via OpenID Connect 1.0. 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.

Best regards,

Andres

1 Like

Thanks Andres for providing all that info!

1 Like

Thanks Andres!

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.

prompt
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:

  1. 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/);
  2. simply redirect back to the app (this is what github does (Sign in to GitHub · GitHub); or,
  3. 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.

Hey there @maxhodges0!

I’m sure Andres will address your concerns once he’s online. Thanks for patience!

Hi @maxhodges0

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.

Regards,

Andres

1 Like

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.
2 Likes

Could someone point us to the place where we should vote for this feature?

1 Like

Thank you very much for considering a workaround to speed up things. Please let us know if you finally add it to your roadmap or any other update.

1 Like

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.