ZERO TRUST
ENDPOINT
FRAMEWORK
Custom OIDC intermediary binding device certificates to identity provider auth flows — enforcing Zero Trust access to internal services without adding friction to the developer experience.
IDENTITY
WITHOUT
DEVICE
Aurora's Okta SSO authenticated the user — but had no mechanism to verify which device was authenticating, whether it was managed, or whether it met current health requirements. A valid credential on an unmanaged or compromised machine passed the same check as a healthy enrolled device.
Internal CLI tooling compounded the problem. Browser-based OAuth flows are clunky in a terminal context, and most alternatives traded security for convenience. Tokens delivered over the network without transport-layer binding created a portable exfiltration surface.
The goal: authenticate the user and the machine simultaneously, cryptographically, without adding friction to the developer experience.
DEVICE
BIND
AUTH
GAP
BEARER
RISK
- No native Okta mechanism to cryptographically bind a login to a specific managed device certificate
- CLI auth required browser-based OAuth flows, trading security for convenience
- Device health — MDM enrollment, cert validity — not evaluated at auth time
- Tokens delivered over the network without transport-layer binding — portable exfiltration vectors
DEVICE
POSTURE
CHECK
Devices forward their certificate via a standard header. The auth proxy validates the cert and checks that the device meets MDM enrollment and baseline health requirements against a regularly updated posture table. Any failure halts the flow before the identity provider is ever reached.
OKTA AUTH
+ WEBAUTHN
+ PKCE
Users complete a standard OIDC authorization code flow with PKCE through Okta, with WebAuthn enforced for phishing-resistant MFA. The auth proxy manages nonce, state, and PKCE data in a managed NoSQL table for the duration of the session.
CALLBACK
+ ENCRYPTED
TOKEN BINDING
After Okta auth, the code is exchanged and the identity validated. For CLI flows, tokens are additionally encrypted and delivered via mTLS — bound to the initiating device, not just bearer-presentable.
9 MONTHS.
ZERO
SHORTCUTS.
The auth proxy was designed and built over four months in early 2024, then rolled out across internal services over the following five months. Phased app onboarding let teams migrate at their own pace while the auth layer matured in production.
The auth proxy was the foundation — but the full Zero Trust picture took longer to close. A device revocation service followed later in 2024, enabling instantaneous certificate revocation. The Device Posture Engine shipped in 2025, enabling continuous compliance monitoring beyond periodic snapshots.
Observability was a first-class requirement from day one — session UUID, client IP, and trace ID threaded through Go context, enabling end-to-end correlation across the auth flow without coupling.
- Managed NoSQL table for session state (nonce, PKCE, state) and posture lookups — atomic access pattern
- Envelope encryption for tokens at rest; cloud-based JWT signing
- Content-negotiation middleware: JSON to CLI clients, browser responses to humans — same endpoint, zero friction
- Zero persistent refresh tokens — posture re-evaluated on every daily auth cycle
- Device revocation service — instantaneous revocation via table lookup, no cert infrastructure changes required
- Device Posture Engine — continuous compliance monitoring, replacing periodic snapshots with real-time posture signals
WHAT THE
SPEC DIDN'T
MENTION
Several technical decisions shaped the final architecture in ways that weren't obvious from the original requirements. Each one traded short-term convenience for long-term correctness.
The most important: choosing a managed NoSQL table. The access pattern for for session state and posture lookups was designed to be fast & atomic from the start — eliminating consistency edge cases that typically surface under load or during partial failure.
- Managed NoSQL table — nonce, state, and PKCE data for session management. Atomic access pattern, no consistency edge cases at scale.
- Envelope encryption — Sensitive data encrypted at rest via cloud KMS, reducing blast radius if storage credentials are compromised. Cloud KMS also used for JWT signing.
- Context-propagated observability — session UUID, client IP, and trace ID threaded through Go context with typed keys. End-to-end correlation without polluting function signatures.
- Single-source for security checks — all auth flows went through the same code for cert validation, device health, lost/stolen status and other security checks. This consistency meant a single path for audit and no risk of edge cases where one flow was less secure than another.
INSTANT
DEVICE
REVOCATION
A certificate-based trust model is only as strong as its revocation path. The auth proxy deliberately avoids traditional revocation infrastructure — instead, trust is revoked by updating a revocation record the proxy checks on every auth attempt. A device flagged as lost or stolen is blocked immediately without any certificate infrastructure changes.
A dedicated Go service owns this path. Security and IT can revoke any asset directly, and employees can self-report their own device via a self-service portal — no ticket required. Either path produces the same outcome: the auth proxy denies the device before the identity provider is ever reached.
The revocation service also syncs with the IT asset inventory system, so a device marked lost in the inventory is automatically reflected in the revocation store — no manual double-entry.
- Written in Go — consistent with the broader internal tooling stack
- Revocation is instantaneous — effective at the device's next auth cycle, no cert infrastructure changes required
- Bidirectional sync with IT asset inventory — one action, two systems updated
- Self-service portal — employees can report without filing a ticket or calling the helpdesk