Signaling authentication

Current TSG HTTP and analytics workers require signed OAuth signaling access tokens. Disabling authentication prevents these workers from starting. Browser sessions and ordinary management tokens cannot authorize signaling. Instance-wide worker management separately requires an allowlisted human operator.

The receiver verifies the token signature and trusted OpenID issuer, its exact audience, dplane-signaling scope, sending plane client_id and transfer permission. Tokens require exp, iat, jti, sub and tenant. Control-plane requests to a worker require execute:dp.transfer. Callbacks to a control plane require execute:cp.transfer; callback permission cannot drive worker execution.

Worker identities and accepted owners

The control plane's signaling identity is auth.signalingId, or auth.clientId when omitted. Each worker explicitly configures that logical identity, its own stable audience and all accepted execution owners:

controlPlane:
  controlplaneId: control-plane-api
  dataplaneId: shared-http-dp
  executionScopes:
    - issuer: https://sso.example.org
      controlPlaneId: control-plane-api
      tenantId: 6cc414b6-402d-4816-893e-1646f5b17c6e

Replace the example UUID with the canonical tenant ID returned by Tenant Management. One accepted owner uses one entry; several owners use several. Every scope's controlPlaneId must match the configured controlplaneId. There is no dedicated/shared switch, default tenant selection or worker self-registration. Analytics split runners use explicit authenticated bridge assignments; see split mode.

Worker signaling additionally requires a canonical lowercase UUID tenant_id. The worker matches the verified issuer, control-plane client_id and canonical tenant ID against executionScopes, then persists that owner on the flow. Every lifecycle and status operation checks the immutable owner. A flow ID, dataset ID, participant DID, tenant slug or browser tenant header alone grants no authority. The token's tenant slug is a routing claim, separate from canonical ownership.

dataplaneId is the stable worker identity and signaling audience. It is distinct from the control plane's internal registration database ID. One worker endpoint can have separate tenant-local registrations with the same dataplaneId.

Managed provisioning and token requests

In SSO Bridge, authorize the existing logical control plane to signal the worker:

managedSignalingTargets:
  - audience: shared-http-dp
    identity: control-plane-api

Tenant Management's root sharedDataPlanes list declares the worker target. The selected profile's sharedDataPlanes grants each tenant's existing control-plane workload credential access to that target. The managed control-plane profile provisions the worker identity, reachable API endpoint, supported profiles and executionLease: true independently for each tenant. No worker startup registration is involved.

Newly provisioned organizations still need an explicit entry in the worker's accepted-owner configuration before they can execute there. Copy canonical IDs from completed provisioning, update executionScopes, and restart or redeploy the worker. This does not require a separate worker process or a static signalingClients mapping per organization. See the managed HTTP sample.

Token requests send grant_type=client_credentials, audience=<receiving-plane-id> and scope=dplane-signaling to the SSO bridge token endpoint with the tenant-bound workload credential. The issuer binds the token to that credential's canonical tenant and grants. Request parameters cannot select another tenant or logical control-plane identity. The control plane caches tokens per tenant, target and credential. Token acquisition failures stop signaling instead of falling back to a management token.

Managed signaling tokens expire after at most 30 seconds and no later than their authorization snapshot. See signaling token lifetimes for issuance and cache behavior.

Execution deadlines and revocation

Every current TSG worker registration requires executionLease: true. The control plane renews active flows every 10 seconds while the owner's lifecycle receipt and authorization projection remain active and fresh. It also checks any exact DID match for a locally managed counterparty. An external peer's lifecycle remains that peer's authority.

Prepare, start, resume and renewal include X-TSG-Execution-Valid-Until, a future epoch timestamp in milliseconds derived from those authorization projections. The worker stores a lease ending at the earlier of that deadline and the verified signaling JWT expiry. Status reads do not renew it. Missing, malformed or expired deadlines cannot establish execution authority.

New HTTP proxy requests and refreshes fail when the stored lease expires; already-open streams may finish. Analytics workers also fence execution and retry runtime stops. See HTTP execution leases and analytics execution.

Third-party credentials and callbacks

The control plane retains registration APIs for third-party data planes. With authentication enabled, registration PUT and DELETE calls accept only the caller's own identity, taken from azp, client_id or sub. A registration's private authorization can contain tokenEndpoint, clientId and clientSecret for a separate outgoing signaling credential. Optional jwks or jwksUri stays private too. API responses omit the entire authorization object. Receiver issuer trust still comes from its own OpenID configuration.

For integrations that use callbacks, the control plane verifies its own audience, the addressed tenant slug and execute:cp.transfer. It checks the caller's client_id against the selected flow's registered data-plane identity before changing transfer state. GET /tenants/:slug/transfers/:id/agreement, relative to the API root, applies the same ownership check and exposes an agreement only to its authenticated owning plane.

SSO Bridge's static signalingClients mappings remain available for integrations such as Siglet. Each mapping fixes the authenticated client, tenant slug, caller role, allowed audiences and optional subject. An optional fixed subject can match Siglet's participant context ID; request parameters cannot change it. A static slug-only mapping does not supply the canonical managed owner and execution deadline required by current TSG workers. See the SSO signaling reference.

Siglet 0.1.4 advertises an incorrect access-token expiry and omits fresh credentials on resume. Authenticated signaling alone does not establish compatibility with credential renewal or resume.