captured core.sign-in-token

Sign in with a password for tokens

A caller posts an email address and a password as JSON. QAuth refuses a locked-out address, counts the attempt, reserves it on the account's failure ladder, checks the password, the verified-account gate and the enabled flag, and refuses every failure with the same 401. On success it signs an access token for the system client, which carries no scope, stores a new refresh-token family, records the sign-in and answers with both tokens.

What this view shows

POST /auth/login from the request to the response, in the order the server runs its checks.

Open world: what is not drawn here is not ruled out. Only the guarantees below are binding.

Left out of this view:

a store failure while the password is checked or the user is read answers 500 the same way as one after it: user.sign_in_failed is recorded with the reason internal_error first, and the answer waits out the floor; a failure to record a refusal (user.sign_in_failed) turns that refusal into a 500
Fastify's own answers before the schema check, as problem documents, such as a body of a media type no parser takes (415, unsupported_media_type) or an empty body sent as application/json (400, bad_request)
the causes of a 421 (a malformed or unknown host, a disabled realm, a realm with no issuer) give one answer and are drawn as one exit; an endpoint host of the realm is served, since this is an api route
with RATE_LIMIT_ENABLED=false the login limit is not applied
in a realm whose brute-force policy is off (bruteForce.enabled false, which FAILED_LOGIN_TRACKING_ENABLED=false seeds in a new realm, #528) no attempt is counted and no address is ever locked out; a cache failure while an attempt is counted fails open: the attempt is let through, and what was counted stays counted
an attempt that reaches the threshold together with another one, which armed the lockout first, was counted on its way in: it is refused as locked out and gives its count back best effort, so a cache failure at that moment leaves it counted; its Retry-After is then the realm's full bruteForce.lockoutSeconds, not the seconds left
LOGIN_RATE_LIMIT must stay above the realm's bruteForce.maxAttempts (the defaults are 5 and 5) for one client address to meet the lockout: at or below it, the login limit refuses that address with its 429 by the request after its last counted failure, and the lockout answer is never sent to it, though the lockout still holds against attempts on the same account from other addresses. binding.yaml sets the limit above the threshold
a password credential whose credential_data is malformed, or whose provider identity disagrees with its row, answers like a wrong password and logs an error; one whose users row is missing answers like a disabled user and logs an error. Neither happens in normal operation
the failure ladder's hard action (#615): the 100th consecutive counted failure of an enabled account's usable password marks it disabled (user_credentials.disabled_at) only while the hard action is armed, which needs the owner's hosted password reset (#642) and the notice that tells the owner (#637). Neither exists, so it is never armed: the ceiling only logs a warning, a mark is ignored, and a successful sign-in clears it. Armed, a marked password answers like a wrong password, after the decoy hash is verified
a rotation of the realm's cookie key changes the keys of the failure ladder, which are derived from it: every account's run of failures and its known addresses start afresh within a minute
the system client is created on the realm with its first direct sign-in, with a random secret nobody is given; SYSTEM_CLIENT_ID names it
with HYBRID_SIGNING_ENABLED the access token is the same Ed25519 JWS, and its detached ML-DSA signature (JWT_MLDSA_PRIVATE_KEY) is stored in the cache for introspection; a failure to store it answers 500
the effects are not one transaction: a failure after the refresh token is stored leaves it stored, though the caller never receives it

The main story

When: The host is a host of an enabled realm with an issuer, the address is under its limit, the body passes the schema, and neither the address being signed in to nor the client address is locked out, the address has a password credential in this realm, its address confirmed, and its user is enabled, the posted password is the credential's, the realm's accounts.requireVerifiedAccount is on, the default (#528); REQUIRE_VERIFIED_ACCOUNT unset, blank or true seeds it so in a new realm.

Wait for a sign-in request: POST /auth/login arrives with an email address and a password
Find the realm of the host: the request has its realm
Count the request against the login limit: the address is under its limit
Check the body against the login schema: the body matches the schema
Refuse a locked-out address, else count the attempt: the attempt is counted on the address being signed in to and on the client address
Reserve the attempt on the account's failure ladder: the attempt is counted on the account's ladder, and the next wait set
Check the password: the password is right
Apply the verified-account gate: the address is confirmed, or the gate is off
Read the user, for its enabled flag: the user is enabled
Sign an access token for the system client: the access token is signed, and a refresh token of 32 random bytes generated
Store the refresh token, hashed, as a new family: the refresh token is stored
Record the sign-in: the event is recorded
Record the time of the sign-in on the user: lastLoginAt is written
Settle the counted attempt: the attempt is settled

Result: Answer with the tokens.

The flow

Show failure paths and “the user closes the page”

blue line: the main storyred dashed line: a failure path (shown with “Show failure paths”)dotted line: decided by a rule, nobody actsdashed grey box: the server decides, nothing is shown

What each step answers

Step	The outside world sees
Answer with the tokens tokens_issued	200 · headers: {"Cache-Control":"no-store","Pragma":"no-cache"} · body: {"access_token":"an Ed25519 JWT signed with JWT_PRIVATE_KEY, iss JWT_ISSUER, for the system client","refresh_token":"64 hexadecimal characters","expires_in":"the access token's lifespan, in seconds","token_type":"Bearer"}
Refuse a locked-out address too_many_requests.locked_out	429 · headers: {"Retry-After":"the seconds left on the lockout; the realm's full bruteForce.lockoutSeconds for an attempt that lost the race to arm it"} · body: {"type":"https://docs.qauth.dev/reference/problem-types/#too-many-requests","title":"Too many requests","status":429,"detail":"Too many failed login attempts. Please try again later.","instance":"/auth/login","code":"too_many_requests","trace_id":"the request id"}
Refuse an attempt inside the account's wait too_many_requests.ladder_wait	429 · headers: {"Retry-After":"the seconds left on the account's wait, rounded up"} · body: {"type":"https://docs.qauth.dev/reference/problem-types/#too-many-requests","title":"Too many requests","status":429,"detail":"Too many failed login attempts. Please try again later.","instance":"/auth/login","code":"too_many_requests","trace_id":"the request id"}
Refuse the attempt when the failure ladder cannot answer service_unavailable.ladder	503 · headers: {"Retry-After":"5"} · body: {"type":"https://docs.qauth.dev/reference/problem-types/#service-unavailable","title":"Service unavailable","status":503,"instance":"/auth/login","code":"service_unavailable","trace_id":"the request id"}
Refuse an address with no account, like a wrong password invalid_credentials.unknown_identifier	401 · body: {"type":"https://docs.qauth.dev/reference/problem-types/#invalid-credentials","title":"Invalid credentials","status":401,"detail":"Invalid email or password","instance":"/auth/login","code":"invalid_credentials","trace_id":"the request id"}
Refuse a wrong password invalid_credentials.wrong_password	401 · body: {"type":"https://docs.qauth.dev/reference/problem-types/#invalid-credentials","title":"Invalid credentials","status":401,"detail":"Invalid email or password","instance":"/auth/login","code":"invalid_credentials","trace_id":"the request id"}
Refuse an unconfirmed account under the gate, like a wrong password invalid_credentials.email_not_verified	401 · body: {"type":"https://docs.qauth.dev/reference/problem-types/#invalid-credentials","title":"Invalid credentials","status":401,"detail":"Invalid email or password","instance":"/auth/login","code":"invalid_credentials","trace_id":"the request id"}
Refuse a disabled user, like a wrong password invalid_credentials.account_disabled	401 · body: {"type":"https://docs.qauth.dev/reference/problem-types/#invalid-credentials","title":"Invalid credentials","status":401,"detail":"Invalid email or password","instance":"/auth/login","code":"invalid_credentials","trace_id":"the request id"}
Refuse a body that does not match the login schema validation_error.body	400 · body: {"type":"https://docs.qauth.dev/reference/problem-types/#validation-error","title":"Validation error","status":400,"detail":"The request is not valid.","instance":"/auth/login","code":"validation_error","trace_id":"the request id","errors":[{"pointer":"/<the field>, such as /email","message":"the schema's message, such as: Invalid email format"}]}
Refuse a host QAuth does not answer for misdirected_request.host	421 · body: {"type":"https://docs.qauth.dev/reference/problem-types/#misdirected-request","title":"Misdirected request","status":421,"detail":"This server does not answer for the requested host","instance":"/auth/login","code":"misdirected_request","trace_id":"the request id"}
Refuse a request over the login limit too_many_requests.login_limit	429 · headers: {"x-ratelimit-limit":"LOGIN_RATE_LIMIT","x-ratelimit-remaining":"0","x-ratelimit-reset":"the seconds until the window resets","retry-after":"the same seconds"} · body: {"type":"https://docs.qauth.dev/reference/problem-types/#too-many-requests","title":"Too many requests","status":429,"detail":"Rate limit exceeded, retry in {the rest of the window, such as 15 minutes}","instance":"/auth/login","code":"too_many_requests","trace_id":"the request id"}
Fail on a store error server_error.store	500 · body: {"type":"https://docs.qauth.dev/reference/problem-types/#internal-error","title":"Internal error","status":500,"instance":"/auth/login","code":"internal_error","trace_id":"the request id"}

How it decides what happens next

Find the realm of the host

#	If	Then
1	the host names no enabled realm with an issuer	Refuse a host QAuth does not answer for
2	the request has its realm	Count the request against the login limit

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`hostUnknown`	`misdirected_request.host`	20 of 140
2	otherwise	`rateLimiting`	120 of 140

hostUnknown: gate == 'unknownHost'

Count the request against the login limit

#	If	Then
1	the address has used up its login requests	Refuse a request over the login limit
2	the address is under its limit	Check the body against the login schema

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`rateLimited`	`too_many_requests.login_limit`	20 of 120
2	otherwise	`validatingBody`	100 of 120

rateLimited: gate == 'rateLimited'

Check the body against the login schema

#	If	Then
1	the body does not match the schema	Refuse a body that does not match the login schema
2	the body matches the schema	Refuse a locked-out address, else count the attempt

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`inputInvalid`	`validation_error.body`	20 of 100
2	otherwise	`checkingLockout`	80 of 100

inputInvalid: gate == 'invalidInput'

Refuse a locked-out address, else count the attempt

#	If	Then
1	an identifier is locked out; the floor is waited out	Refuse a locked-out address
2	the attempt is counted on the address being signed in to and on the client address	Reserve the attempt on the account's failure ladder

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`lockedOut`	`too_many_requests.locked_out`	20 of 80
2	otherwise	`reservingAttempt`	60 of 80

lockedOut: gate == 'lockedOut'

Reserve the attempt on the account's failure ladder

#	If	Then
1	the ladder cannot answer; user.sign_in_failed is recorded with the reason internal_error, and the floor is waited out	Refuse the attempt when the failure ladder cannot answer
2	the account is inside its wait; the floor is waited out	Refuse an attempt inside the account's wait
3	the attempt is counted on the account's ladder, and the next wait set	Check the password

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`ladderUnavailable`	`service_unavailable.ladder`	20 of 60
2	`ladderWait`	`too_many_requests.ladder_wait`	20 of 60
3	otherwise	`checkingPassword`	20 of 60

ladderUnavailable: gate == 'ladderUnavailable'
ladderWait: gate == 'ladderWait'

Apply the verified-account gate

#	If	Then
1	the address is not confirmed, and the gate is on; the floor is waited out	Refuse an unconfirmed account under the gate, like a wrong password
2	the address is confirmed, or the gate is off	Read the user, for its enabled flag

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	`unverifiedUnderTheGate`	`invalid_credentials.email_not_verified`	2 of 8
2	otherwise	`findingUser`	6 of 8

unverifiedUnderTheGate: account in ['unverified', 'disabledUnverified'] and requireVerified

Settle the counted attempt

#	If	Then
1	the attempt is settled	Answer with the tokens

The first matching rule wins.

Exact conditions

#	Condition	Goes to	Situations
1	otherwise	`tokens_issued`	3 of 3

Every way it can end

It ends with	When	What happens
Answer with the tokens ends here	The host is a host of an enabled realm with an issuer, the address is under its limit, the body passes the schema, and neither the address being signed in to nor the client address is locked out, the address has a password credential in this realm, its address confirmed, and its user is enabled, the posted password is the credential's, the realm's accounts.requireVerifiedAccount is on, the default (#528); REQUIRE_VERIFIED_ACCOUNT unset, blank or true seeds it so in a new realm	Wait for a sign-in request: POST /auth/login arrives with an email address and a password Find the realm of the host: the request has its realm Count the request against the login limit: the address is under its limit Check the body against the login schema: the body matches the schema Refuse a locked-out address, else count the attempt: the attempt is counted on the address being signed in to and on the client address Reserve the attempt on the account's failure ladder: the attempt is counted on the account's ladder, and the next wait set Check the password: the password is right Apply the verified-account gate: the address is confirmed, or the gate is off Read the user, for its enabled flag: the user is enabled Sign an access token for the system client: the access token is signed, and a refresh token of 32 random bytes generated Store the refresh token, hashed, as a new family: the refresh token is stored Record the sign-in: the event is recorded Record the time of the sign-in on the user: lastLoginAt is written Settle the counted attempt: the attempt is settled
Refuse a locked-out address ends here	The address being signed in to, or the client address, is locked out: the realm's bruteForce.maxAttempts attempts were counted on it within its bruteForce.windowSeconds, and its bruteForce.lockoutSeconds have not passed (#528: the realm's policies, which the FAILED_LOGIN_* keys seed in a new realm); or this attempt reached the threshold together with another one, which armed the lockout first, the address has a password credential in this realm, its address confirmed, and its user is enabled, the posted password is the credential's, the realm's accounts.requireVerifiedAccount is on, the default (#528); REQUIRE_VERIFIED_ACCOUNT unset, blank or true seeds it so in a new realm	Wait for a sign-in request: POST /auth/login arrives with an email address and a password Find the realm of the host: the request has its realm Count the request against the login limit: the address is under its limit Check the body against the login schema: the body matches the schema Refuse a locked-out address, else count the attempt: an identifier is locked out; the floor is waited out
Refuse an attempt inside the account's wait ends here	The account the address names, held or not, is inside the wait of its failure ladder: from its 5th consecutive counted failure, the n-th makes the next attempt wait 2^(n-5) seconds, at most 15 minutes; and the client address has not signed in to the account in the last 30 days, or 20 of the run's counted failures already came from addresses that have (#968), the address has a password credential in this realm, its address confirmed, and its user is enabled, the posted password is the credential's, the realm's accounts.requireVerifiedAccount is on, the default (#528); REQUIRE_VERIFIED_ACCOUNT unset, blank or true seeds it so in a new realm	Wait for a sign-in request: POST /auth/login arrives with an email address and a password Find the realm of the host: the request has its realm Count the request against the login limit: the address is under its limit Check the body against the login schema: the body matches the schema Refuse a locked-out address, else count the attempt: the attempt is counted on the address being signed in to and on the client address Reserve the attempt on the account's failure ladder: the account is inside its wait; the floor is waited out
Refuse the attempt when the failure ladder cannot answer ends here	The failure ladder's store (Redis) or the realm's cookie key cannot be read in time, the address has a password credential in this realm, its address confirmed, and its user is enabled, the posted password is the credential's, the realm's accounts.requireVerifiedAccount is on, the default (#528); REQUIRE_VERIFIED_ACCOUNT unset, blank or true seeds it so in a new realm	Wait for a sign-in request: POST /auth/login arrives with an email address and a password Find the realm of the host: the request has its realm Count the request against the login limit: the address is under its limit Check the body against the login schema: the body matches the schema Refuse a locked-out address, else count the attempt: the attempt is counted on the address being signed in to and on the client address Reserve the attempt on the account's failure ladder: the ladder cannot answer; user.sign_in_failed is recorded with the reason internal_error, and the floor is waited out
Refuse an address with no account, like a wrong password ends here	The host is a host of an enabled realm with an issuer, the address is under its limit, the body passes the schema, and neither the address being signed in to nor the client address is locked out, the address has no password credential in this realm, the posted password is the credential's, the realm's accounts.requireVerifiedAccount is on, the default (#528); REQUIRE_VERIFIED_ACCOUNT unset, blank or true seeds it so in a new realm	Wait for a sign-in request: POST /auth/login arrives with an email address and a password Find the realm of the host: the request has its realm Count the request against the login limit: the address is under its limit Check the body against the login schema: the body matches the schema Refuse a locked-out address, else count the attempt: the attempt is counted on the address being signed in to and on the client address Reserve the attempt on the account's failure ladder: the attempt is counted on the account's ladder, and the next wait set Check the password: no credential has this address; the decoy hash is verified, and the floor waited out
Refuse a wrong password ends here	The host is a host of an enabled realm with an issuer, the address is under its limit, the body passes the schema, and neither the address being signed in to nor the client address is locked out, the address has a password credential in this realm, its address confirmed, and its user is enabled, it is another one, the realm's accounts.requireVerifiedAccount is on, the default (#528); REQUIRE_VERIFIED_ACCOUNT unset, blank or true seeds it so in a new realm	Wait for a sign-in request: POST /auth/login arrives with an email address and a password Find the realm of the host: the request has its realm Count the request against the login limit: the address is under its limit Check the body against the login schema: the body matches the schema Refuse a locked-out address, else count the attempt: the attempt is counted on the address being signed in to and on the client address Reserve the attempt on the account's failure ladder: the attempt is counted on the account's ladder, and the next wait set Check the password: the password does not verify against the hash; the floor is waited out
Refuse an unconfirmed account under the gate, like a wrong password ends here	The host is a host of an enabled realm with an issuer, the address is under its limit, the body passes the schema, and neither the address being signed in to nor the client address is locked out, the address has a password credential whose address is not confirmed yet, and its user is enabled, the posted password is the credential's, the realm's accounts.requireVerifiedAccount is on, the default (#528); REQUIRE_VERIFIED_ACCOUNT unset, blank or true seeds it so in a new realm	Wait for a sign-in request: POST /auth/login arrives with an email address and a password Find the realm of the host: the request has its realm Count the request against the login limit: the address is under its limit Check the body against the login schema: the body matches the schema Refuse a locked-out address, else count the attempt: the attempt is counted on the address being signed in to and on the client address Reserve the attempt on the account's failure ladder: the attempt is counted on the account's ladder, and the next wait set Check the password: the password is right Apply the verified-account gate: the address is not confirmed, and the gate is on; the floor is waited out
Refuse a disabled user, like a wrong password ends here	The host is a host of an enabled realm with an issuer, the address is under its limit, the body passes the schema, and neither the address being signed in to nor the client address is locked out, the address has a confirmed password credential, and its user is disabled, the posted password is the credential's, the realm's accounts.requireVerifiedAccount is on, the default (#528); REQUIRE_VERIFIED_ACCOUNT unset, blank or true seeds it so in a new realm	Wait for a sign-in request: POST /auth/login arrives with an email address and a password Find the realm of the host: the request has its realm Count the request against the login limit: the address is under its limit Check the body against the login schema: the body matches the schema Refuse a locked-out address, else count the attempt: the attempt is counted on the address being signed in to and on the client address Reserve the attempt on the account's failure ladder: the attempt is counted on the account's ladder, and the next wait set Check the password: the password is right Apply the verified-account gate: the address is confirmed, or the gate is off Read the user, for its enabled flag: the user is disabled; the floor is waited out
Refuse a body that does not match the login schema ends here	The body does not pass the schema: an email that is not an address or is longer than 254 characters, a password longer than 256 characters, a missing field. An empty password passes the schema here, unlike on the form, and is counted and refused like a wrong one, the address has a password credential in this realm, its address confirmed, and its user is enabled, the posted password is the credential's, the realm's accounts.requireVerifiedAccount is on, the default (#528); REQUIRE_VERIFIED_ACCOUNT unset, blank or true seeds it so in a new realm	Wait for a sign-in request: POST /auth/login arrives with an email address and a password Find the realm of the host: the request has its realm Count the request against the login limit: the address is under its limit Check the body against the login schema: the body does not match the schema
Refuse a host QAuth does not answer for ends here	The host names no realm, a disabled realm or a realm with no issuer, the address has a password credential in this realm, its address confirmed, and its user is enabled, the posted password is the credential's, the realm's accounts.requireVerifiedAccount is on, the default (#528); REQUIRE_VERIFIED_ACCOUNT unset, blank or true seeds it so in a new realm	Wait for a sign-in request: POST /auth/login arrives with an email address and a password Find the realm of the host: the host names no enabled realm with an issuer
Refuse a request over the login limit ends here	The client address has used up its login requests for the window, the address has a password credential in this realm, its address confirmed, and its user is enabled, the posted password is the credential's, the realm's accounts.requireVerifiedAccount is on, the default (#528); REQUIRE_VERIFIED_ACCOUNT unset, blank or true seeds it so in a new realm	Wait for a sign-in request: POST /auth/login arrives with an email address and a password Find the realm of the host: the request has its realm Count the request against the login limit: the address has used up its login requests
Fail on a store error ends here	The host is a host of an enabled realm with an issuer, the address is under its limit, the body passes the schema, and neither the address being signed in to nor the client address is locked out, the address has a password credential in this realm, its address confirmed, and its user is enabled, the posted password is the credential's, the realm's accounts.requireVerifiedAccount is on, the default (#528); REQUIRE_VERIFIED_ACCOUNT unset, blank or true seeds it so in a new realm	Wait for a sign-in request: POST /auth/login arrives with an email address and a password Find the realm of the host: the request has its realm Count the request against the login limit: the address is under its limit Check the body against the login schema: the body matches the schema Refuse a locked-out address, else count the attempt: the attempt is counted on the address being signed in to and on the client address Reserve the attempt on the account's failure ladder: the attempt is counted on the account's ladder, and the next wait set Check the password: it fails, because the database fails

Each row is also a generated test: set the starting situation, send the events, expect the ending.

What is guaranteed

These hold in all 852 situations the model can reach, from 140 different starting situations.

Tokens are issued only for an existing, enabled account and its right password, and under the gate only for a confirmed address
Every password checked has been counted first, so guesses sent at once cannot outrun the lockout
Every password checked has been reserved on the account's failure ladder first, so parallel guesses reach the verifier no more often than guesses sent one at a time (#615)
An attempt inside the account's wait, or one the ladder cannot answer, is refused before any credential is read or password checked, and is not counted on the ladder
A locked-out attempt is refused before any password is checked, the right one too, and leaves no count behind: one that lost the race to arm the lockout gives back what it counted
Every refused credential, the lockout, the ladder's refusals and a failure inside the handler answer only once 500 ms have passed since the request arrived, so the time of the answer does not tell the causes apart
An address with no account still costs one Argon2id verification, against the decoy hash
A refresh token reaches the caller only once its hash is stored

Exact rules

Id	Never
`no-tokens-for-a-refused-account`	`(refreshTokenStored or state == 'tokens_issued') and (noCredential or wrongPassword or userDisabled or unverifiedUnderTheGate)`
`attempt-counted-before-the-password`	`state == 'checkingPassword' and not attemptCounted`
`attempt-reserved-on-the-ladder-before-the-password`	`state == 'checkingPassword' and not attemptReserved`
`ladder-refusals-check-no-password`	`state in ['too_many_requests.ladder_wait', 'service_unavailable.ladder'] and (attemptReserved or decoyVerified)`
`locked-out-checks-no-password`	`state == 'too_many_requests.locked_out' and attemptCounted`
`every-refused-credential-waits-the-floor`	`state in ['too_many_requests.locked_out', 'too_many_requests.ladder_wait', 'service_unavailable.ladder', 'invalid_credentials.unknown_identifier', 'invalid_credentials.wrong_password', 'invalid_credentials.email_not_verified', 'invalid_credentials.account_disabled', 'server_error.store'] and not floorWaited`
`unknown-address-verifies-the-decoy`	`state == 'invalid_credentials.unknown_identifier' and not decoyVerified`
`tokens-issued-means-stored`	`state == 'tokens_issued' and not refreshTokenStored`

Reference

All transitions (30)

From	Event	Guard	To	Effects	Taken
`idle`	`LOGIN`		`resolvingRealm`		yes
`resolvingRealm`	`rule 1`	`hostUnknown`	`misdirected_request.host`		yes
`resolvingRealm`	`rule 2`		`rateLimiting`		yes
`rateLimiting`	`rule 1`	`rateLimited`	`too_many_requests.login_limit`		yes
`rateLimiting`	`rule 2`		`validatingBody`		yes
`validatingBody`	`rule 1`	`inputInvalid`	`validation_error.body`		yes
`validatingBody`	`rule 2`		`checkingLockout`		yes
`checkingLockout`	`rule 1`	`lockedOut`	`too_many_requests.locked_out`	`waitFloor`	yes
`checkingLockout`	`rule 2`		`reservingAttempt`	`countAttempt`	yes
`reservingAttempt`	`rule 1`	`ladderUnavailable`	`service_unavailable.ladder`	`waitFloor`	yes
`reservingAttempt`	`rule 2`	`ladderWait`	`too_many_requests.ladder_wait`	`waitFloor`	yes
`reservingAttempt`	`rule 3`		`checkingPassword`	`reserveAttempt`	yes
`checkingPassword`	`DONE`	`noCredential`	`invalid_credentials.unknown_identifier`	`verifyDecoy` `waitFloor`	yes
`checkingPassword`	`DONE`	`wrongPassword`	`invalid_credentials.wrong_password`	`waitFloor`	yes
`checkingPassword`	`DONE`		`checkingVerified`		yes
`checkingPassword`	`FAIL.server`		`server_error.store`	`waitFloor`	yes
`checkingVerified`	`rule 1`	`unverifiedUnderTheGate`	`invalid_credentials.email_not_verified`	`waitFloor`	yes
`checkingVerified`	`rule 2`		`findingUser`		yes
`findingUser`	`DONE`	`userDisabled`	`invalid_credentials.account_disabled`	`waitFloor`	yes
`findingUser`	`DONE`		`issuingAccessToken`		yes
`findingUser`	`FAIL.server`		`server_error.store`	`waitFloor`	yes
`issuingAccessToken`	`DONE`		`storingRefreshToken`		yes
`issuingAccessToken`	`FAIL.server`		`server_error.store`	`waitFloor`	yes
`storingRefreshToken`	`DONE`		`recordingSignIn`	`storeRefreshToken`	yes
`storingRefreshToken`	`FAIL.server`		`server_error.store`	`waitFloor`	yes
`recordingSignIn`	`DONE`		`updatingLastLogin`		yes
`recordingSignIn`	`FAIL.server`		`server_error.store`	`waitFloor`	yes
`updatingLastLogin`	`DONE`		`clearingFailures`		yes
`updatingLastLogin`	`FAIL.server`		`server_error.store`	`waitFloor`	yes
`clearingFailures`	`rule 1`		`tokens_issued`		yes