5 ms·
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?
- dylz 6y agoSAML, single sign on, 2FA confirmation, etc. For 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.
- Nextgrid 6y agoSingle sign on is indeed the reason. However, I don’t agree that this behavior is a good thing - as an industry we’ve failed; we’re inconveniencing a large chunk of users because of an implementation detail. SSO should’ve either been implemented transparently in the underlying protocols or the browser (like Kerberos actually is) or at the very least provide separate login pages so that regular users can bookmark the right one and avoid wasting time if they are not using SSO.
- popotamonga 6y agothey could just hide/show the passw field and not put it on a diferent page. make the email request on background
- NicoJuicy 6y agoSPA apps wouldn't like that, security wise.
- ta17711771 6y agoSPA?
- bruce511 6y agoSingle page application. 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.
- pests 6y agoBad UX imo. User types email and then the password field disappeared! How am I gonna log in now?
- jonplackett 6y agoInteresting - yes that does happen with google and that seems like why 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.
- NicoJuicy 6y agoGuest accounts
- TheJoeMan 6y agoThen we all have to enter our email twice. Why not just ask for the info you actually want: login with password or login with sso buttons
- imnotjames 6y agoBecause you could have thousands. 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...
- dredmorbius 6y agohttps://security.stackexchange.com/a/85180 https://security.stackexchange.com/a/85180
- RealStickman_ 6y agoI'd like to mention that bitwarden seems to handle that rather well (the browser extension at) on the sites I tried. (Backblaze and google login for example)
- netsharc 6y agoevernote.com shows the username field, and you have to click "continue" and it has some dumb slow animation that reveals the password field. If you get your password wrong, the screen freezes for a few seconds, then the password field disappears and the reveal animation happens again, now with the "Incorrect password" message. Maybe they really want people to use their app.
- bigums 6y agoI thought the original intent was to help prevent phishing. If you have to enter you username on the initial page, the subsequent page could then present you with your profile picture and name. That would then condition the user to look for it. I have no evidence to validate that, but just how I thought it was designed to work. All of the other comments seem to have much more logical explanations, like SSO and OAuth options.
- kayman 6y agoThe reason your username and password are on different pages is to handle federated identities. Take a typical saas product. Initially you build your own login username and password. As you grow your users ask to login using gmail, LinkedIn or Microsoft so they don’t have to remember multiple usernames and passwords. If you enable third party login it means you have to redirect the site to the third party login page to authenticate. 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.
- woutr_be 6y agoThat seems like a strange flow, it means the user first has to input his email on your app, then you redirect to Microsoft, user will have to input his Microsoft email and password, and redirect back to your app. 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?
- aliswe 6y agoYou often don't have to put in the email again, thanks to eg. the username hint. 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 ...
- enchiridion 6y agoJWT == JSON Web Token I had to look it up. https://en.m.wikipedia.org/wiki/JSON_Web_Token https://en.m.wikipedia.org/wiki/JSON_Web_Token
- bruce511 6y agoI don't do this myself, but I did consider doing it, because to some degree it simplifies work flow in the login process. 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.
- kevsim 6y agoIf it's done properly, it shouldn't mess with password managers. The trick to doing it properly is to put a hidden password field on the first screen so the password manager can still fill it in. If the page sees them both filled in, it knows it's not dealing with a federated identity situation and can just log the user in. 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).
- aliswe 6y agoDone properly, are you sure about that? Sounds like a security risk to me...
- kevsim 6y agoHow so?
- aliswe 6y agoIf I put it this way ... Don't you think that a password manager entering your password into a hidden input sounds a little strange?
- kevsim 6y agoNot at all. You're explicitly performing an action with your password manager on a domain you've already decided to trust. 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.