12 ms·
That is quite useful however with some federated auth flows, where you just need the email to see where to send them for the actual auth (e.g. Office365 and SAM
by amaccuish 8y ago
That is quite useful however with some federated auth flows, where you just need the email to see where to send them for the actual auth (e.g. Office365 and SAML login), otherwise you'd needlessly be entering your password.
I also much prefer it to the previous way e.g. Office365 worked, where once you'd tabbed away from the email box, they'd detect you needed to be redirected and send you off, whilst most people had begun typing their passwords.
- 8ytecoder 8y agoYeah, federated flows were my guess too. However, the password fields could have been present and hidden in the same page supporting both password managers and avoiding a page transition. And also the hundred other sites that don't need federated flows but think they need to copy this feature as well. Together it's annoying to hit password managers twice for every login.
- amaccuish 8y ago> However, the password fields could have been present and hidden in the same page supporting both password managers and avoiding a page transition But then you run the risk of your password of being submitted to the wrong portal no? > And also the hundred other sites that don't need federated flows but think they need to copy this feature as well Very true. It seems to be becoming increasingly prevalent :(
- 8ytecoder 8y agoi) Hidden and ii) Nothing I enter should be submitted anyway in an SSO flow.
- blattimwind 8y agoPage 1: Email/account name, Page 2: Okay, here are some recatpchas, Page 3: Password. Mistyped it? Start back on Page 1 please.
- tomc1985 8y agoPretty sure that is why... you enter your username and it checks to see what authentication flow to use, if it's a password flow then you get a password screen. Pisses me off too
- deleted 8y ago[deleted]
- jrwoodruff 8y agoBingo. This is why we went with a stepped process. Did you log in with Google, Twitter, Enterprise SSO, or Email? Do you even have an account, maybe you need to create one? It frustrated everyone. Since we've implemented the stepped process (and made other changes) complaints have all but disappeared, and the number of failed sign in attempts has been significantly reduced, successful logins has increased slightly, and overall login attempts dropped. It's not perfect, but all indicators are it's better than a screen full of options - it allows us to guide users to the correct action. Sure, it can still be annoying, but less so than what it was.
- StavrosK 8y agoYour comment confuses me, can you clarify? > This is why we went with a stepped process. [..] It frustrated everyone. But then: > Since we've implemented the stepped process (and made other changes) complaints have all but disappeared
- thisacctforreal 8y ago"[..]" was a list of all the problems that frustrated people before the stepped process.
- StavrosK 8y agoOh, I see, thanks. The list sounded to me like a description of the stepped process, so I was confused.
- 8y ago
- chayesfss 8y agoYes, splitting up auth flow allows you to query auth requirements, query apis for risk/security and more
- joshklein 8y agoWhat reasons are there to avoid doing this asynchronously? (Please note that I’m opposed to requiring user agent javascript to access something claiming to be a website, but let’s assume we’re talking about something behaving like a single-page application post-authentication anyway.)
- enlyth 8y agoI'll give my perspective as a web dev, it can be tricky to time the requests and decide when to query the API asynchronously. Consider a user starts typing an email address, when do you send out the first async request to find out what authentication flow is required? On each onChange event, first time the email is valid, would have issues that your email is foo@bar.com, but foo@bar.co is already valid, so you're probably going to debounce the call by a few hundred ms. What if the user makes typos, or if they are typing in the email very slowly, and so on. You might say it doesn't matter, just don't show any UI feedback until its valid, or keep refreshing the current status, but the problem is your control flow is decided by the email that's typed in. You want to redirect certain users to an SSO page, others to type in their passwords, and so on. susan13@domain.com might need a different authentication flow than susan13@domain.co, which are both valid addresses. Another choice is the onBlur event, but this becomes clunky. Think about when it's triggered and how you would incorporate this into a nice UX, I don't think it's possible. The inversion of control, giving the user time to fill the form in, and press an explicit "Ready, I've typed my correct email in, what's next?" button, makes the flow easy to code. I hope this helps.
- Raidion 8y agoThis is so true it hurts. It honestly sounds like a pretty great idea, so I can see why product would be behind it. "We won't have a login experience like other providers, it would be a total $BRAND_EXPERIENCE_HERE" Then you start getting into the weeds and it's really just not possible to do well.
- jakob223 8y agoDropbox does an AJAX request when you enter your username, and it's fast enough that when you get to the password field it's already greyed out if you use SSO.
- khalilravanna 8y agoThis should be the answer. As soon as the user enters a valid email (regex test) send a request to server to figure out what path they need to go down in the “federated flow”. What we shouldn’t do is diminish the experience for some because the flow for some others is different.
- underwater 8y agoYou shouldn't have a giant sign asking people for something they don't have, it's confusing and discourages people from using your product.
- franciscop 8y agoIt should be onblur, otherwise you'd send requests for: - me@example.c - me@example.co - me@example.co. - me@example.co.u - me@example.co.uk And you'd have to account for all those tricky race conditions happening there
- pmontra 8y agoAnd me@example.co could be the email of another user, so you'll never be able to login with yours.
- velobro 8y agoHelpScout's login is anothrt good example! Definitely echoing other's thoughts that it's the correct way to handle it
- jakear 8y agoDropbox manages to provide both fields, but instantly switch the password to be a “sign in with blah blah” when you’ve typed your email and it recognizes it as using a different provider.
- chrisan 8y ago> That is quite useful however with some federated auth flows This can't be a large majority. I only ever hear complaints. Whats wrong with the suggested way (Harvest example) of having both on the same screen and letting the user choose