Weeellll… you’d hope so, but some users may try to autofill a password with the right username, which will inadvertently fill the password too. And now your vendor (Quip or whomever) can potentially see your employee’s passwords. You have to trust them to throw away any password they see for someone from your org.
Oh yeah, I'm pretty sure Atlassian used to that, too. So I can understand the reason of "making it easier for users" invoked by people implementing this "two step" login.
But I'd argue this is a different issue than the one of giving out what kind of authentication a given login has.
1. It’s usually for institutions. If my email address is username@bigco.com, an attacker already knows that I use BigCo Inc’s internal SSO.
2. It’s avoids having users type (or autofill) their passwords, so if one of (for example) BigCo’s vendors is compromised, the attackers don’t learn the passwords of BigCo employees.
it would be a larger security issue if they didn’t redirect to the SSO provider and instead threw up a page asking for a password.
In many cases SSO means once you’re logged in then you don’t enter a password again for the session anyway- that only works with a redirect.
and your login might not even be a password anyway, or require more information than just a password (like MFA)- our solution for example takes into consideration what you’re logging in to, what device you have and where you are to determine the secrecy level of the thing you’re authenticating into.
