← Back to blog

Production authentication checklist

Verify the following against the production configuration: database migrations, secret handling, authentication responses, session revocation, recovery, organisation authorization, message delivery, and audit records.

Database, migrations, and secrets

Confirm DATABASE_URL points to the intended production Postgres database and npx own-auth status reports Database: connected and Status: current. Restore a recent backup into an isolated database and confirm that the Own Auth tables and migration records are present.

Every application instance must use the same OWN_AUTH_TOKEN_PEPPER. Changing it invalidates outstanding auth tokens, sessions, phone codes, invitations, and API keys.

Credentials and public authentication responses

The application owns every public HTTP route that calls Own Auth. Validate the request shape, derive the actor from a verified credential, and map package errors to narrow public responses. Stack traces, SQL messages, provider responses, internal password-policy detail, and rate-limit bucket state must remain server-side.

  • Return one sign-in failure response for an unknown email, wrong password, disabled account, or provider mismatch.
  • Return the same request response for known and unknown accounts on magic-link, verification, password-reset, and phone-code send routes.
  • Exercise Own Auth's operation-specific limits for password checks, token requests, code verification, invitation creation, and API-key creation.
  • Test malformed requests, token replay, token expiry, disabled users, and concurrent submissions.

Keep account and network limits independent. A per-account counter addresses a distributed attack on one user, while a per-network counter addresses one source testing many accounts. A single composite key such as IP + email gives every new pair another allowance and does not enforce either ceiling.

Sessions, cookies, and revocation

Verify the session on every protected entry point with auth.getCurrentSession or auth.requireCurrentSession, then derive the user ID from the result. Never accept actorUserId, organisation membership, or a role from an untrusted request body.

  • For same-origin web applications, use a session cookie with HttpOnly, Secure, an explicit SameSite policy, Path=/, and an expiry aligned with the server record.
  • Apply and test a CSRF defense on every state-changing route that relies on an ambient cookie.
  • Configure both absolute and idle session limits. auth.getCurrentSession may extend idle expiry, but never absolute expiry.
  • Revoke the database session before clearing the client credential during sign-out.
  • Test individual revocation, account-wide revocation, absolute expiry, idle expiry, and a disabled user with an existing token.
  • Require fresh authentication for high-risk actions such as credential changes, sensitive exports, or destructive administration.

Links, recovery, and destination control

Magic links, password resets, verification links, and invitations are bearer credentials until Own Auth consumes them. Build web destinations from configured application origins, not an untrusted request host. Exclude the complete URL and token from access logs, analytics, support tools, referrers, and error metadata.

  • Configure redirectAllowlist only for flows that accept a caller-selected destination, and list only application-controlled origins or deep links.
  • Confirm each token fails after successful use and after expiry. Test concurrent submissions separately; Own Auth 0.3.6 built-in stores should admit one successful consumer.
  • Confirm password reset revokes every existing session for the account.
  • Apply a restrictive referrer policy and disable third-party analytics on credential-bearing verification pages.

Organisations and API authorization

Test organisation authorization with two users and two organisations. Each protected application query must use the organisation from a verified membership or API-key owner. Verifying a session and then loading a resource by a client-supplied global ID can still expose another tenant's data.

  • Exercise every organisation mutation as owner, administrator, member, non-member, and disabled user.
  • Own Auth 0.3.6 prevents non-owners from assigning its built-in owner role through auth.inviteMember. Validate application-defined role assignment rules before calling the method.
  • Test removal or demotion of the last owner and verify the organisation retains an authorised recovery principal.
  • Scope API keys to the minimum operations required and show the raw key only at creation.
  • Verify revoked API keys fail immediately and that logs contain only safe key metadata such as the visible prefix.
  • Keep product-resource authorization in the application. Own Auth enforces permissions for its own organisation operations, not for application tables.

Email and SMS delivery

The own-auth package creates and verifies auth tokens. The configured email or SMS provider transports them.

  • Run an end-to-end test for every enabled message type from request through verification.
  • Verify send failures do not reveal whether the recipient has an account and do not return provider internals.
  • Never log auth URLs, magic-link tokens, reset tokens, SMS codes, or provider credentials.

Audit, monitoring, and incident actions

Own Auth audit events cover documented event types, including completed changes and selected started or failed flows. With an OpenTelemetry SDK configured, operation errors appear in traces and rate-limit denials produce a package metric. Add application or edge signals for product authorization and other paths the package does not own. Correlate these records with safe user, organisation, and credential-record identifiers, never with raw bearer values.

  • Confirm audit events identify the actor, target, organisation, and request context when those values are available.
  • Redact request bodies and query strings on auth routes at the application, proxy, and observability layers.
  • Exercise disabling a user, revoking one session, revoking all sessions, revoking one API key, and removing one organisation member.
  • Run auth.cleanupAuditLogs against an explicit retention cutoff in a non-production verification environment before scheduling production cleanup.