[Bccorb]

Closes #434. Each claim below was checked against the code on main (0.19.1).

Security posture (docs/security-posture.md)

• Absolute session lifetime: the doc called it open (Refresh rotation resets the absolute session lifetime, so there is no absolute cap #185), but it shipped. It now describes how it works: expiresAt is chainStartedAt plus refresh_token_ttl, and rotation does not extend it. It also covers session_idle_ttl and the absolute_lifetime_reached and idle_timeout refusals.
• New "Account lockout" section, from lockoutPolicyService.ts and authFailureCounter.ts as of fix(lockout): keep passkey sign-in out of lockout and enforce lockoutSeconds #448:
  • The lock starts when maxFailures land inside one windowSeconds window, and lasts lockoutSeconds from there. It is not a rolling count.
  • Which failure types count (LOCKOUT_FAILURE_TYPES), and that passkey assertions do not.
  • Passkey sign-in is not subject to lockout: a locked account with a passkey continues with loginMethods: ["passkey"].
  • Why passkeys are spared (GHSA-66gq-4pwg-33jq), and that the counter is in Postgres and fails closed.
• Enumeration section: the "what is still observable" lockout bullet is updated to match.
• Audience: already correct after fix(auth): verify aud on access tokens, require typ, and require exp on service tokens #443; checked against sessionService.ts (issuer, audience, typ).
• Refresh tokens: the posture doc already says they are opaque.

Refresh tokens described as signed (docs/production-operations.md)

Key rotation step 3 said to wait refresh_token_ttl so that "no token signed by the outgoing key" is still live. Refresh tokens are opaque and not signed. The wait is access_token_ttl, since access tokens are the longest-lived signed tokens.

Per-instance limits (docs/production-operations.md)

A new section, "Running More Than One Instance". It lists what is shared through Postgres, and what is held per process along with its effect with N instances:

• the rate limit and slow-down counters (in-memory stores)
• the five-minute system_config cache (a write clears only the instance that served it)
• the OAuth state replay cache
• the audit-degraded health flag

Owner admin grant, made to match src/lib/ownerAdmin.ts

The code grants one role: admin:write if available, else admin. The CLI smoke runs confirm it; the owner's roles were user,betaUser,admin:write.

• The README said both roles.
• configuration.md said admin.
• The code comment said both signup paths prove the address "before the account is created". For email OTP that is not so. /registration/register creates the account with the role first, and an unverified account cannot sign in. All three now say that.

Smaller fixes

• docs/admin-operations.md: GET /roles is GET /system-config/roles.
• src/controllers/systemConfig.ts: the public config comment claimed it survives a tainted config. getSystemConfig throws on a config that fails schema validation, so it does not. Comment only, no behaviour change.
• docs/fido-conformance.md: /conformance/* is deliberately absent from the committed openapi.json and adapter-manifest.json, which are built with the flag unset.
• CLAUDE.md: the coverage thresholds now read 98/98/95/98, matching vitest.config.
• ci.yml: dropped the stale sequelize audit comment. npm audit --omit=dev shows no sequelize advisories any more.

Checks

npm run typecheck, npm run lint and npm run format:check pass, and npm run test:run passes 1876 tests (1 todo). CI's audit step will fail until #456 (follow-redirects) merges. That failure is not caused by this PR.