The OMI spec is under heavy development, and every piece of it is subject to change. We are documenting the core primitives for sovereign application lifecycles. Join us in defining the v1.0 draft.
Documentation
Core Services
Auth Provider

Auth Provider

In the OMI architecture, the Auth Provider is the “Bouncer” of the swarm. Its job is to verify who a user is and provide them with a cryptographic “hall pass” (token) that every other service in the swarm will respect.

By delegating authentication to a Core Service, Domain Services (like your CMS or CRM) never have to see a password, handle a “Forgot Password” email, or manage a sessions table. They simply trust the Auth Provider.

The Core Responsibility

The Auth Provider sits between the User and the Swarm. It performs three critical functions:

  1. Identity Verification: Validates user credentials (passwords, Passkeys, OAuth, etc.).
  2. Token Issuance: Generates a Signed OMI Token that contains the user’s identity and permissions.
  3. Trust Translation: It fetches the Service Public Keys from the App Registry to ensure it only issues tokens for services that are actually part of your authorized swarm.

Why this is different from “Standard Auth”

In traditional development, you’re stuck in the CRUD State of Mind, rebuilding users tables and /login endpoints for every project. In OMI, the Auth Provider is Pluggable Architecture.

  1. Zero-Knowledge Domain Services Your Domain Services are “blind” to the user’s sensitive credentials. They receive a request, check the signature against the Auth Provider’s Public Key, and proceed. If the signature is valid, the user is who they say they are.

  2. Universal Session Management Since the Auth Provider is a Core Service, “Logging Out” of one service logs you out of the entire swarm. The invalidation signal is broadcasted via the Registry, and every service drops the session simultaneously.

  3. Identity Sovereignty As a developer, you choose your Auth Provider. If you want a provider that focuses on Privacy (Zero-Knowledge) or one that uses Biometric Passkeys, you simply swap the URL in your App Registry. Your Domain Services don’t need a single line of code changed to support the new login method.

The Authentication Flow

StepActionDescription
1. ChallengeUser → AuthUser provides credentials to the Auth Provider.
2. ValidationAuth → RegistryAuth Provider checks the Registry to confirm it is the Trusted Anchor for this AppID.
3. IssuanceAuth → UserAuth signs a token using its Private Key.
4. AccessUser → DomainUser sends the token to the CMS/Service.
5. VerificationDomain (Local)The CMS verifies the token using the Auth Provider’s Public Key (cached from the Registry).

Security Policy: The “Trust Chain”

For an Auth Provider to be valid in an OMI swarm, its own Public Key must be registered in the App Registry and signed by the Developer’s Master Private Key.

This ensures that an attacker can’t just set up their own “Fake Auth Provider” and start issuing tokens to your services. The Domain Service will see that the Registry doesn’t recognize that Auth Provider and will reject the request.

The “Rage” Benefit: You stop writing bcrypt.compare() and express-session boilerplate. You focus on your data; the Auth Provider focuses on the gates.
App RegistryOperational Services