Skip to content

[all hosts] (Identity) Rebrand AAD to Entra #5250

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions docs/design/authentication-patterns.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: Authentication design guidelines for Office Add-ins
ms.date: 08/14/2023
ms.date: 06/24/2025
ms.topic: best-practice
description: Learn how to visually design a sign-on or sign-up page in an Office Add-in.

Expand Down Expand Up @@ -32,7 +32,7 @@ Add-ins may require users to sign-in or sign-up in order to access features and

![The Identity Provider Choices dialog in an Office application.](../images/add-in-auth-choices-dialog.png)

1. Identity Provider Sign-in - The identity provider will have their own UI. Microsoft Azure Active Directory allows customization of sign-in and access panel pages for consistent look and feel with your service. [Learn More](/azure/active-directory/fundamentals/customize-branding).
1. Identity Provider Sign-in - The identity provider will have their own UI. Microsoft Entra allows customization of sign-in and access panel pages for consistent look and feel with your service. For more information, see [Configure your company branding](/entra/fundamentals/how-to-customize-branding).

![The Identity Provider Sign-in dialog in an Office application.](../images/add-in-auth-identity-sign-in.png)

Expand Down
4 changes: 2 additions & 2 deletions docs/develop/authorize-to-microsoft-graph.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
title: Authorize to Microsoft Graph with SSO
description: Learn how users of an Office Add-in can use single sign-on (SSO) to fetch data from Microsoft Graph.
ms.date: 01/22/2024
ms.date: 06/24/2025
ms.localizationpriority: medium
---

