OPA Auth

opa-auth is RAGA's forward-auth middleware service, built on Bun + Express 5. Traefik (reverse proxy) calls this service on every incoming request before forwarding it to the destination service — opa-auth validates the JWT via Redis, asks the OPA Engine for an authorization decision, then forwards the user's identity (role, name, grants, ID) to the downstream service via response headers.

opa-auth is one of three components in RAGA's OPA subsystem:

Component	Role
OPA Config	Runs the OPA server & holds the Rego policy (decision engine)
OPA Data	Syncs role & grant data from User Service into OPA
OPA Auth	The gate in front of Traefik — calls OPA on every request

Tech Stack

Layer	Technology
Runtime	Bun 1
Framework	Express 5 (TypeScript)
Cache	Redis DB 1 (ioredis) — token whitelist validation
Policy Engine	OPA (Open Policy Agent)
Secret Management	Infisical SDK v5

Full environment variable, endpoint, and flow diagram details are on the Technical page.

Flow at a Glance

1. Traefik forwards the request to opa-auth along with x-forwarded-* headers and Authorization.
2. opa-auth checks the token against the Redis whitelist, then asks OPA (POST /v1/data/verify_access) whether the request is allowed.
3. If allowed, opa-auth returns 200 OK with the user's identity headers (X-Auth-User-*), which Traefik reads and forwards to the destination service — the downstream service never needs to decode the JWT itself.
4. If denied, opa-auth returns 401 (invalid/expired token) or 403 (not authorized).

Summary

opa-auth is the single checkpoint every request in the RAGA platform passes through before reaching any service — making it the most critical component in the auth chain: if OPA allows it, the request goes through; if not, it stops here.