Three Gates, One Identity

One of the easiest ways to make a secure system brittle is to describe every authentication problem as if it were the same problem. It is tempting, especially in architecture diagrams, to say the system is either “authenticated” or “unauthenticated” and move on.

Osprey Strike does not really get to live in that simpler world. It has browser traffic entering through AWS ALB, webhook traffic entering through a Cloudflare Worker, and service-to-service calls leaving toward Render. Those are three different trust boundaries with three different failure modes.

The system has multiple edges, so it needs multiple proofs

The architecture looks complicated at first because it is answering three distinct questions:

1. is this browser request really from an authenticated human?
2. is this webhook really from the external system that claims to have sent it?
3. is this outbound API call really being made by an allowed Osprey service?

Those questions sound adjacent, but they are not interchangeable. A browser login flow is about user identity and session continuity. A webhook flow is about origin authenticity and replay resistance. An outbound machine-to-machine call is about client credentials and token lifecycle.

A small sketch makes the separation clearer:

graph TD
  B[Browser user] --> ALB[AWS ALB with OIDC]
  T[Twilio webhook] --> W[Cloudflare Worker]
  W --> CFA[Cloudflare Access]
  ALB --> API[api-go]
  CFA --> API
  API --> OKTA[OAuth2 token service]
  OKTA --> R[Render API]

That diagram is easy to overread. The important thing is not that every arrow has a badge on it. The important thing is that each arrow is authenticated according to the job it is doing.

Browser auth is really a signed-header verification problem

For browser traffic, Osprey Strike relies on ALB OIDC rather than pushing raw login ceremony into the application itself. AWS ALB performs the OIDC flow, then forwards identity to the Go API via x-amzn-oidc-* headers. That choice changes the API’s job. The API is not acting like a full identity provider. It is acting like a verifier of assertions made by infrastructure it trusts, but only after checking the signature and signer constraints.

This means the application is not supposed to merely trust the presence of the headers. It validates the JWT signature, fetches AWS public keys, caches them, and applies ALBeast protections so that a forged token from the wrong load balancer does not get treated as legitimate user identity.

What looks like “simple header auth” is actually a carefully scoped delegation model:

• ALB handles the login dance with the identity provider
• the API verifies the signed result
• the application extracts claims and builds request context
• tenant membership and authorization decisions still happen deeper in the app

That last point matters. Authentication answers who the request arrived as. It does not answer what that user is allowed to do inside a two-dimensional tenant model.

Webhook auth is about origin proof, not user identity

The webhook path solves a different problem. Twilio is not a human with a browser session. It is an external system posting events into Osprey Strike, and the first risk is spoofing.

The design handles that in two stages. First, the Cloudflare Worker validates the Twilio HMAC signature. Only after that check succeeds does it forward the request through Cloudflare Access toward the API. The API then validates the Cloudflare Access credentials or JWT, depending on mode.

This gives the system two separate assurances:

• the message matches Twilio’s signing expectations
• the request reaching the internal webhook endpoint came through the approved gateway path

That is more robust than trusting one check to do both jobs. If the worker validated Twilio but the backend accepted any direct caller, the internal endpoint would still be exposed. If the backend only validated Cloudflare Access but the edge skipped Twilio signature validation, the system would know the request passed through the gateway but not whether the underlying event was authentic.

Outbound auth is a token-lifecycle problem

Calling Render flips the direction of trust. Now Osprey Strike is the client, and the problem is not verifying an incoming identity. The problem is safely obtaining, caching, and rotating credentials for outbound access.

Here the architecture uses OAuth2 client credentials. The API exchanges client ID and client secret for an access token, injects the bearer token into outbound requests, and refreshes it with an expiration buffer so near-expired tokens do not create edge-case failures in the middle of work.

That seems standard, and it is. But the boring details are the whole point:

• secrets are stored encrypted rather than left as plain text application config
• token refresh uses thread-safe caching instead of a thundering herd of refresh calls
• local development can use a mock mode without pretending the production path is identical

If browser auth is about trusting upstream infrastructure and webhook auth is about validating event origin, outbound auth is mostly about operational hygiene. Many real incidents come from stale tokens, ad hoc secret handling, or refresh races rather than from dramatic cryptographic breaks.

Local development has to mimic production without creating a trapdoor

This is where the design gets more interesting than a normal auth diagram. The unified-auth plan recognizes a common failure pattern: development shortcuts become undeclared production affordances.

The proposed dev auth injector is clever precisely because it does less than many local-dev hacks. Instead of inventing a parallel local auth universe, it emits ALB-style headers so the normal validation and request-shaping path can still be exercised as faithfully as possible.

But it only works if the escape hatch stays an escape hatch. That is why the plan layers in explicit guards:

