TotalAuth: One Identity Plane, Many Deliberate Boundaries

Share sign-in, keep decisions local

A calendar, a game, and an operations tool can share sign-in while keeping their own data and permissions. TotalAuth separates those jobs: the identity provider establishes who or what is calling, and each application decides what that caller can do.

Concept illustration for total-auth; not a product screenshot.

Different lifecycles, deliberate contracts

TotalAuth automates several distinct identity lifecycles rather than forcing every caller through one generic client. Browser applications receive public OIDC clients with exact HTTPS origins and PKCE. Machine workloads receive their own scoped principals. API resources can receive an audience and roles without receiving any credential at all. Human onboarding follows a separate, bounded approval path.

Identity and application authority

A shared identity establishes the caller. Each application remains responsible for its own resource decisions.

flowchart TD
    Caller[Person or workload] --> Identity[Identity provider]
    Identity --> Contract[Application-specific identity contract]
    Contract --> App[Application validates caller]
    App --> Decision[Local resource decision]

Bind declarations to reviewed delivery

Repositories opt in through committed manifests, and protected gateways bind those declarations to reviewed platform delivery mappings. The resulting handoffs expose the non-secret contract an application needs—issuer, audience, role claim, scopes, and identity references—while encrypted runtime material travels only to the mapped consumer.

The same philosophy extends to collaboration. Automated Forgejo access uses a short-lived assertion exchange rather than a long-lived personal access token, and workstation requests pass through a constrained adapter and an operation allow-list. TotalAuth turns identity onboarding from an assortment of privileged manual steps into a reviewable system with explicit edges.