Application deployment checklist

Use the items that apply to your integration. For explanations, see deploy your application. If Udibo hosts sign-in, review your client/BFF/API boundaries; the app-owned identity and issuer sections apply only when you host those flows.

Configuration and secrets

• Issuer, app origin, and exact callbacks are configured for this environment.

• Production credentials and data are separate from local and preview environments.

• No demo credentials, fallback secrets, or local test-provider endpoints remain.

• Client secrets, cookie keys, and signing keys stay on the backend and out of logs.

Browser, BFF, and API

• HTTPS cookie and CSRF defaults are enabled; custom browser requests send the CSRF header.

• The BFF's sessionStore and authRequestStorage work on every instance that serves the app: encrypted-cookie stores with secrets every instance shares, a separate one per store instance and per app, or stores over shared storage. MemorySessionStore and MemoryAuthRequestStorageFactory appear only in single-process, test and local configurations. If sign-out must revoke a stolen session cookie, use a shared SessionStore: EncryptedCookieSessionStore keeps a copied cookie valid until its maxAgeMs. See choosing the BFF's stores.

• Login state and PKCE verifier survive callbacks to a different app instance.

• A server-side DirectClient that signs users in or runs the device flow has an authRequestStorage (on the client or passed per call) and a refreshTokenStorage that every instance can read and that outlives a restart. MemoryAuthRequestStorage and MemoryRefreshTokenStorage appear only in single-process, test and local configurations. See DirectClient storage outside a browser.

• Pending sign-ins are bounded. A multi-instance or internet-facing BFF uses EncryptedCookieAuthRequestStorage, or shared storage with its own cap. The login route has a rate limit, and maxReturnToLength (default 2048) suits your return paths. See pending sign-in limits.

• Behind a TLS-terminating proxy, the app origin comes from configuration (redirectUri or resolveOrigin), and SSO logout sends the registered https post-logout redirect URI.

• Sessions expire consistently and stateful updates reject revoked or missing sessions.

• Local logout, upstream revocation, and optional SSO logout have each been tested.

• Session listings expose non-secret row IDs, never cookie credentials or token material.

• The API validates issuer, token type, applicable audience, and required scopes.

• Record-level authorization runs on the server, independently of React rendering guards.

• The app handles invalid tokens separately from issuer outages.

• Any proxy has a fixed trusted target; trusted-forwarded-header policy matches deployment.

• Every route that reads its own body has a request-size limit in the framework or reverse proxy, mounted ahead of protect(). The package caps only its own reads: maxTokenBodyBytes for the form-body access_token search and maxBodyBytes for honoIdentityRoutes.

If your app hosts an authorization server

• PKCE, state, and confidential-client authentication are enabled.

• Registered callbacks and allowed grants are restricted to the app's actual clients.

• Codes and refresh-token rotation claims are consumed atomically.

• The token store implements rotate, claiming a refresh token and saving its successor in one step that revokeFamily cannot interleave with, and passes runTokenRotationContractTests with its barrier wired.

• The token store implements exchangeCode, claiming a code and saving its token in one step, and passes runCodeExchangeContractTests with its barrier wired; its revokeCode revokes nothing for a client other than the code's own, or for a codeVerifierHash other than the one saved with the code's tokens.

• Without rotate, family revocation, from a replay or from revoking a rotated-out token, cannot be undone by a concurrent token save: revokeFamily records the family and save stores any later member of it already revoked.

• getRevokedRefreshToken returns every tombstone; a replay grace comes from replayGraceSeconds, judged on the store's clock by isWithinReplayGrace when the store stamps rotatedAt itself, not from hiding recent tombstones.

• Client-credentials tokens represent the client or its service account, not its human owner.

• Consent and scope policy match the clients you allow.

• maxBodyBytes stays at its 64 KiB default unless your clients send larger token, revocation, introspection or end-session bodies.

• Persisted signing keys survive deployment; rotation and JWT revocation limits are understood.

• The deprecated password grant is not enabled for new integrations.

If your app hosts login

• The full password credential, including params, is persisted.

• Automatic rehash/import uses atomic replaceCredential; a failed comparison writes nothing, and the sign-in proceeds only if the password re-verifies against the credential now stored.

• Rate limiting and lockout are explicitly configured and enforced.

• RateLimiter and AccountLockout use a RateLimitStore and a LockoutStore that every instance shares, with an atomic increment. MemoryRateLimitStore and MemoryLockoutStore appear only in single-process, test and local configurations. See rate limit and lockout storage.

• Email requests and OTP/MFA attempts are throttled; concurrent resend policy is explicit.

• OTP consumption and recovery-code consumption permit one successful caller.

• Password reset invalidates sessions; optional sign-in-link/OTP cleanup is implemented and monitored.

• Email verification is conditional on the current address matching the address proved.

• MFA enrollment, disable, recovery, and verification routes authenticate and authorize the user.

• A completed first factor creates pending MFA state, not a full application session.

• External identities are keyed by trusted provider and subject; linking requires account proof.

• Apple callbacks accept form POSTs and use the required Secure, SameSite=None transient cookie.

Verification and maintenance

• Contract suites pass against the actual persistent adapters.

• Tests cover concurrent redemption, callback mismatch, expired/revoked sessions, and insufficient scope.

• Backups, retention, and recovery are exercised without restoring revoked access unintentionally.

• Audit records omit credentials; delivery and persistence failures are observable.

• The known limitations have been reviewed for enabled features.