Understanding authentication flows

The login screen must help the legitimate user get in without handing useful information to an attacker. It is a critical entry point from a security standpoint.

A message that's too precise helps the user, but also informs the attacker. A message that's too vague protects the system, but loses the user. The design of the authentication journey has to reconcile these two requirements, and to do so it's necessary to consider the journey as a whole: input, error, blocking, help, the second factor, the session.

Note: this article draws on NIST's authentication requirements1 and on several OWASP practical guides, covering login2, the session3, password reset4 and the second factor5.

The "identifier-first" flow

Sometimes, asking for the identifier first lets you steer the user toward the right method rather than forcing them to choose:

• The journey happens in 2 steps: "1. who are you?" then "2. prove it".
• Depending on the identifier entered, the screen offers the organization's SSO, an already-registered passkey, or the password.

The fields

A properly configured email field opens the "right" keyboard and disables autocorrect, which would otherwise try to "fix" the address being entered. A one-time-code field can, for its part, suggest the code received by SMS directly, with no round trip to the messaging app.

<!-- Email: right keyboard, no autocorrect or auto-capitalization -->
<input
  type="email"
  inputmode="email"
  autocapitalize="off"
  autocorrect="off"
  autocomplete="username">

<!-- OTP code: automatic suggestion of the code received by SMS -->
<input
  type="text"
  inputmode="numeric"
  autocomplete="one-time-code">

The states

A few good practices to keep in mind regarding micro-states:

• Disable the button as soon as it's clicked and show progress, to prevent double submission and reassure the user.
• Validate at the right moment: on leaving the field, never on every keystroke, and don't show an error before the field has been left at least once.
• Preserve the input: after a rejected password, never clear the email field. Making the user re-enter the address on every attempt is a gratuitous punishment.
• Flag Caps Lock: a discreet warning on the password field prevents unexplained failures.

The password

On the password itself, NIST favors length over complexity1:

• SHALL A password used on its own is at least fifteen characters long.
• SHOULD The system accepts at least sixty-four.
• SHALL NOT Imposed composition rules — an uppercase letter, a digit, a special character — are set aside. They push toward predictable patterns without any gain in security.

A detailed article on passwords is available here.

Error messages

When a login fails, the temptation is to help the user by being specific.
"Incorrect password" tells them their identifier is right. "This identifier doesn't exist" tells them the opposite. In both cases, the interface has just confirmed a piece of information to whoever is asking.

An attacker tests a list of addresses and sorts the ones that "exist" from the ones that don't. This is account enumeration. OWASP recommends a generic message, identical regardless of the actual reason for the failure2. Avoid the likes of "unknown identifier", "wrong password", "account disabled or locked", and instead use:

• "if this address is in our database, we'll send you an email"
• "invalid username or password"

Should you hide whether an account exists?

This neutrality has a drawback, which OWASP frames as a user-experience problem2: a generic message can disorient a well-meaning person who doesn't understand what's wrong and ends up giving up. The trade-off therefore depends on how critical the application and its data are.

That's why some services deliberately choose the opposite. Two-step logins — address first, then password — often reveal that an account exists before even asking for the secret. This choice improves the journey, but it makes enumeration possible. You can only accept it if other protections prevent anyone from profiting from it. Preventing mass attempts strips enumeration of its value, since an attacker can no longer test thousands of addresses2.

For example:

• Rate limiting: after X attempts, the IP is blocked
• CAPTCHA: enumerating thousands of addresses becomes humanly impossible
• Mandatory MFA: even if the attacker knows an account exists, they can't log in without the second factor
• Monitoring: detect and alert on enumeration patterns

Limiting attempts without punishing the user

Locking an account after a few failures seems prudent, but the lockout can backfire on the user. If anyone can lock an account by entering three wrong passwords, the block becomes a denial-of-service tool against the legitimate user.

NIST recommends rate limiting rather than a hard lockout1. The system limits consecutive failed attempts to a hundred per account at most, after which the authenticator is disabled. SHALL That number is a ceiling, not a target: it can be lowered. MAY An honest user rarely goes beyond a few tries, whereas an automated attack tries thousands. Capping at a hundred stops the latter without bothering the former.

NIST describes three ways to reduce the risk of locking out a legitimate user1. First, a bot-detection test before the attempt (reCAPTCHA v3 or Turnstile). Next, a wait that grows with each failure — for example from thirty seconds up to an hour as you approach the ceiling. Finally, analysis of warning signals: an attempt from an unusual IP address or country, or a typing cadence too fast for a human. When one of these signals appears, the system hardens verification — through a bot-detection test or an additional step — or refuses the attempt. After a successful login, the failure counter resets to zero. SHOULD

On the interface side, indicating a temporary slowdown and the steps to take is better than a hard block with no explanation. The user must understand that they'll be able to try again, and how, without the text revealing the exact state of the account.

Helping after a failure

After a failure, the interface must guide the user without reopening the door to information leakage.4.

• A "Forgot password?" link: kept visible and accessible at all times
• A discreet counter: "2 attempts left before a waiting period" warns without blocking abruptly
• A slowdown message: "Too many attempts. Try again in 30 seconds." with a visible timer if possible

Several other aids reduce failures upstream, and NIST ranks them by strength1:

• SHALL Allowing password managers and autofill is mandatory.
• SHOULD Allowing pasting into the field is recommended, when autofill isn't available.
• SHOULD Offering a button to reveal the entered password is recommended too.

These good practices reduce friction at input and, combined with a password manager, encourage stronger credentials.

<!-- Field that helps the password manager and autofill -->
<label for="password">Password</label>
<input
  id="password"
  type="password"
  autocomplete="current-password"
  aria-describedby="pw-help">
<button type="button" aria-pressed="false">Show</button>
<p id="pw-help">Pasting and password managers are accepted.</p>

After login: the session

Once the user is recognized, it's the session that keeps them logged in, and it's the session that becomes the target. The first measure is to regenerate the session identifier right after login3.

The session's lifetime rests on two combined expirations: an idle expiration, which closes the session after a period of inactivity, and an absolute expiration, which closes it after a fixed duration no matter what3.

Accessibility is not optional

Since WCAG 2.2, this is no longer good intent but a standardized criterion, on the same footing as the NIST requirements cited above.

Criterion 3.3.8 Accessible Authentication (Minimum), level AA, prohibits imposing a cognitive function test (memorizing, transcribing, solving a puzzle) at a step of the login, unless an alternative is provided8. Direct consequence: allowing password managers, autofill and pasting is no longer a mere convenience — it's what makes the journey compliant. The earlier point about autofill therefore becomes an accessibility obligation, not a nicety.

Three points round out the picture, in connection with the previous sections:

• Announce errors. A visual error message stays invisible to a screen reader if it isn't signaled. The container must carry an alert role, and the focus must move to the message.
• Don't rely on color alone. Your "Do / Don't" blocks and your error states must remain understandable without color: an icon, a word, a shape.
• Adjustable time limits. Criterion 2.2.1 (level A) requires warning and being able to extend a time limit8: this is exactly the role of the "your session expires in 2 minutes" alert described below.

<!-- Error region announced to assistive technologies -->
<div
  id="login-error"
  role="alert"
  aria-live="assertive"></div>

<!-- Focus moves to this container after the failure -->

Measuring authentication UX

Authentication leaves traces you can measure to improve the experience:

• First-attempt success rate. The proportion of logins completed without error or retry.
• Time-to-auth. The time elapsed between arriving on the screen and actually gaining access. A lengthening signals a complex journey.
• Password reset rate. A high rate often reflects forgotten credentials for lack of a password manager, or a journey that forces people to create too many.