Architecture Overview

AuthOS is a pre-1.0 identity platform with authentication, authorization, and user-management implementations for multi-tenant applications. This document describes the current architecture; it is not evidence of protocol conformance, tenant isolation, security assessment, or production readiness. Review the current project status.

System Architecture

AuthOS follows a modular, API-first architecture. Capacity, security, and multi-node behavior depend on the release, database, topology, and operator configuration and do not yet have stable public guarantees.

graph TD
    Client[Client Applications] -->|HTTPS/JSON| LoadBalancer[Load Balancer]
    LoadBalancer --> API[AuthOS API Core]
    
    subgraph "AuthOS Platform"
        API -->|Reads/Writes| DB[(Primary Database)]
        API -->|In-Memory Cache| Moka[Moka Cache]
        API -->|Async Tasks| Tasks[Tokio Background Tasks]
        
        Tasks -->|Process| Email[Email Service]
        Tasks -->|Process| Webhooks[Webhook Dispatcher]
        Tasks -->|Process| Audit[Audit Logger]
    end
    
    subgraph "External Integrations"
        API -->|OAuth/OIDC client| OAuth[Upstream Identity Providers]
        EnterpriseSP[Enterprise Service Providers] -->|SAML AuthnRequest| API
        SCIMClient[SCIM Clients] -->|SCIM provisioning| API
        API -->|Events| SIEM[SIEM Systems]
    end

Core Components

1. AuthOS API (Rust/Axum) The Rust/Axum API core handles authentication requests, policy enforcement, and management operations. Quantitative performance claims require a reproducible benchmark and are not implied by the implementation language.

2. Embedded lite web client Public binaries embed the lightweight setup and end-user journey client. Organization and platform management remain API and SDK surfaces; the public release does not claim a separate full administration console.

3. SDKs & Libraries Published TypeScript, React, Vue, Node, and CLI packages provide integration surfaces. They remain Beta in the pre-1.0 series, and consumers should pin exact versions.

4. Background Tasks Internal asynchronous processors (using Tokio) for handling non-blocking tasks such as sending emails, dispatching webhooks, and processing audit logs.

Data Model

The AuthOS data model is hierarchical and multi-tenant by design.

erDiagram
    Platform ||--|{ Organization : hosts
    Organization ||--|{ Service : contains
    Organization ||--|{ Member : has
    User ||--|{ Member : is
    User ||--|{ Identity : has
    Service ||--|{ ApiKey : uses

    Organization {
        string slug
        string name
        string tier
    }
    
    Service {
        string slug
        string type
        string client_id
    }
    
    User {
        string id
        string email
        string verify_status
    }
    
    Member {
        string role
        string permissions
    }

Key Entities

• Platform: The root level instance of AuthOS.
• Organization (Tenant): The primary container for resources. Represents a customer or team. Authorization paths scope resources by organization; comprehensive public tenant-isolation evidence is still being expanded.
• Service (Application): Represents a specific application or project within an organization. Each service has its own configuration, API keys, and branding.
• User: A global identity entity. Users can be members of multiple organizations with different roles (e.g., “Admin” in Org A, “Viewer” in Org B).
• Membership: The link between a User and an Organization, defining the user’s role and permissions within that specific context.

Security-relevant components

The implementation includes the following security-relevant components. This list is not a security certification or independent assessment:

• Application-level secret encryption: Selected private keys and secrets can be encrypted with AES-GCM before storage; operators remain responsible for key management and database protection.
• Transport boundary: Operators must terminate and enforce TLS at their reverse proxy or ingress. AuthOS does not make every deployment TLS-secure automatically.
• Token-based authentication: JWT signing and verification paths are implemented; exact token types and configuration must be evaluated for the deployed release.
• Authorization: RBAC and relationship-based authorization paths are implemented. Tenant-isolation and abuse-case evidence is still being expanded.

Integration Patterns

1. Hosted Login (Redirect) Redirect users to the AuthOS login page and handle the callback. The safest pattern for a particular application depends on its threat model and configuration.

2. Embedded Login (SDK) Use our frontend SDKs to build custom login forms that communicate directly with the API.

3. Machine-to-Machine (M2M) Services use API keys or the documented enterprise token-exchange profiles. AuthOS does not offer a general OAuth client_credentials grant.

4. Enterprise Federation Use AuthOS as a SAML IdP for service providers, or connect organizations to upstream OAuth/OIDC identity providers. Upstream SAML response processing is currently unsupported and fails closed because signature verification is not implemented.