Cloudflare Workers integration

Use a Server web application client when your Worker owns login and can protect a client secret. Start with the Node.js walkthrough to understand the protocol, then implement the application routes in your Worker.

The downloadable Node.js login example uses an HTTP listener and an in-memory store. It is not a Worker entry point or production session package. The Account Security adapter uses Fetch interfaces and Node-compatible crypto; Workers needs nodejs_compat for those imports.

Configuration and storage

• Copy the complete issuer and client ID from the correct environment.
• Keep the client secret and token-encryption key in server secrets. Verify your deployment’s required-secret allowlist includes them.
• Register the exact public HTTPS callback; do not use your local development callback in Production.
• Keep tokens encrypted in a shared server store. Bind sessions to opaque, Secure, HttpOnly cookies.
• Use atomic operations for authentication transactions, refresh coordination and handoff consumption. Process-local Maps and eventually consistent storage are not suitable for single-use redemption across instances.

Your application configures its own storage. It never needs access to Oathvera’s internal databases or service bindings.

Refuse credentialed redirects explicitly

The Workers runtime used during integration rejected redirect: 'error' before sending a request. Use manual handling, then reject redirects without following their destination or forwarding credentials:

const response = await fetch(trustedEndpoint, {
  method: 'POST',
  redirect: 'manual',
  signal: AbortSignal.timeout(10_000),
  headers: serverOnlyHeaders,
  body: encodedBody,
});

if (response.status >= 300 && response.status < 400) {
  await response.body?.cancel();
  throw new Error('Unexpected authentication-service redirect');
}
// Next: require the expected status and parse a size-bounded response.

trustedEndpoint, headers and body come from your validated server configuration and the specific endpoint contract. They must not come from an arbitrary browser URL. Keep both time and response-size limits. Do not retry an uncertain code exchange or rotating refresh automatically.

Browser navigation and CSP

The Account Security guide uses a same-origin POST followed by a top-level redirect. If your dashboard sets form-action 'self', add the exact trusted authentication origin to that directive. Preserve your remaining policy. Test the button in a browser; an HTTP 200 from a backend launch does not prove the navigation works.

Validate in the real runtime

Exercise request construction, success responses, 301/302/303/307/308 rejection, bounded failures, missing secrets and expired sessions in your Worker runtime. Mocked Node.js fetch tests cannot establish runtime compatibility.

Then exercise the deployed application in supported browsers, including fresh/private sessions and an existing hosted cookie. Check production acceptance before routing customer traffic.

Cloudflare references: Fetch · Node.js compatibility · Secrets