Hacker News Reader

Comment by emilsedgh | Hacker News Reader

> Separating the password from the email field with an extra mouse click sucks if you are using a password manager.

If I understand correctly, the reason behind this pattern is SSO.

Most websites are gaining SSO capabilities. Before asking for your email/user, they don't really now if you're gonna login using password, or you should be redirected to an IdentityProvider.

I'd be happy to know if there are better patterns here but I think password managers should get a bit smarter and work with this trend.

View on HN

Honestly asking, what's wrong with "Password (Leave empty if you're using {Name of SSO}): ____"?

If you are going to tell that may confuse users, I think not having a password field is already confusing the other half, while also not being password-manager-friendly.

I don't think making the user read instructions is the solution. Most (myself included) will begin typing before they finish reading.

The current trend to only show the password box after the username is provided doesn't have to be bad for password managers. I use loads of sites that do this (so they can support SSO) and they just use hidden form fields so the password managers know what to do.

I'd be curious to hear any suggestions you have for password managers to improve here though. I can't think of anything short of a .well-defined login route.

The Oreilly learning platform does this. Email and password field on the same page and a message under the email field

> Using Single Sign-on (SSO)? Simply enter your company email address and click sign in.

Seems simple enough to me as a user, not sure how most people interact with it though or how many companies A/B test these things.

My company uses an SSO provider with Google Workspace. Most employees have no idea about any of that, they wouldn't know and probably would type their company password there.

The password field disappears if you enter an SSO-compatible email address.

Then you have to either leak a list of each customer to the client to verify there or send each key stroke and consider latency ...

That requires you to teach your users what SSO is. I don't think it's a great UX.

Seems like password managers should be able to handle the password being entered on the next page when there's no input on the current page.

KeepassXC (and its browser extension KeepassXC-Browser) does this. Not sure why anyone would even consider a different password manager.

(Just don't forget to donate, if you have the means.)

Because different people have different requirements.

Firefox also handles every one of these perfectly. I assume there is a hidden password field already but whatever it is it doesn't cause me issues other than an extra click.

They could just check if the username needs to be redirected, and if they do then ignore the password. It wouldn't be that hard.

The only downside is the user submitting a password they dont need to, but if you're using js you could post the username first and only post the password if needed. That would be the same exact process, except from the users perspective it would be seamless. You could even have it check the username as they type, and lock the password field if its not needed.

I could see a lot of large companies that integrate with other B2B sites recoil in horror with a UI that encourages employees to enter their corporate email address and a password. Many employees would use their corporate passwords.

this is exactly the sort of thought process that leads to terrible login flows. yes, it's technically possible, and it works for you.

but the login flow is one area of your product that needs to work for everybody. There's plenty of features that can be tailored to a power-user workflow because they're the only people that will see it, but the sign-in flow is not one of those. any confusing UI in your sign-in flow is going to confuse your least-confident users. and asking people using Facebook Sign-in to enter a password when they haven't ever set a password for your site is extremely confusing. all just to save a couple keystrokes for the most-technically-competent users.

Well for facebook, and any other big ones they could just click "sign in with facebook" thats common enough.

The problem is when you have a bunch of enterprise customers and you're not sure which custom login to use, and you dont want to list all your clients.

Ideally, this is solved by the client company telling its employees to use an internal link that authenticates and redirects. Though I'm sure not all clients are capable of this, and still want to use SSO. In that case, I think my solution is much nicer than requiring a two step login.

Most websites I've used where this is a thing, definitely don't do this. All the projects where I dealt with PMs / designers insisting on this they would not even had a clue about what SSO was or how it impacts their UX. There are plenty of websites out there with sane login flows.

Passwords work off well publicized naming conventions. That's why they work on the vast majority of websites. The problem is junior developers not knowing that is a thing getting creative with naming things. No-one on such projects even thinks about testing this or pointing out to their PMs that this does not work. 9 out of 10 times you'd get the response to "please fix that". Because why would you not.

Reply on news.ycombinator.com