Office Add-in SSO issue with Entra Identifier URI restrictions and WebApplicationInfo validation

There is no supported way to bypass either side’s validation; both behaviors are by design and must be satisfied together.

From the Entra side

Entra now enforces “secure patterns” for identifier URIs (Application ID URIs). For v1 apps without exemptions, the Application ID URI must follow one of the supported formats, for example:

• api://<appId>
• api://<tenantId>/<appId>
• api://<tenantId>/<string>
• api://<string>/<appId>
• https://<tenantInitialDomain>.onmicrosoft.com/<string>
• https://<verifiedCustomDomain>/<string>
• api://<string>.<verifiedCustomDomainOrInitialDomain>/<string>

and it must be unique in the tenant and must not end with /.

When the identifier-URI protection policy (nonDefaultUriAddition) is enabled, any new identifier URI that does not match these patterns (including unverified custom domains) is rejected. Apps using v2.0 access tokens (api.requestedAccessTokenVersion = 2) or SAML SSO are exempt by default, and administrators can also grant explicit exemptions or disable the policy (not recommended).

See: secure patterns and policy behavior in the identifier URI restrictions documentation.

From the Office Add-in side

For legacy Office SSO add-ins using the unified manifest, the webApplicationInfo block must be configured as follows:

"webApplicationInfo": {
  "id": "<appId>",
  "resource": "api://addin.contoso.com/<appId>"
}

The resource value must be the Application ID URI of the Entra app and must end with the same client ID as webApplicationInfo.id. The manifest tooling also enforces that URLs in the Resources section match the domain/subdomain of this resource value. This validation is not documented as configurable and is part of the SSO design for legacy Office add-ins.

Reconciling the conflict

The key is that the Application ID URI used in webApplicationInfo.resource must simultaneously:

1. Conform to Entra’s secure identifier URI patterns, and
2. Satisfy the Office add-in manifest’s domain-matching rule.

From the Entra documentation, the supported patterns that also allow a domain-like host are:

• https://<tenantInitialDomain>.onmicrosoft.com/<string>
• https://<verifiedCustomDomain>/<string>
• https://<string>.<verifiedCustomDomain>/<string>
• api://<string>.<verifiedCustomDomainOrInitialDomain>/<string>

For tenants with strict identifier URI enforcement, the custom domain used in the Application ID URI must be either the tenant’s initial domain or a verified custom domain in that tenant. A non-verified arbitrary domain (for example, custom-domain.com that is not verified in that tenant) will be rejected.

Therefore, the only supported pattern in this scenario is to choose an Application ID URI that:

• Uses a domain that is actually verified in the tenant (or the tenant’s *.onmicrosoft.com initial domain), and
• Is then used as the webApplicationInfo.resource value so that the Office manifest’s domain-matching rule is satisfied.

Examples that satisfy both sides (assuming the domain is verified in the tenant):

• https://contoso.onmicrosoft.com/myaddin/<appId>
• https://contoso.com/myaddin/<appId>
• api://contoso.com/myaddin (where contoso.com is a verified custom or initial domain)

These are explicitly listed as supported formats for identifier URIs and can be used as the resource in webApplicationInfo.

If the add-in is hosted on a different, non-verified domain, that domain cannot be used in the Application ID URI in tenants where the identifier-URI protection policy is enforced. In that case, the hosting domain and the Application ID URI domain must be decoupled: the add-in can still be served from any HTTPS origin, but the Application ID URI must use a verified or initial domain that satisfies Entra’s rules and the Office manifest’s domain-matching requirement.

Answers to the specific questions

1. Officially supported approach for Office.js SSO in this scenario The supported approach is to configure the Entra Application ID URI to one of the secure patterns that uses a tenant-verified or initial domain (for example, https://<tenantInitialDomain>.onmicrosoft.com/<string> or api://<verifiedCustomDomain>/<string>), and then use that same URI as webApplicationInfo.resource. The domain used there must be verified in each tenant where the app is registered and must match the domain constraints enforced by the Office add-in manifest. If the app must be multi-tenant and use a custom domain that is not verified in all tenants, the only supported way to avoid the restriction is for those tenants’ administrators to either:
   • Grant an exemption for the app to use a noncompliant identifier URI, or
   • Configure the app to use v2.0 tokens (by setting api.requestedAccessTokenVersion = 2), which are exempt from the policy by default, and then choose a compliant identifier URI pattern.
2. Is the manifest domain validation requirement configurable or expected to remain mandatory? The documentation for legacy Office SSO and the unified manifest treats the webApplicationInfo.resource rules (including the requirement that it be the Application ID URI and end with the client ID) as part of the SSO contract. There is no documented option to disable or relax the manifest’s domain-matching validation; it should be considered mandatory for this SSO model.
3. Recommended alternative authentication flows for tenants with stricter Identifier URI policies When the combination of:
   • Tenant identifier-URI protection policy, and
   • Office SSO manifest constraints
   cannot be satisfied (for example, because the required domain cannot be verified in the tenant and exemptions are not allowed), the recommended fallback is to avoid legacy Office SSO and use a non-SSO authentication flow in the add-in:
   • Use a standard OAuth 2.0 / OpenID Connect flow against Entra ID from the add-in’s web application, requesting Microsoft Graph or other API permissions at runtime as documented for modern add-ins.
   • Handle consent and token acquisition in the add-in’s own UI instead of relying on getAccessToken SSO.
   The troubleshooting guidance for legacy Office SSO explicitly notes that Microsoft Graph and other API permissions are requested at runtime in code, and that the add-in should fall back to alternate user authentication when SSO cannot be used or when consent is missing. For some scenarios, updating the app to accept v2.0 tokens and configuring api.requestedAccessTokenVersion = 2 can also unblock use of a compliant identifier URI while remaining on an SSO-based design, but this requires that the service be updated to handle v2.0 token semantics and cannot be reverted to v1.0 if noncompliant URIs are present without an exemption.

In summary, the conflict is expected behavior from both platforms. The supported patterns are:

• Use a tenant-verified or initial domain in the Application ID URI that also satisfies Office manifest validation, or
• Move to v2.0 tokens or request an exemption so that a non-default URI can be used, or
• Fall back to a non-SSO authentication flow in the add-in when neither of the above is acceptable.

References:

• Restrictions on identifier URIs of Microsoft Entra applications
• Understand the app manifest (Microsoft Graph format)
• Use legacy Office single sign-on (SSO) in an Office Add-in
• Troubleshoot error messages for legacy Office single sign-on (SSO)