Expand Down Expand Up @@ -61,7 +61,7 @@ When a Microsoft 365 admin acquires an add-in from [AppSource](https://appsource
If your code passes the `allowConsentPrompt` option in the call of `getAccessToken`, like `OfficeRuntime.auth.getAccessToken( { allowConsentPrompt: true } );`, then Office can prompt the user for consent if the Microsoft identity platform reports to Office that consent has not yet been granted to the add-in. However, for security reasons, Office can only prompt the user to consent to the Microsoft Graph `profile` scope. *Office cannot prompt for consent to other Microsoft Graph scopes*, not even `User.Read`. This means that if the user grants consent on the prompt, Office returns an access token. But the attempt to exchange the access token for a new access token with additional Microsoft Graph scopes fails with error AADSTS65001, which means consent (to Microsoft Graph scopes) has not been granted.

> [!NOTE]
> The request for consent with `{ allowConsentPrompt: true }` could still fail even for the `profile` scope if the administrator has turned off end-user consent. For more information, see [Configure how end-users consent to applications using Azure Active Directory](/azure/active-directory/manage-apps/configure-user-consent).
> The request for consent with `{ allowConsentPrompt: true }` could still fail even for the `profile` scope if the administrator has turned off end-user consent. For more information, see [Configure how end-users consent to applications](/entra/identity/enterprise-apps/configure-user-consent).

Your code can, and should, handle this error by falling back to an alternate system of authentication, which prompts the user for consent to Microsoft Graph scopes. For code examples, see [Create a Node.js Office Add-in that uses single sign-on](create-sso-office-add-ins-nodejs.md) and [Create an ASP.NET Office Add-in that uses single sign-on](create-sso-office-add-ins-aspnet.md) and the samples they link to. The entire process requires multiple round trips to the Microsoft identity platform. To avoid this performance penalty, include the `forMSGraphAccess` option in the call of `getAccessToken`; for example, `OfficeRuntime.auth.getAccessToken( { forMSGraphAccess: true } )`. This signals to Office that your add-in needs Microsoft Graph scopes. Office will ask the Microsoft identity platform to verify that consent to Microsoft Graph scopes has already been granted to the add-in. If it has, the access token is returned. If it hasn't, then the call of `getAccessToken` returns error 13012. Your code can handle this error by falling back to an alternate system of authentication immediately, without making a doomed attempt to exchange tokens with the Microsoft identity platform.

Expand Down
2 changes: 1 addition & 1 deletion docs/develop/debug-office-add-ins-in-visual-studio.md
Original file line number Diff line number Diff line change
Expand Up @@ -142,7 +142,7 @@ This section describes how to start and debug an add-in in desktop Office on the
Start the project by choosing **Debug** > **Start Debugging** from the menu bar or press the <kbd>F5</kbd> button. Visual Studio automatically builds the solution and launches the Office application host page of your Microsoft 365 tenancy.

> [!NOTE]
> When you're debugging an add-in on the web, you may get an AADSTS50011 error similar to the following:
> When you're debugging an add-in on the web, you may get an AADSTS50011 error similar to the following:
>
> "The redirect URI `{Full absolute URL to add-in home page}` specified in the request doesn't match the redirect URIs configured for the application ... "
>
Expand Down
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
title: Enable single sign-on in an Office Add-in with nested app authentication
description: Learn how to enable SSO in an Office Add-in with nested app authentication.
ms.date: 12/23/2024
ms.date: 06/24/2025
ms.topic: how-to
ms.localizationpriority: high
---
Expand All @@ -17,7 +17,7 @@ You can use the MSAL.js library with nested app authentication to use single sig

## NAA supported accounts and hosts

NAA supports both Microsoft Accounts and Microsoft Entra ID (work/school) identities. It doesn't support Azure Active Directory B2C for business-to-consumer identity management scenarios. The following table explains the current support by platform. Platforms listed as generally available (GA) are ready for production usage in your add-in.
NAA supports both Microsoft Accounts and Microsoft Entra ID (work/school) identities. It doesn't support [Azure Active Directory B2C](/azure/active-directory-b2c/overview) for business-to-consumer identity management scenarios. The following table explains the current support by platform. Platforms listed as generally available (GA) are ready for production usage in your add-in.

| Application | Web | Windows | Mac | iOS/iPad | Android |
|-------------|------------|------------------------------------------------------|------------|--------------------|----------------|
Expand Down
4 changes: 2 additions & 2 deletions docs/develop/json-manifest-overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
title: Compare the add-in only manifest with the unified manifest for Microsoft 365
description: Get a comparison of the add-in only manifest with the unified manifest for Microsoft 365.
ms.topic: overview
ms.date: 02/12/2025
ms.date: 06/24/2025
ms.localizationpriority: high
---

Expand Down Expand Up @@ -68,7 +68,7 @@ The base manifest properties specify characteristics of the add-in that *any* ty
|[`"accentColor"`](/microsoft-365/extensibility/schema/root#accentcolor)|*None* |*None* | This property has no equivalent in the add-in only manifest and isn't used in the unified manifest. But it must be present. |
|[`"developer"`](/microsoft-365/extensibility/schema/root#developer)| Identifies the developer of the add-in. | **\<ProviderName\>** |*None* |
|[`"localizationInfo"`](/microsoft-365/extensibility/schema/root#localizationinfo)| Configures the default locale and other supported locales. | **\<DefaultLocale\>** and **\<Override\>** |*None* |
|[`"webApplicationInfo"`](/microsoft-365/extensibility/schema/root#webApplicationInfo-property)| Identifies the add-in's web app as it is known in Azure Active Directory. | **\<WebApplicationInfo\>** | In the add-in only manifest, the **\<WebApplicationInfo\>** element is inside **\<VersionOverrides\>**, not the base manifest. |
|[`"webApplicationInfo"`](/microsoft-365/extensibility/schema/root#webApplicationInfo-property)| Identifies the add-in's web app as it is known in Microsoft Entra. | **\<WebApplicationInfo\>** | In the add-in only manifest, the **\<WebApplicationInfo\>** element is inside **\<VersionOverrides\>**, not the base manifest. |
|[`"authorization"`](/microsoft-365/extensibility/schema/root#authorization)| Identifies any Microsoft Graph permissions that the add-in needs. | **\<WebApplicationInfo\>** | In the add-in only manifest, the **\<WebApplicationInfo\>** element is inside **\<VersionOverrides\>**, not the base manifest. |

The **\<Hosts\>**, **\<Requirements\>**, and **\<ExtendedOverrides\>** elements are part of the base manifest in the add-in only manifest. But concepts and purposes associated with these elements are configured inside the `"extensions"` property of the unified manifest.
Expand Down
2 changes: 1 addition & 1 deletion docs/develop/overview-authn-authz.md
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,7 @@ Before you begin implementing user authentication with SSO, be sure that you're

### Access your Web APIs through SSO

If your add-in has server-side APIs that require an authorized user, call the [getAccessToken](/javascript/api/office-runtime/officeruntime.auth#office-runtime-officeruntime-auth-getaccesstoken-member(1)) method to get an access token. The access token provides access to your own web server (configured through a [Microsoft Azure app registration](register-sso-add-in-aad-v2.md)). When you call APIs on your web server, you also pass the access token to authorize the user.
If your add-in has server-side APIs that require an authorized user, call the [getAccessToken](/javascript/api/office-runtime/officeruntime.auth#office-runtime-officeruntime-auth-getaccesstoken-member(1)) method to get an access token. The access token provides access to your own web server (configured through a [Microsoft Entra app registration](register-sso-add-in-aad-v2.md)). When you call APIs on your web server, you also pass the access token to authorize the user.

The following code shows how to construct an HTTPS GET request to the add-in's web server API to get some data. The code runs on the client side, such as in a task pane. It first gets the access token by calling `getAccessToken`. Then it constructs an AJAX call with the correct authorization header and URL for the server API.

Expand Down
18 changes: 9 additions & 9 deletions docs/develop/troubleshoot-sso-in-office-add-ins.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
title: Troubleshoot error messages for single sign-on (SSO)
description: Guidance about how to troubleshoot problems with single sign-on (SSO) in Office Add-ins, and handle special conditions or errors.
ms.date: 02/07/2024
ms.date: 06/24/2025
ms.localizationpriority: medium
---

Expand Down Expand Up @@ -43,7 +43,7 @@ The user isn't signed into Office. In most scenarios, you should prevent this er

But there may be exceptions. For example, you want the add-in to open with features that require a logged in user; but *only if* the user is *already* logged into Office. If the user isn't logged in, you want the add-in to open with an alternate set of features that do not require that the user is signed in. In this case, logic which runs when the add-in launches calls `getAccessToken` without `allowSignInPrompt: true`. Use the 13001 error as the flag to tell the add-in to present the alternate set of features.

Another option is to respond to 13001 by falling back to an alternate system of user authentication. This will sign the user into AAD, but not sign the user into Office.
Another option is to respond to 13001 by falling back to an alternate system of user authentication. This will sign the user into Microsoft Entra, but not sign the user into Office.

This error doesn't typically occur in Office on the web. If the user's cookie expires, Office on the web returns [error 13006](#13006). However, if a user accesses Outlook on the web from Firefox with Enhanced Tracking Protection turned on, they'll encounter error 13001.

Expand Down Expand Up @@ -80,8 +80,8 @@ The Office application was unable to get an access token to the add-in's web ser
- In production, an account mismatch could cause this error. For example, if the user attempts to sign in with a personal Microsoft account (MSA) when a Work or school account was expected. For these cases, your code should fall back to an alternate system of user authentication. For more information on account types, see [Identity and account types for single- and multi-tenant apps](/security/zero-trust/develop/identity-supported-account-types).
- Make sure your application is enabled for users to sign-in for your organization.
1. Sign in to the [Microsoft Azure portal](https://portal.azure.com/).
2. Go to your add-in's app registration.
3. On the **Overview** page, select **Managed application in local directory**.
1. Go to your add-in's app registration.
1. On the **Overview** page, select **Managed application in local directory**.
:::image type="content" source="../images/azure-portal-managed-application.png" alt-text="The Managed application in local directory option in the App Registration Overview window.":::
1. Select **Manage** > **Properties**, and ensure that the value of **Enabled for users to sign-in?** is **Yes**.
:::image type="content" source="../images/azure-portal-enable-sign-in.png" alt-text="The option to allow users in the organization to sign-in to an application in the Properties window.":::
Expand All @@ -100,7 +100,7 @@ There are several possible causes.

- The add-in is running on a platform that does not support the `getAccessToken` API. For example, it isn't supported on iPad. See also [Identity API requirement sets](/javascript/api/requirement-sets/common/identity-api-requirement-sets).
- The Office document was opened from the **Files** tab of a Teams channel using the **Edit in Teams** option on the **Open** dropdown menu. The `getAccessToken` API isn't supported in this scenario.
- The `forMSGraphAccess` option was passed in the call to `getAccessToken` and the user obtained the add-in from AppSource. In this scenario, the tenant admin has not granted consent to the add-in for the Microsoft Graph scopes (permissions) that it needs. Recalling `getAccessToken` with the `allowConsentPrompt` will not solve the problem because Office is allowed to prompt the user for consent to only the AAD `profile` scope.
- The `forMSGraphAccess` option was passed in the call to `getAccessToken` and the user obtained the add-in from AppSource. In this scenario, the tenant admin has not granted consent to the add-in for the Microsoft Graph scopes (permissions) that it needs. Recalling `getAccessToken` with the `allowConsentPrompt` will not solve the problem because Office is allowed to prompt the user for consent to only the Entra `profile` scope.

Your code should fall back to an alternate system of user authentication.

Expand All @@ -116,7 +116,7 @@ This error (which isn't specific to `getAccessToken`) may indicate that the brow

In a production add-in, the add-in should respond to this error by falling back to an alternate system of user authentication. For more information, see [Requirements and Best Practices](../develop/sso-in-office-add-ins.md#requirements-and-best-practices).

## Errors on the server-side from Azure Active Directory
## Errors on the server-side from Microsoft Entra

For samples of the error-handling described in this section, see:

Expand All @@ -125,15 +125,15 @@ For samples of the error-handling described in this section, see:

### Conditional access / Multifactor authentication errors

In certain configurations of identity in AAD and Microsoft 365, it is possible for some resources that are accessible with Microsoft Graph to require multifactor authentication (MFA), even when the user's Microsoft 365 tenancy does not. When AAD receives a request for a token to the MFA-protected resource, via the on-behalf-of flow, it returns to your add-in's web service a JSON message that contains a `claims` property. The claims property has information about what further authentication factors are needed.
In certain configurations of identity in Entra and Microsoft 365, it is possible for some resources that are accessible with Microsoft Graph to require multifactor authentication (MFA), even when the user's Microsoft 365 tenancy does not. When Entra receives a request for a token to the MFA-protected resource, via the on-behalf-of flow, it returns to your add-in's web service a JSON message that contains a `claims` property. The claims property has information about what further authentication factors are needed.

Your code should test for this `claims` property. Depending on your add-in's architecture, you may test for it on the client-side, or you may test for it on the server-side and relay it to the client. You need this information in the client because Office handles authentication for SSO add-ins. If you relay it from the server-side, the message to the client can be either an error (such as `500 Server Error` or `401 Unauthorized`) or in the body of a success response (such as `200 OK`). In either case, the (failure or success) callback of your code's client-side AJAX call to your add-in's web API should test for this response.

Regardless of your architecture, if the claims value has been sent from AAD, your code should recall `getAccessToken` and pass the option `authChallenge: CLAIMS-STRING-HERE` in the `options` parameter. When AAD sees this string, it prompts the user for the additional factors and then returns a new access token which will be accepted in the on-behalf-of flow.
Regardless of your architecture, if the claims value has been sent from Entra, your code should recall `getAccessToken` and pass the option `authChallenge: CLAIMS-STRING-HERE` in the `options` parameter. When Entra sees this string, it prompts the user for the additional factors and then returns a new access token which will be accepted in the on-behalf-of flow.

### Consent missing errors

If AAD has no record that consent (to the Microsoft Graph resource) was granted to the add-in by the user (or tenant administrator), AAD will send an error message to your web service. Your code must tell the client (in the body of a `403 Forbidden` response, for example).
If Entra has no record that consent (to the Microsoft Graph resource) was granted to the add-in by the user (or tenant administrator), Entra will send an error message to your web service. Your code must tell the client (in the body of a `403 Forbidden` response, for example).

If the add-in needs Microsoft Graph scopes that can only be consented to by an admin, your code should throw an error. If the only scopes that are needed can be consented to by the user, then your code should fall back to an alternate system of user authentication.

Expand Down
4 changes: 2 additions & 2 deletions docs/develop/unified-manifest-overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
title: Office Add-ins with the unified app manifest for Microsoft 365
description: Get an overview of the unified app manifest for Microsoft 365 for Office Add-ins and its uses.
ms.topic: overview
ms.date: 06/19/2025
ms.date: 06/24/2025
ms.localizationpriority: high
---

Expand Down Expand Up @@ -45,7 +45,7 @@ Each of the base properties listed in the following table has more extensive doc
|[`"developer"`](/microsoft-365/extensibility/schema/root#developer)| Information about the developer of the Teams app/add-in. |
|[`"localizationInfo"`](/microsoft-365/extensibility/schema/root#localizationinfo)| Configures the default locale and other supported locales. |
|[`"validDomains"`](/microsoft-365/extensibility/schema/root#validdomains) | See [Specify safe domains](#specify-safe-domains). |
|[`"webApplicationInfo"`](/microsoft-365/extensibility/schema/root#webApplicationInfo-property)| Identifies the Teams app/add-in's web app as it is known in Azure Active Directory. |
|[`"webApplicationInfo"`](/microsoft-365/extensibility/schema/root#webApplicationInfo-property)| Identifies the Teams app/add-in's web app as it is known in Microsoft Entra. |
|[`"authorization"`](/microsoft-365/extensibility/schema/root#authorization)| Identifies any Microsoft Graph permissions that the add-in needs. |

### `"extensions"` property
Expand Down
Loading