Self-service account unlock
A one-hour, single-use unlock link that mirrors the password-reset flow exactly, down to always answering 202 so it never reveals whether an account exists — and runs the same reactivation path the admin unlock button already used.
Somebody who has locked themselves out — five failed sign-in attempts, per Password policy and lockout — no longer has to wait fifteen minutes or ask an administrator. POST /auth/unlock/request and POST /auth/unlock/confirm let them clear the lock themselves, deliberately built to mirror the existing password-reset flow rather than invent a new pattern.
How it works
POST /auth/unlock/requestwith an email address. Whether or not that address has an account, the response is always HTTP 202 — the same enumeration-oracle reasoning the password-reset flow uses: an endpoint that answers differently for a real address than a fake one is a way to discover who has an account with you.- If the address does belong to a locked account, an email carrying a one-hour, single-use unlock token is sent.
POST /auth/unlock/confirmwith that token clears the lock.
Confirming doesn't reimplement lockout-clearing from scratch — it calls the exact same AdminSetUserStatus("active") path the admin console's own unlock button has always used, so the two routes to "unlocked" produce identical results and there is only one place that logic lives.
What it does not do
- It doesn't reset a password. It only clears the account-lockout state — the person still signs in with whatever password they had, which is the correct behaviour when the problem was too many wrong attempts rather than a forgotten password.
- It doesn't tell the requester anything about whether the address exists, on purpose — see the enumeration point above.
- It doesn't touch existing sessions, MFA enrolment, or anything else about the account.
What to do with this
If your support process still routes every locked-out user to an administrator, point them at this flow first — it resolves the single most common lockout cause (too many attempts, not a forgotten password) without anyone having to intervene. Keep the admin unlock action in Password policy and lockout for the cases self-service can't reach: an account whose owner can't receive mail at the registered address, or one you've locked deliberately for a reason you don't want undone by a link.