Authentication
Signing in is a gate in front of the thing people came for, so every decision is about removing steps without removing safety.
Definition
Authentication covers sign-up, sign-in, recovery and elevation. It is the surface where security requirements and usability requirements meet most directly, and where the cost of a small annoyance is multiplied by every session.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this plate
Reach for this when
- Designing sign-up, sign-in, recovery or account switching.
- Sign-in support volume or reset rates are high.
- Introducing a second factor or passkeys.
Common mistakes
- Blocking paste or autofill.
- Rules revealed only after rejection.
- Generic failure messages that hide a locked or unverified account.
- Redirecting to a dashboard instead of the page the reader wanted.
- Composition rules that force complexity while blocking the password managers that would have produced a genuinely strong password.
Methods and what each costs
| Method | Good for | Cost |
|---|---|---|
| Password with a manager | Universal, understood, portable | Reset traffic, reuse across sites, and rules that fight password managers. |
| Email or SMS code | No password to remember or store | Delivery delay, inbox switching, and SMS interception risk. |
| Passkeys | Fast repeat sign-in, phishing resistant | Recovery and multi-device support still confuse people, so keep a fallback. |
| Social or SSO | One click, no new credential | Account fragmentation, and lock-out when the provider account changes. |
| Second factor | Real protection for valuable accounts | Every prompt is a chance to lose someone. Reserve it for sensitive actions. |
The decisions that matter
Do
- Allow paste, autofill and password managers everywhere. Blocking them makes passwords weaker, not stronger.
- State the password rules before the field is filled, and validate them on blur.
- Say whether an account exists in a way you have decided deliberately, and be consistent about it.
- Keep the reader where they were: after sign-in, return them to the page they asked for.
- Offer recovery from the sign-in screen, not from a separate help page.
Do not
- Do not force a password change on a schedule. Current guidance advises against it, and it produces predictable increments.
- Do not use a single 'invalid credentials' message that also fires on a locked account. The reader cannot act on it.
- Do not lose the form contents on a failed attempt.
- Do not gate the whole product behind sign-up when a preview would convert better.
Reducing failed sign-ins
Most sign-in failures are recoverable in the interface rather than in the identity system.
- 1
Keep the email visible
On a two-step sign-in, show the address being used and make it editable without starting again.
- 2
Name the failure honestly
Expired link, locked account, wrong password and unverified email need different messages and different next actions.
- 3
Make codes easy to use
One input that accepts a pasted code, a numeric keyboard on mobile, and autocomplete attributes so the platform can fill it.
- 4
Do not expire aggressively
A magic link that expires in two minutes fails for anyone whose mail is delayed. Fifteen minutes costs little.
Where sign-in actually fails
Almost none of these are password strength problems, which is where most sign-in design attention goes.
| Failure | Cause | Fix |
|---|---|---|
| Wrong method | The account exists through a provider | Say which method this email registered with |
| Blocked paste | Password managers defeated | Allow paste, and mark the field for autofill |
| Code expired | A short window plus an app switch | Longer windows, and one-tap autofill from the message |
| Loop after reset | The new password is rejected by a hidden rule | State every rule before they type |
| Lost second factor | No recovery route | Recovery codes, issued and explained at setup |
In practice
- i.
Guest checkout as an authentication decision
Forcing account creation before purchase is the highest-cost authentication decision most ecommerce products make. Offering the account after the order, prefilled from the details already entered, keeps the conversion and still creates the account.
- ii.
Elevation instead of a permanent gate
Rather than requiring a second factor on every sign-in, a product can require it only when changing payout details or exporting customer data. The protection lands where the damage would be.
- iii.
The account that already existed
Method collisionA reader who signed up with a provider and later tried a password found no account. Telling them which method the address is registered with turns a dead end into one more click.
Local chart
PAT·023 · Region III · Grid F2
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
- [1]
Digital Identity Guidelines, SP 800-63B
NIST, 2017
Source of the current advice against forced periodic password rotation and composition rules.
- [2]
WCAG 2.2, Accessible Authentication (Minimum)
W3C, 2023
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Depends on
Get these right first, or this one will not hold.
- Accessible NamesA11Y·008 · Accessibility
- Labels and InstructionsA11Y·017 · Accessibility
- WCAG in PracticeA11Y·001 · Accessibility
Accessible authentication is a WCAG 2.2 requirement, not a nice-to-have.
Often used with
These usually appear in the same screen or the same decision.
- Text InputCMP·003 · Component
- Input ValidationPAT·007 · Pattern
Practical example
A worked decision where this was the deciding factor.
- Whether to Require an Account at CheckoutCASE·001 · Case study
Related concept
Connected closely enough to change how you apply this.
- Error MessagesWRT·002 · UX writing
- Form Labels and Help TextWRT·009 · UX writing