Code concepts for designers: Authentication & authorization
What is Auth?
Those of us who don’t spend our days writing code often think of logging in to an application as one simple, bundled process of declaring who we are with our user ID and password. Behind the scenes, there are actually two important, independent components at play: authentication and authorization. Together, they determine whether a given user is allowed to access information.
Authentication is what we typically think of when we imagine a login. This process answers the question, “Are you who you claim to be?” A user must prove their identity by entering a password. Other authentication solutions require a user to prove themselves by answering questions, clicking a magic link in their email, entering a temporary code, or a combination of these.
Authorization occurs after successful authentication. This process answers the question, “Are you allowed to do this?” This is where user roles and user access permissions come into play. In some applications, there are things that an admin-level user is allowed to do or access that a regular, view-only user cannot.
Together, these auth processes work to secure an application against improper access and malicious use.
Why should designers care about authentication and authorization?
When designing complex applications — especially those that prioritize security — the constraints that emerge around auth processes can become important considerations for designers. Auth flows are a core part of the UX architecture of any secured application. These flows encompass important user tasks that are often associated with high-friction experiences — just think about the last time you forgot a password.
An awareness of these constraints can result in significant time savings through reduced design iterations and rework. You’ll know more about your options, how things can go wrong, and how you can help your users stay on track to success.
Knowing your way around a discussion about authentication will also help you collaborate effectively with software architects in the planning stages of a project. When designers understand these security limitations and why they exist, we are better equipped to navigate tradeoffs, advocate for user experience, and devise creative solutions that help users while also complying with security requirements. When UX professionals, software architects, and security experts can have informed conversations around auth, we can achieve a collaboration that allows applications to have maximum usability and proper security.
Security vs Usability: Understanding the Conflict
Security and user experience are often at odds on some level. There are trade-offs to be made between the two priorities, and no point of balance is right for every application. While security practices like multi-factor authentication can be a headache for users and the designers who want to please them, it’s important to remember that getting your account compromised — perhaps resulting in the theft of personal information or destruction of digital property — is the worst experience of all. It pays to find a UX security solution that works for your users and your context.
Context is everything. Some applications, such as those that guard highly sensitive financial or identification information, need layers of security because a compromised account could lead to severe consequences like identity theft. Other applications may only store nonsensitive information and have little potential for destruction if hacked. When imposing usability burdens in the name of security, it’s important to calibrate the size of that burden to the risk presented by a compromised account. Talk with the business team and software architects on your project to assess the risks associated with your application, and make sure you have a clear answer to the question, “What does it mean for our users if their account is compromised?” Don’t add unnecessary friction by enforcing security requirements that are out of proportion to the sensitivity of the user’s account.
Tell them why. As security standards have evolved in recent years, users are often frustrated by the new and complex requirements around logging into various services. If your application is going to require action from users that is different from what they might expect based on other services with which they interact, give a succinct explanation to justify your users’ effort. For example, many sites still allow unlimited sign-in attempts. If you are making the security-conscious decision to limit log-in attempts, consider error messaging that explains: “To protect your account, login will be locked for 5 minutes after 3 more failed attempts.”
Be generous with guidance. While you should be paying attention to crafting clear, descriptive error messages, you should also offer hand-holding outside of error states on particularly finicky or high-friction tasks like setting a new password. Password strength meters are a good example here, as is live field validation offering feedback on new password compliance with security standards.
Give warnings before automatically redirecting users. When building thoughtful user experiences, it’s a good idea to avoid unexpected application behaviors that could frustrate and confuse users. However, security protocols might impose these behaviors, such as automatic logouts after a period of inactivity. In these situations, give your users a heads up that something is about to happen and give them control if possible.
Authentication: Are you the user you claim to be?
When I authenticate with an application, I enter my credentials and click the submit button on the login form. At this point, the server application will evaluate whether those credentials are acceptable. If they aren’t, I see an error regarding my credentials. If they are acceptable, I will be granted a session ID token that is stored in my browser until it expires (session time-out) or is destroyed (manual log-out).
Let’s delve into some of the areas where authentication and design intersect.
Authentication Method
There are several options for an authentication method, including:
- User ID + password combination
- Single-sign on (SSO) with Google and other services
- Passwordless login through email (“magic link”)
- One-time use codes sent by SMS or an authentication app
- Biometric identity verification like fingerprints or Face ID
You may use a combination of these methods to improve security through multi-factor authentication. The more independent factors employed, the harder it is for a person to gain access to an account that isn’t theirs.
Pro Tip: If you want to use SSO in an iOS app to allow users to sign in with Google, Facebook, or other services, be warned that you must include Sign In with Apple as well. If SSO is included but Apple sign-in is not, the app will fail the App Store review.
Password Setting Rules
People choose bad passwords. A lot. The question for UX professionals is a philosophical one: how much do we restrict a user’s freedom for their own good?
Steer away from demanding that users have a specific recipe of lowercase letters, uppercase letters, digits, symbols, and punctuation. Instead of the strictly prescriptive approach, consider these most important password security principles as you’re deciding what’s best for your application context:
- You should have a minimum length (the standard is 8 characters)
- Let the passwords be as long as the user wants. Long passwords are more secure, so don’t put a max length on that field!
- Do not allow your users to choose a password that is included in the list of 10,000 most common passwords. This is easy to automatically check with live field validation.
- Allow any characters — even emoji! Restricting character sets reduces the security of a password by reducing the number of possible combinations.
Use these as starting points for conversations with the software architect about password requirements. You may still give users the freedom to choose a less-than-optimal password, like 8 lowercase letters. To help these users without forcing their hand, include a password strength meter to help users make informed decisions about how they want to secure their account.
For applications storing sensitive information, you may want to discuss further security requirements with your software architect around forcing password resets periodically and forbidding users from using previous passwords during a password reset.
Generic Error Messaging
Applications that surface error messages that reveal whether or not a specific account exists are at a heightened risk of brute force login attempts. Using feedback from error codes, attackers can write scripts to rapidly test a huge number of random user IDs and determine which of them are associated with real accounts. Once usernames are known, it’s much easier to access an account when you only need to determine the password.
When you are designing for an application that relies on user IDs being private, it’s a good idea to use generic error messages — error messages that are identical regardless of whether or not an account with a given ID exists. This is true for password recovery forms as well as logging in. When a user enters their email address for password recovery, the submission feedback should not give any clue as to whether or not that email address is actually associated with an account.
In some applications, you may even want to extend this information suppression to the registration page so that the application does not reveal if a specific user ID or email address is already in use. Like all of these security-conscious design tips, this method is only useful in specific contexts. For websites like Reddit, where usernames are public information throughout the site, there is no reason to conceal whether a user ID currently exists or not.
Account Locks
If the software architect on the project is concerned about brute force attacks, they may suggest adding CAPTCHA after a couple of failed login attempts. This is useful for slowing the rate at which an automated script can try different passwords.
In some cases, account locks may also be necessary to ensure proper security for a system. In this case, the generic error messaging practices outlined below may also be used to ensure that attackers aren’t able to compile a list of valid user IDs by noting which user ID inputs result in an account lock error (since accounts that do not exist can’t be locked). When using account locking, consider the following:
- What conditions should cause the account to lock? How can we empower users with this knowledge before the account locks so they aren’t surprised when it happens?
- What path will users take to unlock their accounts? If the application facilitates time-sensitive activities, users may need a fast-tracked unlock option facilitated by an administrator or customer service representative.
- In case the account is locked during a malicious access attempt, how will the application communicate the account lock to the user?
- If account enumeration is a concern, what steps need to be taken to ensure that account lock messages do not reveal the existence of a user ID? (See Generic Error Messaging above)
Session Length & Automatic Log Out
Ask the software architect about session lengths and timeouts. If users may be automatically logged out due to inactivity, then be sure to design for this scenario by creating a view that informs users they have been logged out.
If the application involves complicated, lengthy user input processes that might be interrupted by a session timeout (like submitting expense reports or writing reviews). then consider including a warning prompt 60 seconds or more before the session times out to give the user a chance to extend their session.
Email Communication
Don’t forget to design thoughtful emails! Email can be a necessary part of authentication — think of password recovery or account confirmation — but it can also serve an important security purpose as the second factor of authentication or as a way to communicate important security-related events, such as account locks.
In some highly secure applications, it may be a good idea to send an email every time a user logs into their account, attempts to log into their account, or logs in from a new device. In these emails, guide users to reset their password immediately if the access or attempted access was not from them.
Authorization: Are you allowed to do this?
When I authenticate with an application, I enter my credentials and click the submit button on the login form. At this point, the server application will evaluate whether those credentials are acceptable. If they aren’t, I see an error regarding my credentials. If they are acceptable, I will be granted a session ID token that is stored in my browser until it expires (session time-out) or is destroyed (manual log-out).
Here are some design concerns that relate to authentication.
Permissions
Any secured application needs to have clear requirements around what kinds of users are allowed to access what kinds of resources. The determination and scoping of user roles is an essential UX activity that requires us to understand who our users are, how their needs may differ, and what they shouldn’t be able to do.
There are two major approaches that designers can take when drafting rules for user groups: Role-Based Access Control and Rules.
Role-Based Access Control (RBAC) buckets all users into specific user roles that map to a pre-determined set of access permissions. This is useful when the target users of the application fit neatly into very discrete categories, for example, Customers and Sellers for a POS system. A Seller needs to be able to view the transaction totals for the day as well as ring up orders, issue refunds, and manage inventory. A Customer should be restricted from these activities, but they need to be able to swipe their payment, sign, get an email receipt, and enroll in rewards. There may be a large number of roles, and a single person may inhabit different roles at different times (Uber drivers take rides too, sometimes) but at any given moment the user can have their needs met completely in one of these buckets. There is no gray area, and all new users must be slotted into a role.
Rules accommodate more gray area because there are no set buckets. Instead, when a user is created, access permissions can be granted or denied individually. Can they see this information? Can they edit that information? Can they delete other users? Can they view other users of the system? All of these questions can be answered individually by the person who is creating a new user. This requires more effort on the part of the person managing users, but they are granted more granular control. Rules access is useful for apps targeted towards organizations where users have a variety of responsibilities and access to user access is best determined by the organization’s internal administrators.
Scoped Access Tokens
Consider an application that is used by a university to store students’ grades and performance records. One of this application’s users, an administrator, has access to change or delete students’ exam scores. All faculty at this university are warned not to leave their computers unattended, but there have been incidents in the past of unattended laptops being used by students to change their academic records. How can we solve this?
Scoped access tokens place limits on what a given session token can accomplish before a new session token is required via re-authentication. This means that we can give all administrators the access they need to change records, but we can require that they prove their identity again before doing anything potentially destructive. The user is permitted to perform these actions, but the session itself is not. If the administrator’s computer falls into the wrong hands with a session open, a student who attempts to change their grade will not be able to do so without knowing the administrator’s password.
403 Forbidden Errors
When a user attempts to access part of an application that they are not authorized to view, they will receive a 403 Forbidden error. In the spirit of generic error messages explored earlier in this article, some projects may require that these 403 errors be presented as 404 errors (Page Not Found). This presentation ensures that the unauthorized user won’t even be given the information to know that the resource exists. This may be an important consideration to keep in mind when designing error pages and their copy.
Conditional UI
When different users have access to different resources within the application, this creates design complexity around navigation. Obviously, users shouldn’t see links to areas of the application they cannot access. Be mindful of this when designing application pages and be sure to create documentation that clearly defines what parts of the UI are hidden or visible for different user groups. This is an important part of design handoff to engineers. While we may assume that engineers will intuit the need to hide certain navigation elements for particular user groups that can’t access them, that assumption can create ambiguity and inefficiency. Clear, detailed documentation can be time-consuming, but it’s a worthwhile investment in a project’s success.
Wrapping Up
Authentication and authorization have design implications throughout any secured software application. A basic understanding of these and other application security concepts can empower you as a designer and as a member of a product development team to make thoughtful design decisions and collaborate effectively with software architects and engineers.
Above all, communicate with the software architect to get a detailed, nuanced understanding of the security policy for any given project. Think through how these decisions may impact UI. Ask questions and propose scenarios until you feel confident in your understanding. Flow diagrams in programs like Miro can be extremely helpful communication tools for expressing your understanding of how users will move through the application. Include login, forgot password, and sign up flows in your diagrams and share these with the software architect to confirm your understanding before proceeding further into detailed UI work.
If you are interested in learning more about application security best practices, check out OWASP. The Auth0 documentation contains helpful information about
Resources
- OWASP Top Ten Web Application Security Risks (https://owasp.org/www-project-top-ten/)
- Auth0 docs on authentication (https://auth0.com/docs/authorization)
- Udacity: Token-Based Authentication (https://www.youtube.com/watch?v=woNZJMSNbuo)
Stable Kernel is a full-service custom software firm located in Atlanta, Georgia. We offer world-class market research, design, engineering, and digital strategy to enable our clients’ digital transformation. Learn more about us.
