Add Okta authentication for /intake/* (worker-enforced, testing)

[lamontacrook]

Goal

Add Okta authentication to gate /intake/* for testing, enforced server-side in the Cloudflare Worker (workers/website/). Uses the existing confidential Okta Web app (client ID + secret) via the OIDC Authorization Code flow.

Why the worker (and not the .aem.page URL)

The originally requested URL stage--drago-toolkit--adobedevxsc.aem.page/intake/form is on Adobe's hostname and cannot be fronted by Cloudflare, so the worker can't intercept it. A confidential client (secret) also can't be used safely in browser-only code. Therefore auth is enforced in the worker, which is pointed at the stage AEM branch and tested via wrangler dev (http://localhost:8787) and/or a *.workers.dev deploy.

Trade-off accepted: testing happens through the worker host, not the literal .aem.page stage URL.

Scope / behavior

• Gate all of /intake/*; everything else stays public.
• Any authenticated Okta user is allowed (no group/email restriction).
• For testing, point the worker origin at stage: AEM_ORG=adobedevxsc, AEM_SITE=drago-toolkit, AEM_BRANCH=stage.

Implementation

1. workers/website/handlers/auth.js (new) — OIDC Authorization Code flow with Web Crypto (no heavy deps):
   • requireAuth() — allow non-/intake/ and /auth/* paths; allow valid session; else 302 to Okta /v1/authorize with client_id, redirect_uri=<origin>/auth/callback, response_type=code, scope=openid profile email, random state + nonce (short-lived signed cookie carrying original path).
   • handleCallback() — validate state, exchange code at /v1/token using client_id + client_secret (server-side), verify id_token (RS256 via cached JWKS, iss/aud/exp/nonce), set signed session cookie, redirect to saved path.
   • handleLogout() — clear session cookie.
   • Session cookie: HMAC-signed (SESSION_SECRET), HttpOnly; Secure; SameSite=Lax, ~1h TTL.
2. workers/website/index.js — handle /auth/callback + /auth/logout, then call requireAuth() before the existing ROUTES dispatch.
3. workers/website/index.js (formatRequest) — add AEM_BRANCH var (default main) so origin = ${AEM_BRANCH}--${AEM_SITE}--${AEM_ORG}.aem.live.
4. Secrets/config
   • workers/website/.dev.vars (new, gitignored): OKTA_ISSUER, OKTA_CLIENT_ID, OKTA_CLIENT_SECRET, SESSION_SECRET.
   • wrangler.toml: add AEM_BRANCH; document Okta values + SESSION_SECRET set via wrangler secret put for deployed envs.
   • .gitignore: add .dev.vars and .env.

Okta app configuration (manual)

• Sign-in redirect URI: http://localhost:8787/auth/callback (+ *.workers.dev callback if deployed).
• Sign-out redirect URI: http://localhost:8787/.
• Grant type: Authorization Code. Assignment: everyone in the org.

Test plan

• cd workers/website && npx wrangler dev
• http://localhost:8787/intake/form → redirect to Okta → log in → returns to form. /intake/* all gated.
• http://localhost:8787/ and other paths → public, no redirect.
• Verify: session cookie HttpOnly/Secure/SameSite=Lax; logout clears it; state/nonce mismatch rejected.

Security notes

CSRF via state, replay protection via nonce, full id_token validation, signed short-lived session cookie, secret only in worker env, no token logging.

Blocking prerequisite

• Okta org domain / issuer URL still needed (e.g. https://<org>.okta.com or https://<org>.okta.com/oauth2/default). Client ID, client secret, and kid are on hand; the issuer is required to resolve the /authorize, /token, and JWKS endpoints.

[lamontacrook]

Option B — Adobe App Builder (scaffolded in app-builder/)

Alternative to the Cloudflare Worker, and a better fit given the repo-root .env already uses the ACTIONS_OKTA_ISSUER (App Builder convention). The confidential client secret stays server-side in a Runtime action. Scaffolded under app-builder/ and excluded from EDS code sync via .hlxignore.

Same core constraint

App Builder is not a CDN and cannot sit in front of *.aem.page. The gate is a web action that runs the Okta flow and proxies the stage origin, so the form is reached at <REDIRECT_URI>/intake/form (the App Builder URL), not the .aem.page URL.

Structure

app-builder/
  app.config.yaml            # intake-auth/gate web action + inputs
  package.json               # jose
  actions/gate/index.js      # authorize redirect + callback + session + proxy
  .env.example
  README.md

A single web action (intake-auth/gate) handles three cases:

1. ?code & ?state → OAuth callback: exchange code (Basic auth, secret server-side), verify id_token (RS256 via JWKS, iss/aud/nonce), set signed ak_session cookie, redirect to requested path.
2. valid session cookie → proxy AEM_ORIGIN + path, return HTML.
3. otherwise → redirect to Okta /authorize. Any authenticated Okta user passes.

Config (repo-root .env)

• ACTIONS_OKTA_ISSUER (present: https://adobe.okta.com)
• ACTIONS_OKTA_CLIENT_ID, ACTIONS_OKTA_CLIENT_SECRET
• SESSION_SECRET (openssl rand -base64 32)
• AEM_ORIGIN = https://stage--drago-toolkit--adobedevxsc.aem.live
• REDIRECT_URI = deployed gate URL (must match Okta sign-in redirect URI exactly)

Okta app

• Sign-in redirect URI = REDIRECT_URI, e.g. https://<ns>.adobeioruntime.net/api/v1/web/intake-auth/gate (also register the aio app dev URL for local).
• Grant type: Authorization Code. Assignment: everyone in the org.

Test plan

cd app-builder && npm install
aio app use      # select Console project/workspace
aio app dev      # local
aio app deploy   # to I/O Runtime

Visit <REDIRECT_URI>/intake/form → Okta login → proxied stage form.

Cloudflare vs App Builder

• App Builder: Adobe-native, reuses ACTIONS_OKTA_ISSUER; weaker as a front door (cold starts, exec limits, no edge cache) — fine for gating one form in testing.
• Cloudflare: documented BYO-CDN for EDS, edge-cached; non-Adobe deploy target.
• Neither protects the literal .aem.page URL.

[lamontacrook]

Decision: use AEM native site authentication (token-based)

Switching to the native method documented at https://www.aem.live/docs/authentication-setup-site. The Cloudflare Worker (Option A) and App Builder (Option B) approaches are dropped — the app-builder/ scaffold has been removed.

Why native, and the accepted trade-offs

• ✅ It is the only method that protects the real stage--drago-toolkit--adobedevxsc.aem.page URL (runs in AEM's own CDN).
• ✅ Config-only, no code to build/deploy.
• ⚠️ Whole-site, not path-scoped — quote: "Authentication can only be enabled or disabled for the entire site." This gates the entire stage preview site, not just /intake/form. (Accepted.)
• ⚠️ Not Okta — it is AEM site-token / email-allowlist auth; the Okta Web app is not used. (Accepted.)

Setup steps (Admin API, target = adobedevxsc / drago-toolkit, preview only)

Prerequisite: Configuration Service enabled + authenticated (/docs/config-service-setup).

1. Create a site token
   POST https://admin.hlx.page/config/adobedevxsc/sites/drago-toolkit/secrets.json (empty body)
   Response: { "id": "...", "value": "...", "created": "..." } — save id and value.

2. Enable token access for preview only
   POST https://admin.hlx.page/config/adobedevxsc/sites/drago-toolkit/access/preview.json

   { "allow": [], "secretId": ["<id-from-step-1>"] }

   (access/preview.json = .aem.page only; access/live.json = .aem.live; access/site.json = both.)

3. CDN — for the native .aem.page host nothing extra is needed; the Authorization header forwarding step only applies to a BYO CDN.

How access works after setup

• Programmatic: send header authorization: token hlx_<value>.
• Browser: project-role users sign in via the AEM Sidekick Extension. (An email allowlist via allow can be added for interactive sign-in.)

Open items

• Confirm Config Service is enabled for the site.
• Admin API requires Adobe IMS auth to execute steps 1–2.
• Decide allow list (leave [] for token-only, or add *@adobe.com for email sign-in).

[lamontacrook]

Chosen approach: Adobe App Builder Okta gate ✅

Decision: use the App Builder proxy (Adobe-native) with the Okta Web app. The Cloudflare Worker (Option A) and AEM native token auth are not pursued; the native OIDC CDN path was declined (requires a managed-CDN domain).

Why

• Uses the Okta account/credentials as originally intended (real click-and-login flow).
• Adobe-owned runtime; confidential client secret stays server-side.
• Path scoping not required; gate currently targets /intake/*.

Trade-off (accepted)

Reached via the App Builder action URL (<REDIRECT_URI>/intake/form), not the literal stage--…aem.page host — no method can sit on the .aem.page preview host.

Scaffold committed

app-builder/ (commit e870124):

• actions/gate/index.js — authorize redirect → callback token exchange (Basic auth, secret server-side) → id_token verify (JWKS, iss/aud/nonce) → signed ak_session cookie → proxy AEM_ORIGIN + path.
• app.config.yaml — intake-auth/gate web action, inputs mapped from repo-root .env.
• .hlxignore excludes app-builder/ from EDS code sync; .gitignore ignores .env + aio artifacts.

Remaining setup (manual)

• App Builder project/workspace created in Developer Console; aio app use from app-builder/.
• Root .env: ACTIONS_OKTA_CLIENT_ID, ACTIONS_OKTA_CLIENT_SECRET, SESSION_SECRET, AEM_ORIGIN, REDIRECT_URI.
• Okta app sign-in redirect URI = deployed gate URL (+ aio app dev URL for local).
• aio app deploy; test <REDIRECT_URI>/intake/form.