When you build a product that partners or external organisations use, you often do not want their guest accounts sitting inside the same Entra ID tenant as your own employees. A cleaner pattern is to run a dedicated partner or guest tenant, an Entra ID tenant licensed for MAU (Monthly Active Users), that holds only guest identities and no applications at all. Your actual application keeps running in the home tenant, wherever that is hosted, and reaches into the guest tenant only to invite and manage guest identities. This post walks through how that invite flow is wired up using Microsoft Graph, and compares two ways of authenticating the Graph calls that make it happen.
Why keep guests in a separate tenant
Mixing internal staff and external guests in one directory works fine for small setups, but it gets messy once you have several partner organisations, each with different levels of trust. A separate guest tenant gives you one place to manage every partner identity, independent of how many applications, services or agents exist in the home tenant. It also means a compromise or a misconfigured Conditional Access policy in the home tenant does not automatically expose guest accounts, and vice versa.
This separation is not required if your application happens to be hosted inside the same tenant as the guests. It becomes useful specifically when the application lives in one tenant, the home tenant, and the guest identities live in another, the partner tenant, which is the setup this article focuses on.
How the invite flow works
The web application itself uses one Entra ID app registration purely for signing users in. A second, separate app registration is used only to call Microsoft Graph and create guest invitations. This separation matters: the Graph app registration is granted the Application permission User.Invite.All, which is a high privilege permission that can invite anyone into the tenant, and you do not want your regular sign-in app carrying that permission.
The Graph app registration lives in the home tenant, but a corresponding enterprise application for it is created in the partner tenant, because that is the tenant it needs to call into. Instead of a client secret, the Graph app registration trusts a federated credential tied to a user assigned managed identity running in the home tenant. When the application needs to invite a guest, it asks the managed identity for a token, exchanges that for an access token against the partner tenant using the federated credential trust, and calls the Graph invite API with Application permissions. No secret is generated, stored or rotated anywhere in this chain.
Setting up the Graph app registration in the home tenant
The Graph app registration is created as a multi-tenant app registration, since the corresponding enterprise application needs to be created in a different tenant than the one the registration itself lives in. It is granted the Microsoft Graph Application permission User.Invite.All, with admin consent, and nothing else. A federated credential is then added on this app registration, pointing at the user assigned managed identity that your application or service uses.
A common mistake here is forgetting that a federated credential only works if the subject claim, issuer and audience configured on it match exactly what the managed identity presents. If the invite call fails with an invalid client assertion error, check these three values first before assuming the Graph permission itself is wrong.
Creating the enterprise application in the partner tenant
Because the Graph app registration is multi-tenant, an administrator in the partner tenant can create an enterprise application from it, effectively consenting to let that specific app registration call Graph inside their tenant. You must be careful to pick the correct application from the home tenant here, since a multi-tenant registration can, in principle, be added by any tenant that knows its application ID. Restricting which tenants are allowed to consent, on the app registration side, is worth doing if you only ever expect one or two partner tenants to use it.
Once admin consent is granted for User.Invite.All in the partner tenant, the flow is complete end to end: the home tenant application authenticates as the managed identity, exchanges that for a token against the partner tenant through the federated credential, and calls Graph to invite the guest user, all without a client secret existing anywhere.
Trade-offs of the managed identity approach
This setup works well and removes an entire class of problems around secret rotation and leaked credentials. That said, a user assigned managed identity is not scoped to a single application by default. Any service, function, agent or person with sufficient access in the home tenant that can attach to or use that managed identity can potentially mint a token and invite guests into the partner tenant. As more workloads and people accumulate access to the home tenant over time, this shared identity becomes a wider blast radius than a credential scoped to one specific application.
This is worth flagging during a security review, particularly for home tenants that host many applications and services on shared infrastructure. It does not mean the pattern is unsafe, but it does mean access to the managed identity itself needs the same scrutiny you would give to a Graph API permission with User.Invite.All.
Alternative: certificate based client assertion
If the shared blast radius of a managed identity is a concern, a client assertion backed by a certificate is a reasonable alternative. In this version, both the web application registration and the Graph app registration are single tenant, rather than multi-tenant, and the application can be hosted anywhere, including inside the partner tenant itself. The private key backing the client assertion is stored in Azure Key Vault, and access to that key vault is restricted specifically to the application that needs it.
The trade-off flips here: fewer services or people can obtain a token, since access is gated by Key Vault permissions on a single certificate, but you now own certificate rotation, renewal and deployment. For teams that already have certificate lifecycle automation in place, this is usually a small cost. For teams without it, this becomes an operational burden that offsets some of the security gain.
You can also deploy both the Key Vault and the application into the partner tenant rather than the home tenant. In that case, single tenant app registrations are enough on both sides, and you can go back to using a system assigned managed identity, since the identity is now scoped tightly to that one application in that one tenant.
Which approach to pick
If your home tenant hosts a small, well controlled set of applications and the team managing it is small, the managed identity with federated credential approach is simpler to run and has one less moving part, since there is no certificate to rotate. If the home tenant is shared across many teams, applications and agents, lean towards the certificate based client assertion, or move the application and its Key Vault into the partner tenant entirely, so the identity used to invite guests is scoped as narrowly as possible.
Either way, the core benefit holds: no client secret is required for the guest invite flow itself, which removes secret expiry incidents and leaked credential risk from this particular integration.
Leave a Reply