OwlAuth

Appearance

OwlAuthProject-scoped authentication infrastructure

Self-host users, upstream identity federation, sessions, and tokens for related applications—without turning your product model into OAuth client plumbing.

Understand OwlAuth
Develop OwlAuth
View on GitHub

Project isolation

Each Project owns its users, linked identities, provider configuration, sessions, refresh families, token namespace, and signing keys.

Application sharing

Web, mobile, native, and server Applications inside one Project share its user directory and Project token trust boundary.

Upstream federation and managed profiles

OwlAuth uses OAuth or OIDC only with upstream identity providers and may retain a server-only least-scope renewable credential for bounded profile synchronization.

Passwordless email

Projects can host OTP and magic-link authentication through Project-selected SMTP, with one-use proofs and no silent email linking.

Application user synchronization

Applications receive bounded revisioned user projections and optional signed durable webhooks only for users already bound to them.

Auth and Control separation

Auth hosts isolated Runtime and Server API routers, while privileged administration uses an independent Control listener over the same application and domain core.

Hosted web surfaces

Runtime provides hosted end-user authentication pages, while Control provides an API-key-driven Management Console in the same server artifact.

First-party SDK design

TypeScript, Python, and Rust clients target the Runtime Project Auth contract, including PKCE handoff and coordinated refresh behavior.

Self-hosted authority

PostgreSQL is the durable authority, and private signing or data-protection keys stay behind provider interfaces.

Beta

OwlAuth is pre-1.0. APIs and deployment requirements may change; review the deployment and security guides before operating it.

The product model ​

A single OwlAuth Deployment is one administrative trust domain. It can contain many isolated Projects. A Project represents one product or related application family, and contains one or more Applications.

Applications in one Project share users and Project token trust. Applications that require isolated users or token audiences belong in separate Projects. A person using the same GitHub identity in two Projects maps to two independent Project users.

OwlAuth owns authentication, identity linking, Project sessions, and Project token claims. Your application backend still owns business authorization—organizations, memberships, billing roles, document access, and other product policy.

OAuth/OIDC is upstream only ​

OwlAuth can broker sign-in to a Project's configured upstream provider or verify a first-party email OTP/magic link, then returns an OwlAuth Project user projection and session credentials through the same one-use, PKCE-bound handoff. Downstream Applications consume the Project Auth API; they do not register general OAuth grants or receive OAuth/OIDC provider tokens from OwlAuth.

A Project access token is an OwlAuth application-session JWT. It is not an upstream provider token and it does not make OwlAuth a general-purpose OAuth authorization server.

  • Deployment — released artifacts, production configuration, TLS ingress, PostgreSQL, scaling, probes, upgrades, and tested recovery.
  • Architecture — Projects, Applications, authentication flow, logical planes, storage, and deployment modes.
  • Getting started — build, validate, and inspect the current Beta implementation.
  • SDKs — implemented protocol operations and the explicit Application-owned state boundary.
  • Building a SaaS — compose external tenant authorization, managed cells, reconciliation, and billing around self-hosted OwlAuth.
  • CLI and agent integrations — endpoint-discovered CLI boundaries, documentation plugin, and remote HTTP MCP capabilities.
  • Security — target invariants, operational trust boundaries, and vulnerability reporting.

Released under the BSD 3-Clause License.

Copyright © 2026 OwlFoundry