OxideAuth — Decentralized Identity & Access Management Platform

Overview​

OxideAuth (codename: Ironstone) is a decentralized, multi-tenant Identity and Access Management platform built in Rust. It offloads the full complexity of authentication and authorization from individual services — allowing developers to focus on business logic rather than identity plumbing.

Unlike the previous Codativity-specific version, this is a general-purpose, self-contained IAM platform. Any organization can run it as their central auth service. It supports workspace-level multi-tenancy with complete data isolation, fine-grained RBAC with roles and permissions, stateless JWT tokens with a Redis-backed blacklist pattern, and a composable architecture of services, stores, and caches.

The codebase lives entirely in this repository — Rust source, database migrations, documentation, and Docker infrastructure all in one place.

Key Features​

• Multi-tenant workspaces — Three workspace types (GLOBAL, REGISTRY, STANDARD) with fully isolated data, roles, permissions, and configurations per tenant
• Fine-grained RBAC — Roles bundle permissions; memberships link accounts to workspaces and projects; policies constrain access contextually without granting new abilities
• Stateless JWT auth with blacklist — Tokens are validated by cryptographic signature with a fast Redis cache check for revoked tokens; database fallback ensures durability
• Polymorphic token system — Unified token table supports BLACKLIST (revoked JWTs), REFRESH (session renewal), API_KEY (machine-to-machine), and RESET_PASSWORD tokens
• Workspace-scoped login — Credentials (password, OAuth, SSO, API key) are scoped per workspace; login resolves the correct membership context for the JWT
• Embedded background worker — Tokio-spawned janitor task auto-prunes expired tokens from the database on a schedule
• AWS S3 & SES integration — Object storage for user uploads and transactional email delivery via AWS services

Architecture​

A layered, service-oriented Rust application backed by PostgreSQL and Redis:

All layers share an Arc<StoreManager> and Arc<CacheManager> via the ServiceFactory, with request-scoped services instantiated per-request to prevent state leakage.

Architecture Diagram​

[HTTP Request]
    ↓
Axum Handler (web/handlers/*.rs)
    ↓
CoreCtx Middleware → builds per-request context (membership, roles, permissions)
    ↓
Service Layer (core/services/*.rs) → business logic, hydration, authorization
    ↓
Store Layer (store/stores/*.rs) → sea-query + SQLx
    ↓
PostgreSQL / Redis

Data Model​

Core Entities​

RBAC Flow​

Account → Membership → Role → Permissions

A user's effective permissions are the union of all permissions granted by all roles assigned to their membership(s). Policies can only constrain — they never grant new abilities.

Workspace Types​

Token Architecture​

Stateless JWT with Blacklist​

The system uses stateless JWTs — the server trusts the token's cryptographic signature without a database lookup. To support logout and revocation, a blacklist pattern is used over a whitelist:

Every request: Signature check → Redis cache check (bl:{jti}) → Database fallback (if cache miss).

Token Types​

API Design​

All endpoints use HTTP POST with the action in the URL path (JSON-RPC style). This keeps sensitive data (tokens, credentials) in the request body and intentionally disables HTTP caching — a security requirement for real-time authorization.

Projects follow the same pattern at /projects/create, /projects/describe, etc.

Tech Stack​

Default RBAC​

When a new workspace is created, four default roles are seeded:

Permissions follow a resource:action convention (e.g., projects:create, members:invite, billing:manage). Over 20 default permissions are seeded across workspace, members, projects, roles, billing, and audit-log resources.

Development​

Prerequisites​

• Rust (latest stable)
• PostgreSQL 16
• Redis 7
• Docker & Docker Compose (optional, for infra)

Quick Start​

# Start PostgreSQL and Redis
docker compose up -d postgres redis

# Copy and fill in the config
cp ironstone/.cargo/config.example.toml ironstone/.cargo/config.toml

# Run dev migrations
cargo db-dev-run

# Start the dev server
cargo run --bin ironstone

The API starts on http://localhost:8000 by default. Health check at GET /health-check.

Project Structure​

oxideauth/
├── ironstone/              # Main Rust application
│   ├── src/
│   │   ├── main.rs         # Entrypoint, tokio runtime
│   │   ├── app.rs          # AppState, env config, init
│   │   ├── config.rs       # Config from environment
│   │   ├── web/            # Axum handlers, router, middleware, DTOs
│   │   ├── core/           # Services, models, traits, context, worker
│   │   ├── store/          # StoreManager, entities, stores, query traits
│   │   ├── cache/          # CacheManager, Redis, cache stores
│   │   ├── macros/         # Custom derive macros (filters)
│   │   ├── dev/            # Dev environment fixtures & seeding
│   │   └── utils/          # Shared utilities
│   └── sql/
│       ├── migrations/dev/ # Development schema migrations
│       ├── migrations/prod/# Production schema migrations
│       └── fixtures/       # Bootstrap data (accounts, workspaces, roles, etc.)
├── ironstone-macros/       # Procedural macro crate
├── docs/                   # Architecture & design documentation (24 docs)
├── docker-compose.yaml     # PostgreSQL + Redis infra
└── Dockerfile.dev          # Dev container with cargo-watch