Credential Runtime Bindings

An activated OAuth credential is not available to every workload. Credential Manager combines job bindings with allowed workers or worker groups so runtime delivery follows an explicit entitlement.

Applies to

OAuth source binding is a Beta Enterprise capability for single-node and distributed-worker deployments. Hybrid credential delivery is covered by the broader secrets capability, but each installed worker and component must still advertise and satisfy its runtime requirements.

The three checks

Check	Question it answers
Credential state	Is the credential active, enabled, and within its scope policy?
Job binding	May this job request the credential, with this scope subset, audience, and required claims?
Worker allowance	May the selected worker or worker group receive material for this credential?

All three must agree. A connected worker proves heartbeat, not credential serviceability. Likewise, an active credential proves token state, not job or worker authorization.

Allow workers

From the credential detail page, use Allowed workers or Allowed worker groups to select the runtime boundary. Prefer the smallest stable group that covers the intended placement.

After changing the allowlist:

1. confirm the target worker appears in the selected set or group;
2. verify the worker still advertises the required credential transport;
3. confirm deployment placement selects that worker or group; and
4. rerun the runtime-readiness check for the target job.

Removing a worker blocks future credential delivery to that worker. It does not revoke provider-side material that may have been issued previously.

Bind a job

Use Job bindings on the credential detail page to add the job and its policy:

• Scope subset narrows the credential’s allowed scopes for the job.
• Audience restricts the token audience where the provider uses one.
• Required claims enforce provider-specific identity properties such as a tenant.

The binding must fit within the credential’s scope policy. If it does not, reduce the requested grant or update the owning credential policy through a reviewed change.

Credential bundles can bind several existing OAuth credentials as one named package. Bundle validation reports conditions such as ready, disabled, missing, or needs_activation. A ready validation result proves the bundle’s stored prerequisites at that moment; it is not proof of worker connectivity or an external provider action.

Verify runtime delivery

Use the credential detail view or the supported API/CLI runtime inspection for the exact job and credential. Interpret the result as follows:

• Existing runtime metadata means a bounded runtime record is available; it does not disclose plaintext token material.
• An accepted or pending fetch means delivery was requested and must still be observed on the worker.
• A worker-not-allowed result requires an allowlist repair.
• A missing-binding result requires a job binding.
• A disabled or needs-activation result must be repaired before runtime use.

Then run the intended job and verify both LyftData execution evidence and the provider result. Internal success is not automatically proof that an external side effect occurred.

Troubleshooting order

Check layers in this order:

1. credential enabled/activated state;
2. job binding and scope policy;
3. worker or worker-group allowance;
4. job placement and worker heartbeat;
5. worker credential-transport health;
6. provider network, consent, token, and scope response.

Do not repair bindings or worker credential state by editing SQLite. Direct writes bypass validation and audit paths and can leave the server, worker, and readiness reports disagreeing.

For worker identity and authorization repair, see Worker authentication. For component configuration, use the generated DSL reference.