Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Companies like Google and Microsoft use identifier-first screens: where you provide your identifier (like an email) before providing the password.
Why is this done, is this somehow more secure?
I'm setting up a login with Auth0 and identifier-first is one of the options; should I use it?
This is common with federated identity systems where a service authenticates users from many identity providers.
Your email address is used to look up which identity provider can authenticate you. This could be a work, school, or personal account. Upon entering your work email, you would be redirected to a URL from your workplace where you enter your credentials before being redirected back to the service. This is also how services allow you to log in via Facebook, Google, and other popular social media networks.
Which solution you choose as a service provider depends on your needs. Your will need to evaluate each type and weigh the benefits and drawbacks. No system is perfect. You will need to learn how they work and what their vulnerabilities are.
The purpose of this is to redirect to the account's identity provider. However the use case is not selecting between personal login providers such as Facebook or Google. It's to support organisational logins which have organisation-specific user identifiers.
Personal login flows are selected with a dedicated button. The first image in the docs has a "continue with Facebook" button that chooses Facebook as the login provider.
What if the email is registered with multiple services - for example I use the same email for gmail/outloook?
This scenario is handled by manual selection. Auto-detection applies on a domain level rather than an account level. From the home Realm Discovery section of the Auth0 docs:
When a user enters their email, Auth0 will check if the domain matches one from a registered Enterprise Connection. If there's a match, Auth0 redirects the user to the enterprise identity provider’s login page. If the domain doesn't match, the user is prompted to enter their password. This is also known as Home Realm Discovery (HRD).
Entering joe.bloggs@foo-corp.com redirects to Foo Corp's instance because the foo-corp.com domain is registered.
Redirecting to a given domain leaks that the domain is registered with your Auth0 service.
In the Foo Corp example we know that Foo Corp exists however Foo Corp is responsible for not leaking information about the presence or absence of the Joe Bloggs' account.
These redirects support organisations using a product such as Microsoft's Azure AD without being required to give their users' credentials to Microsoft. They organisation can store their credentials in their own instance whilst still allowing access to external services such as Office 365.
I think this is used for when some logins may be forwarded to a seperate auth service. in this case you don't want to see the password at all.
eg, say you allow the user to login to your site with google/facebook/email you can detect which one they want to use from the identifier, but you dont want to see their google password
https://auth0.com/docs/universal-login/identifier-first
In your google example, some users may have corporate "Google Workspace" accounts where the auth is done by the corporations Active Directory domain or whatever
There might be more than one way to authenticate yourself to a service, especially at their scale.
For example, Google lets you use your phone instead of a password, so that means that they'll want to show that screen instead of a password prompt. Microsoft do too, and also provide options for using physical hardware keys like smart cards, fingerprint sensors, etc as the first factor authentication.
If you're using a managed corporate or education account, you might log in using SSO (single sign-on), which means you'll use one account to log in to all your services --- in this case they'll want to redirect you to that portal after you enter an email address, although often it is Google / Microsoft that provide the single sign-on account.
I'm sure there are also some other special cases which cause these screens to be different as well, prehaps when people are locked out of their accounts, or custom interactions designed for specific devices or companies.
From a security perspective, it doesn't really change too much. It does show what account names are available (e.g. if you enter in a bad email address into the Google login form it won't take you to the next step, so rather than a more vauge "invalid email or password" message you're getting "invalid email"), but you get this information already by trying to sign up with an email address that's already in use on the sign up form, so there's really no way around this on a public system like theirs anyway.
@example.comand it'd work the same way. Also, arguably, trying to prevent username enumeration with vague error messages results in loss in UX for a questionable gain in security (especially if you have a public registration page!).