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

, ,

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.

You can do this with a little workaround using the Classic Universal Login.

Turn on “Customize Login Page”, then replace lock.show() with this snippet.

    const urlParams = new URLSearchParams(window.location.search);
    let initialScreen = urlParams.get('initialScreen'); // get the query param 'initialScreen'; you can change this any time
    initialScreen = initialScreen === 'signUp' ? 'signUp' : 'login'; // if not explicitly 'signUp', default to login
    document.title = (initialScreen === 'signUp' ? 'Sign Up' : 'Log In') + ' | Brand Name'; // dynamically set page title
    lock.show({ initialScreen }); // open the lock with the initial screen

This way you don’t need to completely switch away from Universal Login. Just need to use “Classic” Universal Login, and not the “New” Universal Login.

(Disclaimer: may work with the new one too, have not tried as my app is using classic! YMMV.)

Then, when you want to sign up/log in just include a query param &initialScreen= at the end:

  • To sign up, set it to signUp
  • To log in, set it to login or don’t send it.
1 Like

Thanks for sharing this workaround @simpleauthority!

@maxhodges0 we are actually implementing this. We expect it would be live in 2 weeks or so.

1 Like

Thanks a lot for the headsup @andres.aguiar!

Please clarify if I understand correctly - are you implementing “this” the feature discussed (default to SignUp view) or something else, related to RFC?

We are building a new product and this issue is very hurting. We cannot use the new XP without this feature.

Thanks,
Oleksandr.

Hi @sasha.sochka,

We are building a feature that will let you specify screen_hint=signup in the /authorize parameters and will default to the Signup page when using the New Universal Login Experience

Regards,

Andres

1 Like

Thanks.
Does that include support in the auth0-spa lib, to hide that implementation detail (e.g. a new method similar to loginWithPopup, maybe signupWithPopup? or a parameter/option in existing methods).
Oleksandr

Yes, you’ll be able to specify that parameter in Auth0ClientOptions https://auth0.github.io/auth0-spa-js/interfaces/auth0clientoptions.html

Regards,

Andres

1 Like

Thanks for letting us know @andres.aguiar!