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.
- Firstly, a common "login with email" screen has two fields: email and password.
- 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".
- 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.
- 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:
- In the iOS app user enters their email address and taps "Log in" button.
- 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).
- 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.
- iOS app shows a message: "Email was sent to [email protected] address. Please read it to log in.".
- User opens the email and taps the "Log In" link which opens the iOS app. This link can only be used once.
- 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.
- Users do not need to remember the password. There is nothing to forget.
- 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.
- 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.
- Less code, less bugs, easier to maintain.
- Less UI - there is just one screen with one text field. No need to create separate new/existing user and forgot password screens.
- 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.
- 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.
- Password field may convey a sense of security to people. The absence of password field may feel less secure.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.