• dev auth must be intentionally enabled
• it must not coexist with enforced ALB validation
• it must refuse to run when AWS environment signals are present
• it must require explicit local user configuration instead of hidden defaults

That is a good rule far beyond Osprey Strike. The dangerous local-dev pattern is not “fake auth exists.” It is “fake auth is convenient enough to quietly survive into places it should never run.”

WebSockets expose whether auth is architecture or just middleware

Subscriptions are where fragmented auth stories usually get caught. It is easy to secure normal HTTP routes and discover later that upgraded connections are traveling a parallel path with weaker assumptions.

The unified-auth work calls this out directly. The WebSocket InitFunc should read auth context from the HTTP upgrade request, which means the same authenticated request context can flow into subscriptions instead of treating realtime traffic as a separate, half-secured subsystem.

That is a subtle but healthy design instinct. Realtime features often fail security review not because they are exotic, but because they sit just far enough away from the main request path that teams stop insisting on equivalence.

If the subscription channel uses the same identity model as the request that created it, the system stays conceptually simpler:

• one way to establish user identity
• one context shape for downstream authorization
• one place to test for drift between dev and prod

The real win is separation of claims

The cleanest thing about this architecture is that it does not ask any single component to prove more than it should.

ALB is allowed to prove that a browser user completed OIDC. The application is allowed to verify ALB’s signed claim and map it into user context. The Cloudflare Worker is allowed to prove Twilio webhook authenticity. Cloudflare Access is allowed to prove the webhook traversed the approved gateway. The outbound token provider is allowed to prove Osprey is an authorized client of Render.

Each component owns a narrow claim:

That table is worth lingering on because it prevents a lot of sloppy architecture talk. “Authenticated” is not one bit. It is a stack of bounded claims.

What this means for operations

Operationally, the architecture gives the team better failure isolation. When authentication breaks, the debugging path is narrower because the system is opinionated about which proof belongs where.

If browser requests start failing, the likely checks are ALB headers, signing keys, claim parsing, or session behavior. If webhooks fail, the likely checks are Twilio signature generation, worker forwarding, or Cloudflare Access validation. If outbound Render calls fail, the likely checks are token acquisition, secret decryption, or token expiry behavior.

That kind of decomposition is not glamorous, but it makes incident response much less mushy. This is also why auth architecture should be documented with request flows and cache behavior, not just boxes named “Auth Service.” Many production failures live in key fetch TTLs, cookie behavior, and refresh races.

It also helps the team resist a recurring anti-pattern: “simplifying” auth by collapsing distinct trust boundaries into one generic mechanism. Simpler diagrams can produce more ambiguous systems.

What to carry forward

The big lesson is not that Osprey Strike uses several auth mechanisms. Most non-trivial systems do. The useful lesson is that it uses them for different claims, and then works hard not to blur those claims together.

1. Different edges need different proofs. Browser login, webhook authenticity, and outbound service identity are adjacent concerns, not one concern repeated three times.
2. Delegation only works when verification is explicit. ALB can own OIDC ceremony because the application still validates the resulting assertion rather than trusting raw headers.
3. Webhook pipelines benefit from layered origin checks. Twilio signature validation and Cloudflare Access each prove something useful, and neither replaces the other.
4. Outbound auth lives or dies on operational discipline. Token buffers, encrypted secret storage, and concurrency-safe refresh matter more than they look.
5. Local-dev shortcuts must be guarded like hazardous tools. A fake-auth path is acceptable only when accidental production use is aggressively prevented.

• Which of our other systems still use the word “authenticated” without making the underlying claim explicit, user identity, origin authenticity, or client authorization?
• Do any current realtime or background-worker paths bypass the same auth context we rely on for normal HTTP requests?
• Where would a narrowly scoped development auth mechanism help us test production behavior more honestly, and what hard guardrails would we require before shipping it?

1. AWS Application Load Balancer: Authenticate users — The canonical description of ALB-managed OIDC flows, useful for understanding why ALB can handle browser-facing login while forwarding signed identity assertions downstream.
2. AWS Application Load Balancer: User claims encoding and signature verification — Documents the `x-amzn-oidc-*` model and the signature-verification responsibilities that the backend must still perform.
3. Twilio Docs: Secure your app by validating incoming Twilio requests — Explains Twilio webhook signature validation, which maps directly to the Cloudflare Worker's job at the internet edge.
4. Cloudflare Docs: Service tokens — Useful for the second stage of webhook protection, where the backend validates that the request came through the approved Cloudflare Access path.
5. RFC 6749: The OAuth 2.0 Authorization Framework — The primary source for the client-credentials flow used when Osprey Strike authenticates itself to Render.
6. OWASP Secrets Management Cheat Sheet — Good supporting guidance for why encrypted secret storage and rotation discipline matter as much as the token exchange itself.