Over the past 20 years I’ve heard software engineers, architects, and executives espouse the gospel that “the user should not have to know,” and that “the best UX is no UX”.  This is true for many if not most technology scenarios, but good auth cannot be 100% “transparent” or invisible.  Not when a person is making access control decisions and choosing when and where to provide their credential information.  There must be a clear experience that lets them know what is being accessed, by whom, and for how long. In short, access control decisions need to be explicit.

And there’s another reason that having a user experience is crucial, specifically for accessing and using sign in credentials. Consider your home or car keys. Those keys are obviously very important in your life, and they are not “transparent” or invisible. We can see and touch our keys. We know what they are for. And so we develop good habits around them. We most likely have muscle memory built around checking for our keys before we leave the house, work, gym, etc. Most of us probably know where a set of spare keys are stashed as well. This relationship we have with our keys enables us to keep track of them, to keep them protected and available. If our keys were somehow invisible, or if we didn’t interact with them very often or understand how they worked, this would not be the case. Basically, keys and credentials are different from other technical artifacts in that the “friction” or trouble taken to interact with them has a good result: it trains us to make better choices.

The internet of 2024 is one of extremes: for example, most websites interrupt each new user with a popup to explain that “we use cookies”, which is not news because every website does. Meanwhile, authenticated sites and services routinely trade user information with each other without the user knowing at all (see Consent Culture). And for workers, MFA prompts for each desktop, network and app lead to frustration and a tendency to “just approve everything”.

This one may be obvious, but good auth respects the context of a sign-in: for example, what’s being accessed, from where, how the sign-in was authenticated, the privilege level of the user, and environmental risk information; and it uses this information rather than resorting to simplistic rules such as prompts for every new resource, session time limits, or at the other extreme, troubling users just once and then never again. If something new is being requested from a previously consented website, the user should have the chance to provide new, informed consent. But if a new website is requesting a low level of access that multiple other websites likely already use, then maybe the user does not need to be bothered. For workers or for higher risk consumer scenarios such as shopping or financial transactions, the overall risk of the scenario should inform the frequency and experience of auth prompts. As the industry progresses, these experiences should be refined continuously, based on finer grained information, and evolve to trouble users only when the level of security or privacy risk merits it.

The security landscape is fast-moving enough without starting out in a deficit. Phishing, disclosure, and man-in-the-middle attacks are common ways to breach passwords, OTP codes, and other common auth methods. Good auth should embrace methods sufficiently resistant to the most common attacks.

Today this means avoiding factors that can be intercepted, disclosed, and used remotely without detection. Specifically, this means reducing the use of persisted symmetric shared secrets and bearer tokens, passwords, one time codes (OTP), API tokens and other secrets not bound to a proof of possession of a private key.

Good auth not only has an intelligent user experience, it has one that considers human factors such as peoples’ relationships with their phones, their ability or inability to carry phones or other items into work or school, their tolerance for wearables, their sense of privacy and/or aversion to biometrics, and their level of ability or disability.
Corporate security organizations will have their recommendations about what is the most secure authentication factor, but getting the broader population to adopt more secure practices necessitates meeting people where they are. A less secure factor that will be adopted by more of the population is better than nothing and is better than a highly secure factor which people will not use, will use incorrectly, or will attempt to find ways around.

The auth experience is one of the most sensitive in technology. Good auth respects the contract between the user and the “user agent” (usually an app or browser) and helps the user by giving them clear visual cues to help them determine if the interaction is safe. Good auth provides a consistent experience that helps the user to spot anomalies and/or warning signs of things like phishing or fraud.

Whether creating, accessing, or recovering access to an account, whether from a phone or laptop, app or browser, whether the account is for banking, social media, work, entertainment or shopping, the auth experience should guide the user to the best authentication method for their scenario. This could be a built-in authenticator, a security key, a phone app, a password, or something else. This applies to sign in but also enrollment and recovery scenarios. For example, when signing on from a phone to an account that was enrolled from a computer, it makes sense to guide the user to “enroll their phone” for sign on based on the on board PIN or biometric.

Learning from historically bad (for example PKI “cert picker”) user experiences, a good auth experience should surface meaningful information when there are multiple available authentication methods or credentials that are similarly suitable for a scenario. “Meaningful information” is of course subjective, but in general the experience should ensure that the information displayed for method or credential is distinct and that the easiest to use is prioritized. Providing hints based on information the user provided at enrollment time, “my security key” or similar, can help if done carefully. Hints for users are also hints for attackers, but with a secure factor such as a FIDO2 authenticator, the minimal information in the hint does not offer much help to an attacker who is not in possession of the device. (See Webauthn for PKI professionals).

There isn’t just one way to sign in. For most apps and websites, you can either sign in or click something like an “I forgot my password” link, also known as account recovery, to get back into the account based on other information. Good auth makes sure the security of these experiences is consistent with the security of sign in and that users can easily enter the experience they need and that they have the credentials to use.

The auth experience should also account for common variants such as “I’m on a new computer or phone”, for example, by enabling a fallback method (relative to the ideal method for the device.) If I’m on a new phone, I may not have initialized and registered the phone app or platform authenticator. Similarly, if I’m on a new computer I may not have registered my device. There should be an easy entry point to enrollment of a suggested auth method for the new device, for example by identity verification, use of backup methods, or use of a previously enrolled device.

Finally, new users or users who do not succeed in the account recovery experience need a way to create a new account or to appeal access to their existing account. Good auth anticipates these needs and provides entry points into these experiences, including an experience for when all credentials are lost. (see The Factors We Choose).

Good auth recognizes that after a user signs in, a lot of things can change. The user’s location or authorization level could change easily, as could the security status of their device. Within an app, API or resource there are usually multiple sub-resources and authorization levels. Access authorized on initial sign in should be specific and minimal, and once signed in, if access to an additional or higher privileged resource is requested, or if environmental risk factors change, auth should be re-examined. (see Consent Culture, The Factors We Choose).

It’s common for sign on to be followed by a “consent” prompt. This means a downstream resource (another website or app) will gain privileges of its own if the user clicks “Accept”. In these cases it is crucial that the auth experience enables the user to know what access is being requested and for how long. Good auth provides this, as well as an easily discoverable way to revoke or manage access after the initial consent prompt. (see Consent Culture).