Signaling authentication

The SSO bridge issues audience-bound data plane signaling tokens through POST /api/oauth/token. Request grant_type=client_credentials, scope=dplane-signaling and audience=<receiving plane identity> with the client's usual authentication. resource is an alias for audience; if both are supplied they must agree.

Deployment configuration authorizes each signaling target. Ordinary application permissions do not grant signaling authority. Shared workers use managedSignalingTargets and a fresh tenant workload grant. Static integrations use signalingClients; both paths require the exact execute permission:

Caller role	Required permission	Audience
controlplane	execute:dp.transfer	Receiving data plane identity
dataplane	execute:cp.transfer	Receiving control plane identity

The mapping contains an explicit audience allowlist. Do not put control plane receivers in a control plane caller's allowlist, or data plane receivers in a data plane caller's allowlist. The receivers also verify the direction's permission. Broad management permissions alone do not satisfy this issuance check.

signalingClients:
  - clientId: cp-tenant-a-credential
    tenant: tenant-a
    identity: controlplane-a
    role: controlplane
    audiences: [dataplane-a]
  - clientId: dp-tenant-a-credential
    tenant: tenant-a
    identity: dataplane-a
    role: dataplane
    audiences: [controlplane-a]

Create the OAuth clients separately with explicit kind: workload, canonical tenantId, registered audiences, grants: [client_credentials] and the required permission ceilings above. Apply the current tenant grant and principal mapping through Tenant Management. The mapping does not create clients or assign permissions. Use a separate OAuth client for each tenant and caller role, and keep exactly one mapping per client.

tenant is the receiving tenant's slug. identity becomes the JWT client_id and defaults to the authenticated OAuth client ID. sub defaults to that plane identity. An optional fixed subject overrides sub for integrations such as Siglet, where it must equal the participant context ID in the request path. Request parameters cannot change the configured tenant, plane identity or subject. The azp claim retains the authenticated OAuth client ID.

signalingClients:
  - clientId: cp-siglet-tenant-a-credential
    tenant: tenant-a
    identity: controlplane-a
    subject: siglet-participant-context-a
    role: controlplane
    audiences: [siglet-dataplane-a]

Static mappings also require an active managed organization and current target authorization. A mapping alone cannot establish a tenant grant. The issuer signs tokens with its persistent key set. Public keys are available at the jwks_uri published by its OpenID metadata. Configure receivers with that issuer, its JWKS and their own exact audience. Tokens carry aud, sub, client_id, tenant, scope, permissions, iat, exp and jti, canonical tenant_id and authorization revision. Client credentials grants do not issue refresh tokens.

Signaling tokens expire after at most 30 seconds, or earlier when their current authorization snapshot expires. The same rule applies to shared workers, dedicated workers and static mappings. Receivers verify JWTs locally; missing or stale tenant grants deny issuance.

The control plane renews shared execution leases every 10 seconds and requests tokens with at least 20 seconds left. The default signaling-token cache refreshes when fewer than 10 seconds remain, so dedicated workers normally need a new managed signaling token about every 20 seconds. Shared workers bound execution by both token expiry and the control plane's execution deadline. These timings leave room for renewal while limiting stale authorization to 30 seconds.

Existing installations

The managed CLI stack supplies organization management and consumer access. It does not provision data-plane workloads, static signaling aliases or use-case apps. Configure a worker's exact issuer, audience, canonical execution owners and managed Control Plane profile explicitly. The managed HTTP sample documents a complete shared-worker topology.

Preserve each existing worker's registered dataplaneId, database and signing key. Explicitly import its participant and service grants through Tenant Management. Changing a worker identity leaves existing transfers bound to the old registration. Drain old unowned transfers and start fresh managed transfers; do not assign their ownership from a guessed slug or reset databases to bypass import. Review existing client kinds, scopes, audiences and permissions explicitly, because old unbound clients cannot issue tokens.