Self-host users, upstream identity federation, sessions, and tokens for related applications—without turning your product model into OAuth client plumbing.
Pre-alpha implementation
OwlAuth now implements one complete strict-OIDC Project Auth and session journey, isolated Runtime and Control APIs, PostgreSQL authority, embedded Hosted Authentication and Management Console surfaces, signing and configuration-secret stores, and TypeScript/Python/Rust protocol SDKs. It remains pre-alpha rather than production-supported. Passwordless email, managed provider synchronization, projection webhooks, SCIM/bulk directory, and remote MCP remain deferred.
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.
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.