Secretless cross-tenant dataverse access

Client secrets are like hiding your house key under the mat; easy to grab and impossible to audit. Certificates are just slightly better, because they at least prove who made the key. Until, of course, someone forgets where it’s stored. Even Azure Key Vault, while fantastic, doesn’t eliminate the problem; it just relocates it. So while secrets always need a mechanism on where and how to store, distribute and rotate, I rather prefer solutions that are totally secretless.

For today’s scenario, I want to call Dataverse in a completely different Entra tenant without ever storing a secret or managing a certificate. The setup is a User-Assigned Managed Identity in your operational tenant (let’s call it Tenant A), a multi-tenant app registration with a Federated Identity Credential configured in Tenant B, and an Azure Function that ties it all together.

The zero-secret pattern

Here’s what happens under the hood: The Azure Function in Tenant A uses its managed identity to request a token for api://AzureADTokenExchange/.default. That token is then exchanged for a Dataverse access token in Tenant B, validated by the FIC, which knows to trust this specific identity from that specific tenant. Dataverse then maps the resulting service principal to an Application User, and by that your cross-tenant API call works:securely, traceably, and without a single secret involved.

flowchart TB
subgraph TA["TENANT A (your Azure subscription)"]
FA["Function App<br/>(TypeScript)"]
UAMI["User-Assigned Managed Identity"]
APP["App Registration<br/>(multitenant)"]
FIC["Federated Identity Credential"]
FA -->|"uses"| UAMI
UAMI -->|"token for api://AzureADTokenExchange/.default"| APP
APP --- FIC
end
subgraph TB["TENANT B (Dataverse tenant)"]
SP["Service Principal"]
AU["Dataverse Application User"]
DV["Dataverse Web API"]
SP -->|"mapped to"| AU
AU --> DV
end
FA -. HTTPS request .-> TB
UAMI ==>|"token exchange"| SP
FA -->|"calls with issued token"| DV
DV -->|"returns data"| FA

One-command deployment

To make things super easy for you (and a bit more challenging for me), you can deploy all of that goodness in a single PowerShell command:

.\deploy-full-automation.ps1 `
 -TenantAId "<your-tenant-a-id>" `
 -TenantBId "<your-tenant-b-id>" `
 -DataverseBaseUrl "https://yourorg.crm.dynamics.com"

The script creates the Function App and User-assigned Managed Identity in Tenant A, registers a multi-tenant app without any API permissions (that part is important), configures the federated credential, sets up the service principal in Tenant B, deploys the TypeScript function, creates the corresponding Dataverse Application User and assigns it with a security role.

When you’re done experimenting, one cleanup command wipes everything:

.\cleanup-all.ps1

You can find the full code in this GitHub repo.

What’s actually running

In Tenant A, you end up with a neat little cluster: a resource group, a Function App on Linux Consumption (Node 20), a user-assigned managed identity, and the multitenant app registration that contains the federated identity credential. Tenant B only needs two things: a service principal created automatically during setup, and a Dataverse Application User that maps to it with a role of your choice. Start with System Customizer if you just want to test; trim it down later for least privilege.

Testing the setup

If deployment finishes successfully, the easiest test is to run a simple WhoAmI request through your function:

$functionUrl = "https://func-dvproxy-prod.azurewebsites.net"
$whoami = Invoke-RestMethod "$functionUrl/api/dataverseproxy?path=WhoAmI"
Write-Host "User ID: $($whoami.data.UserId)"

Once that returns something, try querying accounts or system users. If it works, you just built a completely secretless integration across Microsoft Entra tenants.

The why behind the pattern

This pattern isn’t just about security, but about getting out of the business of secret-babysitting. Every secret rotation process you eliminate is one less operational cliff edge. Managed identities and federated credentials make identity the platform’s problem again, where it belongs. You control the trust relationship; Entra handles the token lifecycle; Dataverse handles the mapping. No oh no, it expired again moments. (been there, done that 🙄)

No more secrets :-)