address pass access token vs include cros credentials

Author: lennessyy

docs/encyclopedia/data-conversion/codec-server.mdx

@@ -41,9 +41,9 @@ Temporal Service. Common reasons to run a Codec Server include:
 - **Operating from the CLI.** Use commands like `temporal workflow show` and `temporal workflow execute` with readable
   data, even when payloads are encrypted at rest.
 - **Encoding inputs from the UI and CLI.** When you start or signal a Workflow from the Web UI or CLI, the Codec Server
-  can encode the input before it reaches the Temporal Service, so the Temporal Service never sees 
-  plaintext (the input still travels from your browser or CLI to the Codec Server, which is why HTTPS 
-  matters  in any non-loopback deployment).
+  can encode the input before it reaches the Temporal Service, so the Temporal Service never sees plaintext (the input
+  still travels from your browser or CLI to the Codec Server, which is why HTTPS matters in any non-loopback
+  deployment).
 - **Compliance and access control.** Because the Codec Server runs in your environment, you control who can decode
   payloads and under what conditions. You can layer authorization on top of the decode endpoint to restrict access per
   user or per Namespace.
@@ -76,8 +76,8 @@ The `/encode` endpoint works in the other direction. When you start a Workflow o
 the input is sent to the Codec Server's `/encode` endpoint first, so data reaches the Temporal Service in its encoded
 form.
 
-decoding. Because the Codec Server often holds the same keys as your Workers, treat its
-host with the same trust as a Worker; anyone who can call it has effective decrypt parity.
+Your Codec Server should use the same Payload Codec implementation as your Workers to ensure consistent encoding and
+decoding.
 
 ## Codec Server vs. Payload Codec
 
@@ -96,13 +96,41 @@ CLI can use it remotely.
 
 ## Securing a Codec Server
 
-Access to a Codec Server should be restricted because it can decode sensitive data. Common approaches include:
+Because a Codec Server can decode sensitive data, treat it with the same trust as a Worker. Anyone who can call it has
+effective decrypt access. Use HTTPS for any deployment that is not strictly loopback (`localhost`).
 
-- **Network-level restrictions.** Run the Codec Server on `localhost` or behind a VPN. The Web UI can communicate with a
-  Codec Server that is only accessible locally.
-- **Token-based authorization.** Integrate your organization's authentication provider (OAuth, Auth0, or similar).
-  Temporal Cloud can pass access tokens (JWT) to your Codec Server with each request. Verify these tokens against the
-  [Temporal Cloud JWKS endpoint](https://login.tmprl.cloud/.well-known/jwks.json).
+### Network-level restrictions
+
+Restrict network access to the Codec Server. The Web UI can communicate with a Codec Server that is only accessible on
+`localhost`, so running the Codec Server locally is a viable security pattern. For team access, place the Codec Server
+behind a VPN.
+
+### Authentication
+
+When the Codec Server is accessible beyond `localhost`, authenticate requests to verify the identity of the caller. The
+Web UI supports two approaches:
+
+**Include cross-origin credentials (recommended).** Enable **Include cross-origin credentials** in the Web UI Codec
+Server settings. The browser sends cookies scoped to the Codec Server's domain with each request. Your Codec Server must
+have its own authentication mechanism (its own login page and session cookies), so the user must have independently
+authenticated with the Codec Server. This is the recommended approach because the Codec Server maintains its own auth
+boundary, separate from the Temporal UI.
+
+**Pass access token.** Enable **Pass access token** in the Web UI Codec Server settings. The Web UI includes the same
+JWT the user used to log into the Temporal UI in the `Authorization` header of each request. Your Codec Server validates
+the token signature against the OIDC provider's JWKS endpoint. On Temporal Cloud, verify against the
+[Temporal Cloud JWKS endpoint](https://login.tmprl.cloud/.well-known/jwks.json). On a self-hosted Temporal Service, the
+token comes from whatever auth provider you have [configured for the Web UI](/references/web-ui-configuration#auth).
+This approach requires less setup but reuses the same token across the Temporal UI and the Codec Server.
+
+### Namespace-level authorization
+
+Authentication identifies the caller, but does not confirm the caller is authorized to decode payloads for a specific
+Namespace. Each request from the Web UI includes an `X-Namespace` header identifying the Namespace. To enforce
+Namespace-level access control, your Codec Server must enforce an additional check on whether the authenticated user has
+permissions for the requested Namespace. This applies regardless of which authentication approach you use.
+
+### Key management
 
 You may also need [key management infrastructure](/key-management) to share encryption keys between your Workers and the
 Codec Server.