System overview
Packages, layers, Cloudflare bindings, and the authentication flows that make up eetr-auth.
eetr-auth is a Cloudflare-native OAuth 2.1 + OpenID Connect authorization server packaged as
an npm monorepo. It is designed to run entirely on Cloudflare's edge platform with no traditional
server infrastructure.
Monorepo packages
apps/auth
The core OAuth 2.1 / OIDC server. Next.js 16 (App Router) + React 19, deployed via OpenNext to Cloudflare Workers. D1 for persistence, R2 for object storage, NextAuth.js v5 for admin sessions.
apps/argon-hasher
An internal-only Rust/Wasm Worker implementing Argon2id hashing, reachable only via service binding. Keeps expensive hashing off the auth isolate's CPU budget.
packages/eetr-auth-client
A published TypeScript library for consuming the server — discovery, token management,
introspection, and JWT validation. jose is its only runtime dependency.
Layered internal architecture
apps/auth keeps a strict separation between entry points, business logic, and persistence:
src/
├── app/ # Next.js App Router
│ ├── api/ # REST API routes (OAuth, users, admin)
│ └── (auth|admin)/ # UI pages (login, dashboard)
└── lib/
├── services/ # Business logic
├── repositories/ # Data access layer (D1 implementations)
├── auth/ # Auth utilities (JWT, HMAC, cookies)
├── config/ # Runtime config readers
├── context/ # Dependency injection registry
├── crypto/ # Cryptographic primitives
└── db/ # D1 connection helperRoutes and server actions only wire context and call services; services hold all business logic and depend on repositories; repositories do persistence only. The full rules — including how to add new code — are in Layer conventions.
Cloudflare bindings
| Binding | Type | Purpose |
|---|---|---|
DB | D1 Database | All persistent data (users, tokens, clients, etc.) |
AUTH_ASSETS | R2 Bucket | User avatars, site logo, JWKS JSON |
IMAGES | Images API | Cloudflare image optimization |
ASSETS | Static Assets | OpenNext-compiled static files |
WORKER_SELF_REFERENCE | Service Binding | Internal self-calls for routing/caching |
ARGON_HASHER | Service Binding | Password hash/verify operations |
Authentication flows
Authorization Code + PKCE (S256)
Token refresh (rotation)
Client credentials
Infrastructure & deployment order
Terraform provisions D1 + R2 and emits outputs that are rendered into the gitignored
wrangler.generated.jsonc. Deployment always follows this order:
argon-hasher must be deployed before apps/auth, because the auth Worker reaches it through
the ARGON_HASHER service binding at startup.