1 · Cloudflare Access
You would not be reading this if Access had not already let you in. This calls
/api/whoami, which shows what the Worker sees in the
Cf-Access-Jwt-Assertion header.
2 · Okta sign-in (PKCE)
The Access session gets you to the page. The AWS API needs a separate Okta access token, which this SPA fetches with authorization code + PKCE. Pick the scopes that match your Okta group before signing in — Okta rejects the whole login if you request a scope your group is not allowed.
Access token claims
3 · API — AWS API Gateway
Every button below hits the same Worker route and the same gateway. The Worker forwards
your Okta bearer token untouched for the Lambda TOKEN authorizer to check, and adds its
own x-api-key for the usage plan. The /api prefix is the
Worker's own namespace and is stripped before forwarding, so /api/dog
reaches {AWS_API_BASE}/dog.
Running in AWS — Lambda, and ALB → ECS
Running in Azure — ALB → VPN → Kubernetes
Which cloud serves a call is decided inside API Gateway, not here — the labels above are
documentation, and nothing in the browser or the Worker can tell the two apart.
/api/dog is a Lambda integration; the /ecs and /aks
routes go through a VPC link to the alb-routing-demo ALB, which picks the
backend by Host header. Those four need the jwtread scope.