Back to guides

Self-hosted authentication without building auth from scratch


Self-hosted authentication means the application controls the runtime and auth data instead of sending every identity operation to a hosted vendor. It does not require writing password hashing, tokens, sessions, and rate limits from scratch. A library such as Own Auth can run inside the existing backend and store its records in the application's Postgres database.

Three authentication operating models

  • Hosted identity service: a vendor runs the auth backend and stores or controls the identity records.
  • Separate self-hosted auth server: the team deploys and operates another network service beside the application.
  • Embedded server library: the application backend calls auth code directly and uses its own database.

Own Auth uses the embedded library model. There is no separate Own Auth user service to deploy. The optional Own Auth Delivery service sends authentication emails, but it does not create users, verify tokens, or create sessions.

What the auth library must own

  • Password hashing and safe credential errors
  • Single-use expiring token creation and verification
  • Session creation, expiry, revocation, and cleanup
  • Rate limits around sensitive authentication actions
  • Account linking and verified identity rules
  • Audit events for security-sensitive changes

Application routes still validate HTTP shape, set cookies, render screens, and authorize product data. They should not duplicate password policy, token verification, or session logic that belongs to the auth engine.

Operational responsibilities do not disappear

Running auth in the application means the team owns database availability, secrets, migrations, backups, monitoring, abuse controls, and incident response. Use managed Postgres and managed email delivery if they reduce operational risk, but keep the trust boundaries explicit.

Suitable applications

  • The product needs direct ownership of user and session data.
  • Auth flows must match a custom application interface.
  • The team already operates a trusted backend and Postgres.
  • Vendor-specific SDKs or hosted UI would constrain the architecture.
  • The team accepts responsibility for secure deployment and database operations.

Hosted identity reduces operational responsibility. An embedded library preserves database and application control but requires the team to operate the backend securely.