`azd pipeline config --provider azdo` cannot configure federated credentials, so the Azure DevOps path requires a long-lived client secret

[jongio]

Problem

azd pipeline config supports OIDC federated credentials for the GitHub provider. The azdo provider does not. The documentation states this directly:

By default, azd pipeline config for Azure Pipelines uses client credentials. OIDC/federated credentials are not currently supported.

Source: Configure a pipeline using Azure Pipelines

Impact

Choosing Azure DevOps forces a long-lived client secret into pipeline configuration, while the same command against the other supported provider produces a secretless configuration. The security posture of a deployment is therefore determined by CI platform choice rather than by any deliberate decision, and the weaker option is the silent default.

For organizations where Azure DevOps is mandated rather than chosen, azd pipeline config is unusable for any workload with a no-stored-secrets requirement. Those users must configure the service connection and app registration by hand, which is the exact work the command exists to eliminate.

This is not a runtime limitation. The runtime half already works: azd auth login --federated-credential-provider azure-pipelines is implemented and supported, reading AZURESUBSCRIPTION_CLIENT_ID, AZURESUBSCRIPTION_TENANT_ID, AZURESUBSCRIPTION_SERVICE_CONNECTION_ID, and SYSTEM_ACCESSTOKEN. Only the configuration half is missing, so the gap is a parity gap, not a capability gap.

Proposed requirement

azd pipeline config --provider azdo must be able to produce a secretless configuration, and should do so by default.

1. Create the Azure Resource Manager service connection using workload identity federation.
2. Create the matching federated credential on the app registration, using the issuer and subject the service connection requires.
3. Make federated credentials the default for azdo, with client credentials available only behind an explicit opt-in flag.
4. Emit the generated pipeline YAML using azd auth login --federated-credential-provider azure-pipelines.

Acceptance criteria

• azd pipeline config --provider azdo creates a workload identity federation service connection
• The corresponding federated credential is created on the app registration
• No client secret is created or stored on the default path
• Generated pipeline YAML authenticates with the azure-pipelines federated provider
• Client credentials remain reachable through an explicit opt-in flag
• Documentation no longer states that OIDC is unsupported for this provider

[vhvb1989]

The premise here is out of date — azd pipeline config --provider azdo already creates a secretless (OIDC / workload identity federation) configuration, and it has been the default since mid‑2024. This was implemented in #3924 ("ado with oidc", merged 2024-06-01, fixing #2777).

What the code actually does today

• Service connection uses workload identity federation by default. In cli/azd/pkg/azdo/service_connection.go, createAzureRMServiceEndPointArgs sets endpointScheme := "WorkloadIdentityFederation" and only falls back to "ServicePrincipal" (client key) when a client secret is explicitly present.
• The app-registration federated credential is created automatically. In cli/azd/pkg/pipeline/azdo_provider.go (credentialOptions), after the service connection is created azd reads the workloadIdentityFederationIssuer / workloadIdentityFederationSubject back from it and creates a matching FederatedIdentityCredential (AzureDevOpsOIDC) on the SP.
• Federated is the default; client credentials are opt-in. When --auth-type is unset azd takes the federated path. A client secret is only created when the user explicitly passes --auth-type client-credentials.

So the acceptance criteria in this issue are already met by the runtime behavior. This is a documentation/help-text parity gap, not a capability gap.

What actually needs to change

1. Official docs — the Configure a pipeline using Azure Pipelines page still says OIDC/federated credentials are not supported and that client credentials are the default. That statement is wrong and should be removed/updated (source is in the MicrosoftDocs/azure-dev-docs repo, not this one).
2. --auth-type flag help (cli/azd/cmd/pipeline.go:58) still reads "(Only valid for GitHub provider)". It is now valid for azdo too and should be updated.
3. Stale/contradictory guard in preConfigureCheck (cli/azd/pkg/pipeline/azdo_provider.go:712) — passing --auth-type federated explicitly is rejected with the misleading error "Azure DevOps does not support federated authentication.", even though federated is exactly what the default path does. This error message contradicts real behavior and should be fixed so explicit --auth-type federated is accepted (or at minimum the message reworded).

Suggested next steps

• Update the Learn docs to remove the "OIDC not supported for Azure Pipelines" statement.
• Update the --auth-type flag description to note it applies to both github and azdo.
• Fix the preConfigureCheck guard so explicit --auth-type federated works for azdo (and update the error text).

Reference PR: #3924.

[vhvb1989]

Opened the two PRs to close this parity/docs gap:

• CLI fix (this repo): fix: correct azdo pipeline config federated (OIDC) auth help and stale guard #9329 — removes the stale preConfigureCheck guard that rejected explicit --auth-type federated for azdo, and fixes the --auth-type flag help text (it wrongly said "Only valid for GitHub provider"). Includes updated unit tests and usage snapshots.
• Official docs: MicrosoftDocs/azure-dev-docs-pr#9520 (private repo) — corrects pipeline-azure-pipelines.md, tooling-environment-faq.md, and the generated reference.md to state that OIDC (federated) is the default and supported for the azdo provider.

No runtime code change was needed for the core scenario: the secretless OIDC service connection + federated credential path already ships as the default (since #3924). Both PRs are opened as drafts for review.

[RickWinter]

Triage note: related to #9382 and #9322. Keeping separate because this issue tracks federated credential capability for azdo provider, while #9382 is an active failure report and #9322 is Azure Pipelines auth ergonomics.