Do we really need to ask for password on iOS "login with email" screen?

Question

I am designing a login screen for an iOS app where users login with their email.

The standard approach

Here is the approach that is used by most apps.

1. Firstly, a common "login with email" screen has two fields: email and password.
2. Secondly, apps communicate to the user if they are creating a new account or signing into an existing account. It is usually done by either creating two screens "log in" and "create account" or using a single screen with two buttons "log in" and "create account".
3. Next, some apps implement the email verification when a confimation email is sent to the user. This is done to ensure that user entered a valid and working email address.
4. Finally, there are usually two more screens to reset the password: one where users enter their email address and the other where they enter the new password.

Simplified login with no password field

Can we get rid of the password?

I was just thinking why do we need to ask for a password on the login screen at all? I know it sounds crazy but let me explain.

What if we had just a single login screen with just one email field and a "Log in" button? Here is the proposed workflow:

1. In the iOS app user enters their email address and taps "Log in" button.
2. The server checks if there is an existing user record with given email, if not - it creates a new user account. Also, the server creates a short-lived secret token that will be checked when user taps the link from the email (see below).
3. The server sends an email to this email address. The email body has a "Log In" link. The link has the custom URL scheme for the app and includes the secret token. The link's url can look like this: myapp://login/2a9f1939f281a277b1.
4. iOS app shows a message: "Email was sent to [email protected] address. Please read it to log in.".
5. User opens the email and taps the "Log In" link which opens the iOS app. This link can only be used once.
6. iOS app sends the secret token to the server, if it matches the one in the database the user is logged in.

Message shown after tapping "log in" button

Note: the "Read email" button in the dialog opens the Mail iOS app, I created a demo app and confirmed that it works reliably.

Email sent to the user

The following are the pros and cons that I collected with help of my colleagues and those who responded here.

Pros

1. Users do not need to remember the password. There is nothing to forget.
2. We can always be sure the email is entered correctly because users need to receive it in order to log in. This, in my opinion, is the strongest feature of this approach. This will eliminate cases when people create accounts with mistyped email addresses and are not able to login later. Mistyped emails can frustrate users and create a lot of unnecessary support communication.
3. It may be more secure for majority of users because as we know a lot of people may use common/weak passwords and/or reuse same password on many different apps and web sites. This allows script kids to impersonate the user and log into the app by trying common passwords or using person's leaked password from other service.
4. Less code, less bugs, easier to maintain.
5. Less UI - there is just one screen with one text field. No need to create separate new/existing user and forgot password screens.
6. Eliminates a privacy issue on "create account" screen when it returns an error "this email already registered" which allows attackers see if a person has an account with the service.

Cons

1. This may be unintuitive because we are used to seeing password field on login screens. A login screen without password may look weird and unfamiliar. I personally think this can be the biggest problem. Unfamiliar things can be scary to humans.
2. Password field may convey a sense of security to people. The absence of password field may feel less secure.
3. Context switching? User need to open email app in order to login. Counterargument: user opens email anyway if we want to verify the email validity upon registration in the standard workflow.
4. Less secure? Other people who have access to the phone or person's email can log in. Counterargument: same problem exists in standard workflow: if you have access to email you can tap 'forgot password', get the email, change the password and log in.
5. What if user mistypes the email? The system will create a new account for mistyped email. Counterargument: if person mistyped email address they won't receive the email message and won't be able to login. The users will know early that something is not right as opposed to mistyping email in the standard approach where users will know about it later after they loose access to the mistyped account they already populated with data.
6. What if I knew someone's email and I just used it on my own device. Counterargument: the workflow requires you to read the email and tap the "log in" link in it. If you do not have access to person's email you won't be able to log in.
7. Each time the user logs in they need to open the email. Counterargument: that is true but on iOS people usually stay logged into the app for long time unless they deliberately want to log out.
8. If users can't read their email they can't log in.

Is there anything that I am missing? Are there other disadvantages to this "no password" approach?

Log in with phone number?

The no-password approach can be used with "Log in with phone number" method as well. The logic remains the same except that instead of emailing the login link we send it to the user by SMS. It is handy for developers because they can reuse big portion of server side logic to support email and phone number logins.

Let us continue this discussion •ᴥ•

Thank you so much for contributing to this discussion, I really appreciate your help. It think it is important for us to discuss and try new approaches and see how they work. If you have any experience of implementing no-password approach feel free to share your outcomes here.

Further reading

• Data Monday: Login & Passwords by Luke Wroblewski
• Is it time for password-less login? on notes.xoxco.com
• Design Solutions for New Log In Problems by Luke Wroblewski
• 30 years of failure: the username/password combination on arstechnica.com
• Signing in to Medium by email

Answer 1

Your proposal actually complicates things for the user

Current user interaction:

• type in email
• tap password box
• type in password
• tap [login] button

Proposed user interaction:

• type in email
• tap password button
• wait for notification
• tap notification to switch app
• tap login button

Your idea is that there is "just a single screen" but you overlook the fact that going to the email and back to the login app is essentially two screen switches. You're dropping one interaction (password) but adding several interactions. Interactions that switch context, no less.

Other disadvantages? Plenty.

• you're reliant on their email. if it's down, no login
• less security. Anyone that can get in their phone or mail can get in to your app. Presumably you wouldn't want this because you're using PW/verification
• like JeromeR mentioned, clunky handling of typing errors
• multiple trips between app and your servers instead of just one
• relies on app-starting functionality of email/OS. Not all clients/platforms might support this (well)

Answer 2

Medium have gone for the no password route and it's certainly doable despite what some might say. It's controversial but essentially what they do is shift the security focus over to the email provider and send you a link/email each time you log in so you can see something unusual. Sounds like bad UX to me though as:

• you end up filling people email accounts with rubbish (like Linkedin or something)
• if a persons email address is insecure then it's pointless anyway
• it is disconcerting for users as password authorisation is a long established way to access services.

That said, it's definitely worthy checking out their article on the idea:

https://medium.com/the-story/signing-in-to-medium-by-email-aacc21134fcd