AuthGeek

Systems, Security, & Architecture

The Architecture of AuthGeek

Why we rely on API-SIX and OPA to decouple business rules from frontend code, drawing parallels to managing physical battery storage.

Designing the AuthGeek Infrastructure

Building a robust authentication gateway requires the exact same mindset as building an off-grid solar array: zero trust, isolation, and deterministic routing.

In this post, we’ll break down the architecture that powers the live demo at demo.authgeek.com, specifically focusing on how we decouple our identity provider (Keycloak) from edge routing (Apache API-SIX).

The Request Flow

Before jumping into the configuration, let’s visualize the exact flow of an unauthenticated user attempting to access a protected billing route.

sequenceDiagram
    participant User as End User
    participant Gateway as API-SIX (Edge)
    participant OPA as Open Policy Agent
    participant IdP as Keycloak (OAuth2)
    participant App as Billing Service

    User->>Gateway: GET /api/billing
    Gateway->>OPA: Check Policy: Is context valid?
    OPA-->>Gateway: Deny (No Token)
    Gateway-->>User: 302 Redirect to IdP

    User->>IdP: Authenticate
    IdP-->>User: Issue JWT

    User->>Gateway: GET /api/billing (with JWT)
    Gateway->>Gateway: Validate JWT Signature
    Gateway->>OPA: Check Policy: User Role = Admin?
    OPA-->>Gateway: Allow

    Gateway->>App: Proxy Request /w Headers
    App-->>User: 200 OK (Billing Data)

Why OPA?

You might ask why we introduce Open Policy Agent when API-SIX already has routing rules and Keycloak has RBAC (Role-Based Access Control).

The answer lies in complexity management.

If you code business rules directly into your application (e.g., if (user.role == 'admin')), your microservices become tightly coupled to your identity provider’s schema. If you code them all into the Gateway, the Gateway’s configuration becomes a massive, unreadable monolith.

OPA acts as the “BMS” (Battery Management System). It sits outside the primary flow of power (the HTTP request) but makes the deterministic decisions on whether the circuit should remain open or closed based on real-time constraints.

[!NOTE] This site itself is built using Astro and deployed on Cloudflare Pages, maintaining near-zero maintenance overhead while keeping an architectural separation from the vulnerable demo environment.

Stay secure, and stay curious.