Brainforge Knowledge

same-origin-openwork-proxy-auth-investigation

5 min read

Investigation: same-origin /openwork proxying + auth bridging

Status: Completed recommendation
Date: 2026-03-07
Related ticket: PLT-1080
Related plan: OpenWork Standup Plan

Decision summary

Recommendation: Do not proceed with same-origin proxying right now.
Keep the current Labs-first + platform entry-route model until we have a concrete product requirement that cannot be met by:

  • /openwork authenticated entry in platform, and
  • Labs-hosted OpenWork runtime + token-based OpenWork auth.

Proceed with a same-origin spike only if we confirm a strong product need for seamless session behavior (for example, strict enterprise cookie/domain constraints or workflow breakage caused by cross-origin boundaries).

Current state (what exists today)

  • Platform /openwork is an authenticated wrapper page that loads static OpenWork web assets from /openwork-static/index.html in an iframe.
  • Platform auth is enforced in Supabase middleware; only /openwork/about is public.
  • There is no platform rewrite or route-handler proxy for /openwork/:path*, /opencode/*, or /opencode-router/*.
  • OpenWork web clients expect token-based auth for /opencode calls (Authorization: Bearer ...), while platform auth is cookie/session based.
  • OpenWork server already contains non-trivial proxy/auth logic for /opencode* and /opencode-router* (header stripping, scoped auth, high-risk action checks).

Implication: same-origin proxying is not an incremental config toggle. It is an auth and proxy-safety project with security and reliability risk.

Product-need threshold (when this should be reconsidered)

Re-open same-origin work only if one or more are true:

  1. Internal users hit repeatable UX friction from cross-origin boundaries that cannot be fixed with current entry mode.
  2. Enterprise/security requirements demand strict same-site cookie behavior across platform and OpenWork.
  3. We need platform-owned auditing/authorization at every OpenWork API hop and cannot rely on OpenWork token/session boundaries.
  4. Labs-first usage demonstrates enough adoption to justify additional maintenance burden.

If none are true, defer.

Options evaluated

Option A (current): Labs-first hosting + platform entry route

Pros

  • Lowest coupling and lowest blast radius.
  • Preserves OpenWork runtime assumptions.
  • Fastest path to usage learning.

Cons

  • No seamless shared-cookie experience.
  • Extra complexity if users must reason about two session models.

Assessment: Best default now.

Option B: Next.js rewrite pass-through to OpenWork host

Pros

  • Minimal code changes to route traffic under platform origin.

Cons

  • Limited control for secure auth bridging and header policy.
  • Harder to apply fine-grained safeguards for streaming, websocket/SSE, and path-specific controls.
  • Easy to create hidden regressions in middleware/auth behavior.

Assessment: Not recommended as primary approach.

Option C: Route-handler proxy (BFF style) under platform origin

Pros

  • Stronger control over auth exchange, headers, and failure handling.
  • Easier to gate routes and add request-level policy.

Cons

  • Highest implementation/maintenance complexity in platform.
  • Requires explicit and safe token-bridging model.
  • Requires substantial regression coverage.

Assessment: Preferred only if product need is confirmed.

Option D: Deep co-hosting OpenWork runtime directly in platform process

Pros

  • Theoretical single-stack feel.

Cons

  • Conflicts with current decoupled runtime model and operational assumptions.
  • Largest risk to platform stability and release cadence.

Assessment: Reject for now.

Auth-bridging analysis (core risk)

Current mismatch:

  • Platform: Supabase cookie/session model.
  • OpenWork: bearer token model for /opencode and workspace endpoints.

If proceeding with same-origin, the safest model is:

  1. Platform-authenticated user requests OpenWork session bootstrap endpoint.
  2. Platform backend issues a short-lived, scoped OpenWork token (audience, workspace scope, TTL).
  3. Token is used only for OpenWork proxy paths.
  4. Rotation/refresh and revocation are explicit.

Avoid:

  • Reusing Supabase cookies directly inside OpenWork server logic.
  • Long-lived bearer tokens in browser storage without TTL/scope controls.
  • Duplicating OpenWork server auth decisions in multiple places.

Proxy/base-path considerations

  • OpenWork platform embedding currently depends on static assets at /openwork-static and hash routing.
  • Same-origin app-path hosting (/openwork/:path*) would require explicit base-path strategy and likely web-build/runtime updates.
  • /opencode traffic includes streaming/long-lived behavior; proxy layer must preserve streaming semantics and timeout behavior.
  • Middleware exceptions must be explicit so auth redirects do not break API traffic.

Failure modes to plan for

  1. Auth redirect loop: middleware redirects API/proxy calls to /login.
  2. Session desync: cookie mutation in middleware breaks Supabase session continuity.
  3. Token scope leak: over-broad OpenWork token grants unintended workspace access.
  4. Streaming breakage: SSE/chunked responses buffered or closed by proxy layer.
  5. Path rewrite drift: /openwork/* and /opencode* mappings diverge from OpenWork expectations.
  6. Dual-policy divergence: platform proxy and OpenWork server enforce conflicting auth/risk rules.
  7. Observability blind spots: failed proxied calls lack traceability between platform and OpenWork services.

Follow-on work required if decision flips to “yes”

  1. Architecture decision record
    • Finalize route topology (/openwork/*, /opencode/*, /opencode-router/*).
    • Define source of truth for auth decisions.
  2. Auth bridge implementation
    • Token mint/refresh/revoke flow.
    • Scope and TTL policy.
    • User/workspace identity mapping.
  3. Proxy implementation
    • Route handlers for required paths.
    • Header allow/deny policy.
    • Streaming-safe transport and timeout settings.
  4. Middleware updates
    • Explicit exceptions for proxy endpoints.
    • Guardrails to avoid session cookie breakage.
  5. Operational controls
    • Metrics, structured logs, correlation IDs, alerting.
    • Rollback switch/feature flag.
  6. Security review
    • Threat model refresh and approval for token/cookie handling.

Required regression coverage (minimum bar)

Automated

  • Auth tests for:
    • authenticated access to /openwork pages,
    • unauthenticated redirect behavior,
    • proxy endpoint behavior for authenticated vs unauthenticated callers.
  • Route/proxy tests for:
    • path rewrite correctness,
    • header forwarding/stripping policy,
    • error mapping and timeout behavior.
  • Contract tests for token minting and scope validation.

Manual end-to-end

  • Login → /openwork → OpenWork action flow.
  • Streaming action confirmation (long-running response still works).
  • Multi-tab/session behavior (no redirect loops or silent sign-out).
  • Expired token behavior and recovery UX.
  • Feature-flag rollback path.

Gate 3 recommendation input

For Gate 3, current recommendation is No-Go (defer) until the product-need threshold above is met.
If threshold is met, execute Option C (route-handler BFF) as a scoped spike with explicit exit criteria and rollback controls.

Graph View

Backlinks