Multi-Tenant Authentication for Office Add-ins

If you are building an Office add-in as a product, something you sell or distribute to multiple enterprise customers, multi-tenant authentication is not optional. Each customer has their own Azure AD tenant. Their users authenticate against their tenant, not yours. Without a multi-tenant setup, every new customer requires manual configuration in your app registration, which does not scale.

A multi-tenant Office add-in uses a single Azure AD app registration configured for multi-tenant support. When a user from a new customer tenant installs the add-in, they or their IT administrator grants consent for your add-in to access their tenant. From that point, users in that tenant authenticate through Microsoft SSO against their own Entra ID and receive tokens that are scoped to their tenant's data. Your add-in receives the token, validates it, identifies the tenant, and routes requests accordingly.

The implementation details that matter: tenant discovery at token validation time, handling the admin consent redirect for new tenants, per-tenant token caching so one customer's tokens cannot be used for another's data, and the onboarding flow that new customers go through when they first deploy the add-in. We have built this architecture for ISVs distributing to anywhere from 10 to hundreds of enterprise tenants.

An HR software vendor onboarded its first three enterprise customers by hand: a screen-share with each IT department, settings adjusted per tenant, a week of back-and-forth per deal. Customer four was a 9,000-seat company whose IT team refused the manual process outright. We converted the vendor's registration to multi-tenant, built the consent page a new customer's administrator visits once to approve the permissions, and added tenant validation on the backend so each customer's tokens map only to that customer's data. Onboarding became something the vendor's sales engineer does in a kickoff call. The part that mattered commercially came later: with consent-based onboarding in place, the vendor passed the marketplace review process and listed publicly, which is how AppSource publication turned an enterprise sales tool into an inbound channel.

Multi-tenant auth is for add-ins sold or distributed beyond your own organisation. If your add-in serves one company, a single-tenant setup is simpler, safer, and easier to get through IT review, and converting later is a known path rather than a rebuild. The honest test: if you cannot name a second tenant that will use the add-in this year, do not pay for this yet.