Workload Identity

​

How it works

1. The workload asks its platform for a token addressed to Bifrost: an app-only Entra token for the Bifrost SSO app, an AWS STS web identity token, or a client-credentials token from your identity provider.
2. It calls an inference endpoint with Authorization: Bearer <token> and no virtual key.
3. Bifrost checks that the token comes from a source it trusts (its iss must match exactly), is addressed to Bifrost, and belongs to a workload: Entra takes only app-only tokens, and a generic issuer takes only tokens that pass its rule or, without one, whose workload ID is mapped. Anything else, including a person’s token, is left to the normal sign-in path, even when the same identity provider runs your SSO.
4. Bifrost verifies the signature against the source’s published keys, then the expiry and lifetime.
5. It looks up the mapping for the token’s identity, such as the object ID, role ARN or client ID. Entra object IDs match whatever their case; an issuer’s workload IDs, role ARNs included, match exactly as the token carries them.
6. The request runs as the mapped service account. The token is removed from the request, so it is never forwarded to a provider.

​

Trusted issuers

• While any workload is mapped on an issuer, Bifrost refuses a provider save that changes its kind, issuer URL or workload ID claim. Disconnect those mappings first, or add the new issuer under another name.
• Renaming or removing an issuer is allowed. Its mappings take no tokens, and show the issuer as unavailable, until an issuer with that name is back.
• If an issuer changes anyway, for example in config.json, its mappings show that the issuer changed and take no tokens until you map the workloads again.

​

Mapping a workload

• Azure workload identity federation: search the Entra directory for the managed identity or app, or paste its object ID. Its name is taken from Entra.
• An additional trusted issuer: enter the role ARN, client ID or other identity the issuer’s kind names, exactly as tokens carry it.

​

Declarative configuration

{
  "scim_config": {
    "enabled": true,
    "provider": "entra",
    "config": {
      "tenantId": "00000000-0000-0000-0000-000000000000",
      "clientId": "env.ENTRA_CLIENT_ID",
      "workloadIdentity": {
        "additionalTrustedIssuers": [
          {
            "name": "AWS prod",
            "kind": "aws",
            "issuerUrl": "https://<id>.tokens.sts.global.api.aws",
            "audiences": ["https://bifrost.example.com"]
          },
          {
            "name": "Okta workloads",
            "kind": "generic",
            "issuerUrl": "https://acme.okta.com/oauth2/default",
            "audiences": ["api://bifrost"],
            "identityClaim": "cid",
            "machineCheck": { "kind": "sub_equals_claim", "claim": "cid" }
          }
        ]
      }
    }
  }
}

• A generic issuer needs identityClaim and machineCheck. Use {"kind": "any"} to take only tokens whose workload ID is mapped, or a rule (sub_equals_claim, claim_equals, claim_prefix) with its claim and, for the last two, a non-empty value.
• issuerUrl must be https, or http on localhost for testing, with no user info, query or fragment.
• maxLifetimeSeconds caps a token’s total lifetime, between 300 and 172800; the default is 24 hours. disabled: true keeps an issuer and its mappings but refuses its tokens.

​

Responses

​

MCP gateway

​

Permissions