Ask HN: What benefit is there to the enter username then enter password pattern? | Hacker News Reader

Ask HN: What benefit is there to the enter username then enter password pattern?

24 pointsBitwiseFool8 comments

Apologies for not knowing the proper term for this, but I have increasingly noticed that many websites are adopting a new login process that I can only describe as "Enter Username, then redirect to Enter Username + Enter Password". In other words, I have to enter my username, then it redirects me to a new page where I enter my password (sometimes the username field is present too, sometimes it is not). This is different from the past where the username and password field were almost always on the same page.

I think this might have something to do with oAuth, but I see this behavior on websites that don't use any common account infrastructure.

Ultimately, I have two questions for web designers and UI/UX folks. What is the name of this pattern? And, does it bring any benefits or is it just a trendy thing to do?

View on HN

There's generally two big reasons I've seen for this pattern:

1. "Single Sign-On"/Multi-Provider support where the email is used as a lookup key for which Provider to use to log in (redirecting to corporate SAML providers or things like that). (Mentioned by most of the other commenters here.)

2. Another "Wish It Were Multi-Factor" process that (mostly American) Banks cooked up to meet regulatory wording at available loopholes rather than address regulatory intent/spirit (real Two-Factor/Multi-Factor support), in this case specifically for phishing protection. That (dumb) idea was that the user in application settings would pick a recognizable "callback" such as a photo of a cute animal and a word they'd notice. Upon entering the username and before entering the password the application would display this "callback" and in theory the user would remember and know better than to enter their password if they saw the wrong "callback" photo/word. In practice I think we all realize that humans do things like username/password login generally by rote muscle memory, aren't likely to stop and "check the cute animal photo" first, and that whatever APIs returned the "callbacks" would be easily scrapable for phishing anyway if the only real input to them was email address (and maybe a rate limit). At least in my experience most of the sites that did this "cute animal wish it were phishing protection" have since dropped the "cute animal" callbacks (because they were silly), but kept the separate username then password flows. It's easy to assume that that's just laziness on their part after they did all that work to separate the flow that they would not be quick to merge it back together.

Ohhhh I forgot about the cute animal security step! Tbh I thought it was decent. A sort of reverse password where they demonstrate that they're really them before you demonstrate you're really you. Two factor does do this, but I think it's easy to convince people that the system just "didn't require it" this time and skip it as a malicious actor vs. the cute animal. I'm not surprised it failed to accomplish anything, but in theory it seemed decent.

Almost like a dumber version of using public and private keys for auth!

This is a pretty common pattern for applications that support using multiple identity providers via protocols like OAuth or SAML.

The site looks up the supplied email and decides where to send the user - if they have a password, ask them for it; otherwise send them to their identity provider to authenticate and sign them in at the end of that process.

This does leak a little bit of information about users - a third-party could observe whether "bob@megacorp.co" gets redirected to Megacorp's SAML server or gets a password prompt.

It's not a UI pattern as such but the way authentication can be done when the site in question does not know or manage the user's login credentials. It also serves the purpose of "single sign on" in enterprise environments. In other words, the site you're logging into may not have your authentication credentials for that account and would first need to know who you are in order to decide how to challenge you for your credentials or even who should challenge you for your credentials and authenticate you.

Note that I have used the words "authentication" and "credentials" and purposefully omitted "passwords". That's because passwords are just one way of authenticating users. You could also authenticate users by sending a code by email or SMS or using a client certificate, among other ways.

An example: your company subscribes to Office365 but wants to manage your credentials to provide you a single sign on experience across systems. When you visit outlook.office.com to check your email, Microsoft has no idea who you are or that you need to be authenticated by your company. So it asks you to enter your email address, and on getting that, it knows (based on prior configuration) that your company's domain requires you to be sent to a specific page managed by your company for authentication (of course, your company may have outsourced that function to another provider, in which case you get redirected there). In this setup, Microsoft does not know or care how you get authenticated. It just needs a secure and valid authentication token back from the system that's going to authenticate you.

Depending on the systems and providers in question, the most common underlying technologies would either be OAuth or SAML.

Forgot to add that in case the site realizes that it does know how to authenticate the user (after getting the email address or username) and that it doesn’t have to redirect the user to another site (the identity provider or IdP), it will just show the password field to get that.

Here are a couple just based on my limited anecdotal observations. Some sites will redirect a user to the region/cluster their account resides externally rather than internally. There may be a mix of technical and/or regulatory requirements around this pattern. And to your point, some sites will retroactively snap in other authentication methods, redirecting to a different endpoint rather than retrofitting the logic internally on the destination servers. Sometimes this is a result of technical dept or prioritization of projects or spending. Sometimes this is a result of adding a turn-key solution that did not easily integrate with existing applications. I'm sure others here can add more reasons than I have seen.

For SAML, IdP Discovery.

Reply on news.ycombinator.com