feat(datafactory): bridge host auth to DataFactory.MCP.Core via TokenCredential

[Ebram-Tawfik]

Summary

Bridges the Fabric MCP Server's authentication to DataFactory.MCP.Core so that Data Factory commands automatically use the host's IAzureTokenCredentialProvider instead of requiring a separate login flow.

Changes

• DataFactoryAreaSetup.cs — Register TokenCredential from IAzureTokenCredentialProvider before calling AddDataFactoryMcpServices(). DataFactory.MCP.Core v0.21.0 auto-detects a TokenCredential in DI and uses it via TokenCredentialAuthenticationService.
• Directory.Packages.props — Bump Microsoft.DataFactory.MCP.Core from 0.20.0-beta to 0.21.0-preview (includes the TokenCredentialAuthenticationService adapter).

Auth Flow

Fabric MCP Server (DefaultAzureCredential)
-> IAzureTokenCredentialProvider
-> TokenCredential (registered by DataFactoryAreaSetup)
-> TokenCredentialAuthenticationService (auto-detected)
-> FabricAuthenticationHandler -> Bearer token on API calls

Why

Without this bridge, Data Factory commands fail at auth time because FabricAuthenticationHandler calls IAuthenticationService.GetAccessTokenAsync() which requires an explicit login that never happens in the Fabric MCP Server context. Other Fabric tools (OneLake, Core) accept TokenCredential via constructor — this aligns DataFactory with that pattern.

Related

• DataFactory.MCP.Core PR: Shared handler pattern + source-gen JSON + Airflow Job integration for Fabric MCP DataFactory.MCP#102 (adds TokenCredentialAuthenticationService + version 0.21.0)

[github-actions]

Thank you for your contribution Ebram-Tawfik! We will review the pull request and get back to you soon.

[Copilot]

Pull request overview

This PR bridges the Fabric MCP Server’s host authentication into DataFactory.MCP.Core by registering an Azure.Core.TokenCredential in DI derived from the host IAzureTokenCredentialProvider, and updates the DataFactory core package version to pick up the new TokenCredentialAuthenticationService support.

Changes:

• Register TokenCredential in DataFactoryAreaSetup so DataFactory services can auto-use host auth.
• Bump Microsoft.DataFactory.MCP.Core dependency from 0.20.0-beta to 0.21.0-preview.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
tools/Fabric.Mcp.Tools.DataFactory/src/DataFactoryAreaSetup.cs	Adds DI bridge from IAzureTokenCredentialProvider to TokenCredential before registering DataFactory MCP services.
Directory.Packages.props	Updates Microsoft.DataFactory.MCP.Core to 0.21.0-preview.

[Jon Gallant (jongio)]

Two issues with the auth bridging approach that need resolution before this can merge:

1. Singleton caching breaks OBO/remote mode: IAzureTokenCredentialProvider.GetTokenCredentialAsync is designed to return per-execution-context credentials (see the interface xmldoc). Caching the first resolved TokenCredential in a singleton means all subsequent users share one credential. If the Fabric server ever runs in HTTP mode with OBO, this is a correctness bug.

2. Sync-over-async in DI factory: .GetAwaiter().GetResult() can deadlock on platforms with a SynchronizationContext and is generally an anti-pattern in DI registration.

The fix is to register a delegating TokenCredential subclass that wraps IAzureTokenCredentialProvider and calls through to the provider on each GetToken/GetTokenAsync invocation - no caching, no blocking. Something like:

internal sealed class ProviderDelegatingCredential(IAzureTokenCredentialProvider provider) : TokenCredential
{
    public override AccessToken GetToken(TokenRequestContext ctx, CancellationToken ct)
        => GetTokenAsync(ctx, ct).GetAwaiter().GetResult();

    public override async ValueTask<AccessToken> GetTokenAsync(TokenRequestContext ctx, CancellationToken ct)
    {
        var credential = await provider.GetTokenCredentialAsync(tenantId: null, ct);
        return await credential.GetTokenAsync(ctx, ct);
    }
}

Then register: services.TryAddSingleton<TokenCredential, ProviderDelegatingCredential>();

This preserves OBO correctness (provider resolves per-context) and avoids sync-over-async in the factory.

Also: all CI builds are currently failing - worth checking if the 0.21.0-preview package is available on the feed.

[Jon Gallant (jongio)]

Addresses my previous feedback cleanly. The delegating TokenCredential wrapper is the right pattern - per-call resolution preserves OBO correctness without sync-over-async in the DI factory. Tests are solid (proving no caching + context propagation).

[Steven Vukelich (vukelich)]

Late suggestions. Main feedback is around the Microsoft.DataFactory.MCP.Core DI extensibility and suggesting a more direct DI contract with the very broad TokenCredential type.

[Steven Vukelich (vukelich)]

Ebram-Tawfik I'd like to provide some suggestions on design improvements to be mindful that TokenCredential can mean different things to different code paths. For example, it's totally reasonable for a remote MCP server to use TokenCredential instances to talk to its own resources (e.g., using its own MI and RBAC to its own Redis cache) versus using TokenCredential instances that reflect accessing the user's intended resource for MCP tool invocations.

That being said, this PR is fine for the state of this repo today because the code only expects downstream authentication to be getting data for the MCP client/user. If/when we add functionality for the MCP server to interact with separate downstream auth credentials, then I'd be a little more worried about this possible pollution of the DI container. Such future functionality could be using a Redis cache to manage long-running or distributed MCP tool work.

(Caveat: technically, the remote MCP server will use the Azure Identity SDK + Microsoft.Identity.Web to authenticate as the Entra app registration for remote MCP server OBO flows. I do not believe those libraries would consume a TokenCredential from DI for that, so I'm not worried on affecting remote scenarios today.)

Does the Microsoft.DataFactory.MCP.Core package have DI configurability to very directly provide TokenCredential, such as through keyed services or named options?

I asked Opus 4.7, and it provided a well-laid out explanation and supports this suggestion for the Microsoft.DataFactory.MCP.Core library. Claude also called out the Azure SDK's similar WithCredential DI extension method to tightly couple an outbound client instance with the credential that client instance should use.

[Steven Vukelich (vukelich)]

When did you see cases where IAzureTokenCredentialProvider was not in the DI container? I'd expect that to always be present, but maybe there's a use case I'm not expecting.

[Steven Vukelich (vukelich)]

If we expect it to always be there, then I'd recommend a pattern where we throw an exception to fast-fail. Such failures should be caught in any manual or automated testing and never end up in the customer's hands. Catching unexpected state before we complete pull requests is the best time to fix them.

[Steven Vukelich (vukelich)]

Please do not use CancellationToken.None. Using a meaningful CancellationToken allows for responsive ending of unit tests. As detailed in the CONTRIBUTING.md, use Xunit.TestContext.Current.CancellationToken