Azure AD App Registration for Office Add-ins

Every Office add-in that uses Microsoft authentication needs an app registration in Microsoft Entra ID (formerly Azure Active Directory). The registration tells Azure who the add-in is, what permissions it needs, and which redirect URIs are valid. Get any of those details wrong and the auth flow breaks with error messages that point everywhere except the actual problem.

The parts that trip up most development teams: the app ID URI must follow a specific format for Office SSO to work. The WebApplicationInfo block in the add-in manifest must match the app registration exactly. Microsoft Graph permissions must be split correctly between delegated and application types. Admin consent must be configured for any permission that accesses organisational data. And the redirect URIs must cover every domain the add-in runs on, including localhost for development.

We handle app registrations as a standalone service for teams that have the add-in code but cannot get the auth layer to work, and as part of larger Office add-in development projects. For ISVs shipping to many customers, the registration feeds straight into multi-tenant authentication. We document every setting we configure so your IT team understands what was created in their tenant and why.

AADSTS50011. That error code sat in a fintech team's browser console for two weeks before they called us. Their add-in authenticated perfectly on localhost and failed in production, and every fix they tried targeted the code rather than the configuration. The actual faults sat in Entra ID: a redirect URI list missing the production domain, and an app ID URI that did not follow the format Office expects. We corrected the registration, split it into separate development and production entries so localhost testing could never touch live settings again, and documented each field for their IT team. Total code changes: zero. The team had budgeted a sprint for the fix; the corrected configuration was live in two days, and their security reviewers signed off on the documented permission list the same week.

This is the right standalone service when the add-in code is done and authentication refuses to cooperate, or when an IT team wants an existing configuration audited before a security review. It is not a substitute for building the auth layer itself; the registration is the configuration half of that story. And when the actual goal is moving data between Office and other systems, our integration services address the layer where that work happens.