Ask HN: Why do many sites now put username+password entry on different pages?
I just find it irritating when typing it in, AND it messes with password managers. But it seems to be happening more and more. What's the logic behind it? Is there some security benefit I don't understand? Or is it just me who hates this?
32 comments
[ 6.1 ms ] story [ 90.4 ms ] threadFor example, I don't know what login method a user would be using (our own password? or redirect them to their corporate's auth portal) until they enter their email.
Basically a single page request (that then immediately fetches all the associated JaveScript and CSS) to run the entire app.
It is popular now because its a very small step from that to having a PWA (progressive Web application) which is progressive in the sense that it can be completely cached on the users device, and work with no connection to the Internet.
It also improves page-load performance in connected situations by there being no pages to load (after the first one).
While a solid approach, SPAs can suffer from long initial load times, as well as a tendancy to suffer from complexity that comes with any monolithic large app.
But it also happens plenty of places where single sign in isn't an option. Like the biggest two supermarkets Tesco.com and Sainsburys.co.uk here in the UK.
Log in with Corp acme. Log in with palantir. Log in with Facebook (Corp). Log in with Facebook (end user)... Etc.
You'd have to iterate through every customer with SAML / OIDC set up.
Even if you are just using end user, it's sometimes confusing if there are 10+ options because you have to remember... Ok not only do I gotta remember my email I used, how did I originally sign up? .. was it with Google? With Facebook... No wait did I use email and password...
"A big reason why this is done is to prevent passwords from accidentally landing in the username field, which is logged, & is correlated in all sort of reports"
Maybe they really want people to use their app.
All of the other comments seem to have much more logical explanations, like SSO and OAuth options.
To accomodate that you design your page so the user first enters username. In your system you check based on email who the identity provider is and redirect to that login journey.
For e.g. if Microsoft you redirect to Microsoft login page to authenticate.
If successful the third party login provider will send you back to your app with a JWT. In your app you check if the JWT is valid - if so allow access.
On first entering email on login, If your login provider is your own app, you redirect to your own login password page.
I had to look it up.
https://en.m.wikipedia.org/wiki/JSON_Web_Token
This means the user now has to remember which email he used on your app, which is not very different from remembering which third party provider you used before.
Maybe I'm missing something, but how would you explain why Google does this two step login process?
And then, if you're already logged in according to the auth provider, you don't have to type your password either.
A good thing about tgis is that the providers can require different kinds of MFA at their discretion though.
But, what would happen to that poor app if I have a live account associated with my gmail and a google account associated with my o365 mail? ....
Come to think of it, I have an email account to which I have associated an ms live account AND an o365 corporate account, and a google account ... Very confusing ...
Maybe they're just joining a trend that they don't realise has benefits to others but not themselves?
By way of background I should point out that logins can be a Lot more complicated than just "enter login and password" and critically the complexity may be different per user.
For example some users have 2FA turned on, so we need to collect user name, password And say SMS code. This is the very tip of the iceberg.
So identifying the user first can make it easier to then determine which path to follow.
Ultimately I didn't go this route because AJAX can be used to get the user-name when entered. However it can then get complicated when the user name and password are entered and the login button clicked at the same time (like by a password manager).
So multi-step input is easier to code.
Other services show both the username/password but send requests to the server as the user types their email address and take away the password field if it's an email associated with an SSO domain. I believe this is how Dropbox does it (could be remembering wrong).
Go head and inspect the source for the Google account screen where you put in your email and you'll see a password field a few elements down with the name "hiddenPassword" with "display: none" set on it. This is a well known approach.