Not that strange. Different users may belong to different groups which may have different authentication backends. The associated authentication method is brought up once a username has been provided.
I don’t like it when I need to sign in twice for single sign-on. The email/username then tells the system if they need to be directed to another sign in page. Like Google or Microsoft. This then allows you access without having to give them your password.
And the auto-submitting TOTP entry form where you’re apparently not allowed to make a typo. And obscuring the TOTP number like it’s a password or state secret.
This is because of Enterprise Single Sign On. You can try this for yourself by going to https://gmail.com/ and enter the email of a public person at a large org, for example the CEO of Doordash (tony@doordash.com). After you enter the email, you get sent to Doordash’s employee portal to authenticate. Based on the email you provide, Gmail has to figure out if you need to provide a password to gmail itself or if the email authenticates another way.
It’s not like you can’t add a “Log in with your company’s SSO” button to the form. That works just fine and at least Microsoft does something like that.
Not sure I’d take design inspiration from Microsoft of all places. Also https://login.live.com/ has the same workflow email -> continue -> password. Not sure where you’re seeing Log in with SSO option.
I see the Login with SSO option all over the place. Of course, that assumes the users actually understand what that means, and they know whether or not they need to click it.
My company uses Entra ID (or whatever they’ve renamed it to this week) and it’s a pretty common sight in our login flow. I think our SharePoint instance does it so it should be something MS does.
Of course it all depends on w how the company configures it.
Ok, I think I get what you’re saying. You mean have a different form input without the password, like how it’s done here: https://eu.app.orcasecurity.io/login? I guess that’s one way to do it, but it’s not really intuitive from a user perspective, since the first thing you see is a password field, and then think you don’t have access because you don’t have a password. This one comes to mind because I have had to tell people to click the tab for the email only field, not email and password.
I also often see implementations where there’s a first step where you have to select how to log in. It’s an extra click but very clear (and usually one of the options is some form of SSO where that one click fully logs you in if you already have a session open).
That ones because users like choice. They need to look up who you are to know how you’ve chosen to authenticate. At least, that’s how it started. Some could be doing it because the big kids are, but that’s why the big kids do.
And they support choice because businesses want to use their login infrastructure and refuse to share. So you enter “user@businessOrUniversity.com.edu” and it forwards you to your institutional login.
Also This strange trend to split username and password on to two separate pages, or only showing the password field after confirming the username
Not that strange. Different users may belong to different groups which may have different authentication backends. The associated authentication method is brought up once a username has been provided.
if your choice of api route directly affects your auth flow something is very wrong.
I don’t like it when I need to sign in twice for single sign-on. The email/username then tells the system if they need to be directed to another sign in page. Like Google or Microsoft. This then allows you access without having to give them your password.
You can do that as part of an OAuth workflow. You don’t need to have them on separate pages for that to happen.
Yes, but, it also lets them slurp up email addresses. Routing users is legit tho.
And the auto-submitting TOTP entry form where you’re apparently not allowed to make a typo. And obscuring the TOTP number like it’s a password or state secret.
This is because of Enterprise Single Sign On. You can try this for yourself by going to https://gmail.com/ and enter the email of a public person at a large org, for example the CEO of Doordash (
tony@doordash.com). After you enter the email, you get sent to Doordash’s employee portal to authenticate. Based on the email you provide, Gmail has to figure out if you need to provide a password to gmail itself or if the email authenticates another way.It’s not like you can’t add a “Log in with your company’s SSO” button to the form. That works just fine and at least Microsoft does something like that.
Not sure I’d take design inspiration from Microsoft of all places. Also https://login.live.com/ has the same workflow email -> continue -> password. Not sure where you’re seeing Log in with SSO option.
I see the Login with SSO option all over the place. Of course, that assumes the users actually understand what that means, and they know whether or not they need to click it.
And remembers which one they choose when registering.
Zoom has it, for example.
My company uses Entra ID (or whatever they’ve renamed it to this week) and it’s a pretty common sight in our login flow. I think our SharePoint instance does it so it should be something MS does.
Of course it all depends on w how the company configures it.
Ok, I think I get what you’re saying. You mean have a different form input without the password, like how it’s done here: https://eu.app.orcasecurity.io/login? I guess that’s one way to do it, but it’s not really intuitive from a user perspective, since the first thing you see is a password field, and then think you don’t have access because you don’t have a password. This one comes to mind because I have had to tell people to click the tab for the email only field, not email and password.
I also often see implementations where there’s a first step where you have to select how to log in. It’s an extra click but very clear (and usually one of the options is some form of SSO where that one click fully logs you in if you already have a session open).
No it doesn’t work fine, because it confuses people, and provides the potential for working-around SSO.
That ones because users like choice. They need to look up who you are to know how you’ve chosen to authenticate. At least, that’s how it started. Some could be doing it because the big kids are, but that’s why the big kids do.
And they support choice because businesses want to use their login infrastructure and refuse to share. So you enter “user@businessOrUniversity.com.edu” and it forwards you to your institutional login.
That’s there to support routing to an identity provider for SAML2 SSO.
Came here to say that! For the love of God, stop with this nonsense!