[docs] Document ITokenCredentialProvider for reusing Aspire's Azure credential

[aspire-repo-bot]

Documents changes from microsoft/aspire#17387

@eerhardt

Targeting release/13.5 — the latest release branch on microsoft/aspire.dev — because release/13.4 (from the source PR milestone 13.4) does not exist there.

Why

microsoft/aspire#17387 makes ITokenCredentialProvider public so integrations and AppHost code outside of Aspire.Hosting.Azure can resolve the same TokenCredential that Aspire's Azure hosting integrations use for provisioning and Azure API calls. This is a new public type (new_public_type signal) with an explicit "User-facing usage" section in the PR body (pr_body_has_user_facing_section signal), so it needs to be documented.

Changes

• Updated src/frontend/src/content/docs/integrations/cloud/azure/azure-default-credential.mdx with a new "Reuse the credential in custom code" section that:
  • Shows how to resolve ITokenCredentialProvider from DI and use its TokenCredential property.
  • Notes the singleton registration via AddAzureProvisioning, including indirect registration through Azure resource extension methods that invoke it.
  • Explains that the concrete credential type is an implementation detail and should be treated as opaque.
  • Cross-references the existing "Default credential behavior" section.
  • Mentions that callers can replace the registration with a custom implementation.

No new pages were created; this is an addition to an existing, closely related page.

Generated by PR Documentation Check · auto · 36.6 AIC · ⌖ 6.34 AIC · ⊞ 19.6K · ◷

[aspire-repo-bot]

Automated wording suggestions from the forbidden-words check. Apply the suggestions to resolve them.

[aspire-repo-bot]

Use "AppHost" instead of "app host".

Suggested change

	Integrations and app host code outside of `Aspire.Hosting.Azure`—for example, a pipeline step, lifecycle hook, or custom resource—can resolve the same `TokenCredential` that Aspire's Azure hosting integrations use for provisioning and Azure API calls. Resolve `ITokenCredentialProvider` from dependency injection and read its `TokenCredential` property:
	Integrations and AppHost code outside of `Aspire.Hosting.Azure`—for example, a pipeline step, lifecycle hook, or custom resource—can resolve the same `TokenCredential` that Aspire's Azure hosting integrations use for provisioning and Azure API calls. Resolve `ITokenCredentialProvider` from dependency injection and read its `TokenCredential` property:

[Copilot]

Pull request overview

Adds documentation for the newly public ITokenCredentialProvider so AppHost/custom integration code can reuse the same Azure TokenCredential that Aspire’s Azure hosting/provisioning uses.

Changes:

• Adds a “Reuse the credential in custom code” section describing resolving ITokenCredentialProvider from DI and consuming its TokenCredential.
• Documents how the provider is registered (via AddAzureProvisioning, including indirect registration via Azure resource extension methods).
• Notes that consumers can replace the ITokenCredentialProvider registration with a custom implementation.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[aspire-repo-bot]

Frontend HTML artifact ready

The latest frontend build uploaded the frontend-dist artifact for PR #1527. Use the VS Code button below to open this PR with GitHub Artifacts Explorer and browse the built HTML locally.

This comment updates automatically when a new frontend build artifact is uploaded.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/frontend/src/content/docs/integrations/cloud/azure/azure-default-credential.mdx:79

• PR description says this new section notes that the ITokenCredentialProvider singleton registration via AddAzureProvisioning is also reached indirectly via AddAzureEnvironment, but the doc only mentions Azure resource extension methods. Either update the PR description to match the actual doc change, or (if intended and accurate) update this paragraph to also mention AddAzureEnvironment.

`ITokenCredentialProvider` is registered as a singleton by `AddAzureProvisioning`. Azure resource extension methods invoke `AddAzureProvisioning`, so using those methods registers the provider indirectly. The credential it exposes is configured by the same Azure provisioning options (tenant ID, credential source, and so on) and matched to the current run or publish execution context, as described in [Default credential behavior](#default-credential-behavior).