Skip to main content

​
Airlock Cross-Subdomain Auth: Zero-Config Integration for New Services

​
The Core Insight

Adding auth to a new *.devarno.cloud service requires zero OIDC client registration, zero token exchange, and zero callback URL configuration. Airlock’s BetterAuth cross-subdomain cookies (Domain=.devarno.cloud) mean any new service just needs to forward the cookie header to airlock.devarno.cloud/api/auth/get-session and validate the response. The session is already there.

​
The Pattern

HUBBLE’s auth integration is a 3-file pattern:
  1. Middleware (middleware.ts): Forward cookies to Airlock’s get-session endpoint. On success, inject user headers (x-hubble-user-id, x-hubble-user-email, x-hubble-user-tier). On failure, redirect to Airlock sign-in with callback URL.
  2. Auth client (lib/auth.ts): BetterAuth client pointing at Airlock for client-side session reads. Tier derivation from user identity (username/email → full/observer/collaborator).
  3. Auth provider (providers/auth-provider.tsx): React context wrapping authClient.getSession() for component-level access to user + tier.
No NextAuth, no separate OAuth flow, no token storage. The entire auth surface is session validation against Airlock.

​
Why Not OIDC?

OIDC would require registering HUBBLE as a client in Airlock, handling authorization code flow, managing token refresh, and storing tokens. For services within the .devarno.cloud subdomain, the shared cookie is simpler, faster, and eliminates an entire class of token-management bugs. OIDC remains available for external consumers outside the subdomain.

​
Actionable Takeaway

For any new *.devarno.cloud service: skip OIDC, forward the cookie to Airlock’s get-session, and derive access tiers from the user response. Three files, no registration, no tokens. Reserve OIDC for services outside the .devarno.cloud domain boundary.