[BULK] - DocuTune - Rebranding of Azure Active Directory to Microsoft Entra terminology

msal-python-conceptual/TOC.yml

@@ -1,7 +1,7 @@
 - name: Getting started
   href: index.md
   items:
-  - name: Register your app with Azure AD
+  - name: Register your app with Microsoft Entra ID
     href: /azure/active-directory/develop/active-directory-integrating-applications
   - name: Client applications
     href: getting-started/client-applications.md
@@ -45,7 +45,7 @@
   items:
   - name: Releases
     href: https://github.com/AzureAD/microsoft-authentication-library-for-python/releases
-  - name: Azure AD Developer Guide
+  - name: Microsoft Entra Developer Guide
     href: https://aka.ms/aaddevv2
   - name: Code samples
     href: /azure/active-directory/develop/sample-v2-code

msal-python-conceptual/advanced/aad-b2c.md

@@ -9,7 +9,7 @@ description: "You can use MSAL Python to sign-in users with social identities, a
 
 You can use MSAL Python to sign-in users with social identities, acquire tokens, and customize the sign-in experience by using [Azure AD B2C](https://aka.ms/aadb2c).
 
-AAD B2C is built around the notion of [User Flows](/azure/active-directory-b2c/active-directory-b2c-reference-policies) (formerly known as policies). In MSAL Python, specifying a user flow translates to providing an authority.
+Azure AD B2C is built around the notion of [User Flows](/azure/active-directory-b2c/active-directory-b2c-reference-policies) (formerly known as policies). In MSAL Python, specifying a user flow translates to providing an authority.
 
 * When you instantiate the client application, you need to specify the user flow in authority as
   `https://{tenant_name}.b2clogin.com/{tenant_name}.onmicrosoft.com/{user_flow}`.
@@ -62,7 +62,7 @@ app.acquire_token_by_xyz(...)  # Same as in non-B2C scenarios
 
 > There is no need to filter accounts by user flow,
 as long as you are following a pattern of
-"create different msal app for different user flow"
+"create different MSAL app for different user flow"
 (because the B2C user flow is designed to behave like an isolated authority).
 In practice, you will still typically reuse same MSAL app and its token cache for the SignIn user flow,
 and only create new one-time MSAL app when invoking EditProfile or ResetPassword user flows,
@@ -97,7 +97,7 @@ The following content serves as a mini-tutorial.
 * In your AzureAD B2C tenant, create a new user flow and select **Sign in using ROPC**.
 This will enable the ROPC user flow for your tenant.
 See [Configure the resource owner password credentials flow](/azure/active-directory-b2c/configure-ropc) for more details.
-* Once you create the msal instance with the authority which contains the ROPC user flow,
+* Once you create the MSAL instance with the authority which contains the ROPC user flow,
 the [`acquire_token_by_username_password(...)`](https://msal-python.readthedocs.io/en/latest/#msal.PublicClientApplication.acquire_token_by_username_password)
 would work as usual.
 * Limitations: This **only works for local accounts** (where you register with B2C using an email or username). This flow does not work if federating to any of the IdPs supported by B2C (Facebook, Google, etc...).

msal-python-conceptual/advanced/best-practices.md

@@ -9,6 +9,6 @@ You've seen that with MSAL Python you can quite simply acquire a token for a pro
 
 However, to build robust, enterprise ready applications, you will need to do a bit more. For instance you'll want to:
 
-* [Handle exceptions](/azure/active-directory/develop/msal-handling-exceptions?tabs=python), both when you acquire a token, but also when you call the protected Web API. In particular, if your application runs in an Azure AD tenant where the tenant admins have set [Conditional Access](https://github.com/AzureAD/microsoft-authentication-library-for-python/wiki/Conditional-Access-and-Claims-Challenges) policies to enforce Multiple Factor Authentication (MFA), you will need to handle a Claim challenge.
+* [Handle exceptions](/azure/active-directory/develop/msal-handling-exceptions?tabs=python), both when you acquire a token, but also when you call the protected Web API. In particular, if your application runs in a Microsoft Entra tenant where the tenant admins have set [Conditional Access](https://github.com/AzureAD/microsoft-authentication-library-for-python/wiki/Conditional-Access-and-Claims-Challenges) policies to enforce Multiple Factor Authentication (MFA), you will need to handle a Claim challenge.
 
 * You might want to enable [Logging](/azure/active-directory/develop/msal-logging?tabs=python) to troubleshoot your application and help your users, while respecting their privacy and being compliant with GDPR.

msal-python-conceptual/advanced/client-capabilities.md

@@ -1,22 +1,22 @@
 ---
 title: Client capabilities
-description: "The Azure AD service provides features and policies which are applicable in certain scenarios, such as conditional access policies."
+description: "The Microsoft Entra service provides features and policies which are applicable in certain scenarios, such as conditional access policies."
 ---
 
 # Client capabilities
 
-The Azure AD service provides features and policies which are applicable in certain scenarios, such as [conditional access](./conditional-access.md) policies. The Azure AD service needs to determine if a client application is participating in the feature or capable of handling the policy, for the end to end scenario to work.
+The Microsoft Entra service provides features and policies which are applicable in certain scenarios, such as [conditional access](./conditional-access.md) policies. The Microsoft Entra service needs to determine if a client application is participating in the feature or capable of handling the policy, for the end to end scenario to work.
 
-- The **client capabilities** parameter in the application object allows client applications to indicate their compliance with a scenario and readiness to handle the policies or features, so that Azure AD can apply them for the client. 
+- The **client capabilities** parameter in the application object allows client applications to indicate their compliance with a scenario and readiness to handle the policies or features, so that Microsoft Entra ID can apply them for the client. 
 
-    For example, in the context of conditional access scenario, adding client capability `CP1` will mean that the client is capable of handling a `claims challenge` from the resource provider(ex: MS Graph). Thus, Azure AD STS (Security token service) will emit claims in the access token that may lead to claims challenge from a resource provider (ex: MS Graph).
+    For example, in the context of conditional access scenario, adding client capability `CP1` will mean that the client is capable of handling a `claims challenge` from the resource provider(ex: MS Graph). Thus, Microsoft Entra STS (Security token service) will emit claims in the access token that may lead to claims challenge from a resource provider (ex: MS Graph).
 
 - These capabilities are set when creating the application object using the `client_capabilities` parameter which is a list of client capability strings.
 
     ```python
     app = msal.PublicClientApplication(client_id="client_id", authority="your_authority", client_capabilities = ["CP1"])
     ```
 
-- Once these are set at the application level, they will be sent in all the requests to the Azure AD authorize and token endpoints. 
+- Once these are set at the application level, they will be sent in all the requests to the Microsoft Entra authorize and token endpoints. 
 - When setting a capability, the client application should make sure that the policy or feature is handled in the application.
   - In the above example,  when such a capability(`CP1`) is set on the application object, the client application should make sure that a claims challenge from the resource provider(ex: MS Graph) is handled in the application. You can read more details about it in [handling the claims challenge ](./conditional-access.md#handling-claim-challenge-in-msal-python).

msal-python-conceptual/advanced/client-credentials.md

@@ -12,23 +12,23 @@ There are two types of client credentials in MSAL Python:
 
 ## Client Credentials with application secret
 
-During the registration of a confidential client application with Azure AD, a client secret is generated (a kind of application password).
+During the registration of a confidential client application with Microsoft Entra ID, a client secret is generated (a kind of application password).
 
 ### Registering client secrets using the application registration portal
 
 The management of client credentials happens in the **certificates & secrets** page for an application:
 
 ![image](https://user-images.githubusercontent.com/13203188/49435190-4f385300-f7b6-11e8-8a83-7e468e5fd124.png)
 
-- the application secret (also named client secret) is generated by Azure AD during the registration of the confidential client application when you select **New client secret**. At that point, you must copy the secret string in the clipboard for use in your app, before selecting **Save**. This string won't be presented to you again in the future.
+- the application secret (also named client secret) is generated by Microsoft Entra ID during the registration of the confidential client application when you select **New client secret**. At that point, you must copy the secret string in the clipboard for use in your app, before selecting **Save**. This string won't be presented to you again in the future.
 
 ### Using client secrets
 
 In MSAL Python client credentials are similar to what they are in ADAL Python, except that the client credentials are passed as a parameter at the application construction. In this case client secret is passed as an parameter. Then, once the confidential client application is constructed, `acquire_token_for_client` is called with scope as parameter.
 
 ## Client Credentials with certificate
 
-When the application is registered with Azure AD, it uploads the public key of a certificate. At application construction, `thumbprint` and `private_key_file` is passed as the client credential. When it wants to acquire a token, the client application will need to call the `acquire_token_for_client` method by passing the scope as parameter.
+When the application is registered with Microsoft Entra ID, it uploads the public key of a certificate. At application construction, `thumbprint` and `private_key_file` is passed as the client credential. When it wants to acquire a token, the client application will need to call the `acquire_token_for_client` method by passing the scope as parameter.
 
 Steps to generate certificate and private key to be used when implementing the client credential flow are as follows:
 

msal-python-conceptual/advanced/migrate-python-adal-msal.md

@@ -15,7 +15,7 @@ ADAL works with the Azure Active Directory (Azure AD) v1.0 endpoint. The Microso
 
 Supports:
 
-- Work and school accounts (Azure AD provisioned accounts)
+- Work and school accounts (Microsoft Entra ID provisioned accounts)
 - Personal accounts (such as Outlook.com or Hotmail.com)
 - Your customers who bring their own email or social identity (such as LinkedIn, Facebook, Google) via the Azure AD B2C offering
 
@@ -105,4 +105,4 @@ for old_rt, scopes in get_preexisting_rt_and_their_scopes_from_elsewhere():
         print("Discarding unsuccessful RT. Error: ", json.dumps(result, indent=2))
 
 print("Migration completed")
-```
+```

msal-python-conceptual/advanced/msal-error-handling-python.md

@@ -50,7 +50,7 @@ In certain cases when calling an API requiring Conditional Access, you can recei
 
 ## Retrying after errors and exceptions
 
-MSAL makes HTTP calls to the Azure AD service, and occasionally failures can occur.
+MSAL makes HTTP calls to the Microsoft Entra service, and occasionally failures can occur.
 For example the network can go down or the server is overloaded.
 
 MSAL Python 1.11+ automatically performs one retry attempt for you.

msal-python-conceptual/advanced/msal-python-adfs-support.md

@@ -9,7 +9,7 @@ Active Directory Federation Services (AD FS) in Windows Server enables you to ad
 
 There are usually two ways of authenticating against AD FS:
 
-- MSAL Python talks to Azure Active Directory, which itself is federated with other identity providers. The federation happens through AD FS. MSAL Python connects to Azure AD, which signs in users that are managed in Azure AD (managed users) or users managed by another identity provider such as AD FS (federated users). MSAL Python doesn't  know that a user is federated. It simply talks to Azure AD. The [authority](/azure/active-directory/develop/msal-client-application-configuration#authority) you use in this case is the usual authority (authority host name + tenant, common, or organizations).
+- MSAL Python talks to Microsoft Entra ID, which itself is federated with other identity providers. The federation happens through AD FS. MSAL Python connects to Microsoft Entra ID, which signs in users that are managed in Microsoft Entra ID (managed users) or users managed by another identity provider such as AD FS (federated users). MSAL Python doesn't  know that a user is federated. It simply talks to Microsoft Entra ID. The [authority](/azure/active-directory/develop/msal-client-application-configuration#authority) you use in this case is the usual authority (authority host name + tenant, common, or organizations).
 - MSAL Python talks directly to an AD FS authority. This is only supported by AD FS 2019 and later.
 
 ## Connect to Active Directory federated with AD FS
@@ -21,7 +21,7 @@ The following applies whether you connect directly to Active Directory Federatio
 When you call `acquire_token_by_authorization_code` or `acquire_token_by_device_flow`, the user experience is typically as follows:
 
 1. The user enters their account ID.
-2. Azure AD displays briefly the message "Taking you to your organization's page" and the user is redirected to the sign-in page of the identity provider. The sign-in page is usually customized with the logo of the organization.
+2. Microsoft Entra ID displays briefly the message "Taking you to your organization's page" and the user is redirected to the sign-in page of the identity provider. The sign-in page is usually customized with the logo of the organization.
 
 The supported AD FS versions in this federated scenario are:
 - Active Directory Federation Services FS v2
@@ -32,10 +32,10 @@ The supported AD FS versions in this federated scenario are:
 
 The following applies whether you connect directly to Active Directory Federation Services (AD FS) or through Active Directory.
 
-When you acquire a token using `acquire_token_by_username_password`, MSAL Python gets the identity provider to contact based on the username. MSAL Python gets a [SAML 1.1 token](/azure/active-directory/develop/reference-saml-tokens) from the identity provider, which it then provides to Azure AD which returns the JSON Web Token (JWT).
+When you acquire a token using `acquire_token_by_username_password`, MSAL Python gets the identity provider to contact based on the username. MSAL Python gets a [SAML 1.1 token](/azure/active-directory/develop/reference-saml-tokens) from the identity provider, which it then provides to Microsoft Entra which returns the JSON Web Token (JWT).
 
 ## Connecting directly to AD FS
 
 When you connect directory to AD FS, the authority you'll want to use to build your application will be something like `https://somesite.contoso.com/adfs/`
 
-MSAL Python supports ADFS 2019, but does not support a direct connection to ADFS 2016 or ADFS v2. Once you have upgraded your on-premises system to ADFS 2019, you can use MSAL Python.
+MSAL Python supports ADFS 2019, but does not support a direct connection to ADFS 2016 or ADFS v2. Once you have upgraded your on-premises system to ADFS 2019, you can use MSAL Python.

msal-python-conceptual/advanced/username-password-authentication.md

@@ -16,8 +16,8 @@ In general Microsoft does not advise customers to use it as it's less secure tha
 * By design and policy, the username/password authentication works only for Work and school accounts, but not for Microsoft Accounts (MSA).
   See the [definition of these 2 types of accounts here](/azure/active-directory/fundamentals/sign-up-organization).
 * The Username/Password authentication is not compatible with conditional access and multi-factor authentication,
-  because this is not an interactive flow, the Microsoft Identity platform does not have an opportunity to present a web-based dialog for the end user to interact.
-  As a consequence, if your app runs in an Azure AD tenant where the tenant admin requires multi-factor authentication (many organizations do that), this flow will not work.
+  because this is not an interactive flow, the Microsoft identity platform does not have an opportunity to present a web-based dialog for the end user to interact.
+  As a consequence, if your app runs in a Microsoft Entra tenant where the tenant admin requires multi-factor authentication (many organizations do that), this flow will not work.
 * Because Username Password Authentication is a non-interactive flow:
   - the user of your application must have previously consented to use the application 
   - or the tenant admin must have previously consented to all users in the tenant to use the application.

msal-python-conceptual/getting-started/acquiring-tokens.md

@@ -21,15 +21,15 @@ Public client applications cannot securely store a secret and can _only_ authent
 
 - Acquire tokens **as the user** with the help of an [interactive flow](/azure/active-directory/develop/scenario-desktop-acquire-token?tabs=python#acquiring-a-token-interactively) after letting the user sign-in through the authorization request URL.
 - It's also possible (but not recommended) to get a token with a [username and password](/azure/active-directory/develop/scenario-desktop-acquire-token?tabs=python#username--password).
-- For applications running on devices which don't have a web browser, it's possible to acquire a token through the [device code flow](/azure/active-directory/develop/scenario-desktop-acquire-token?tabs=python#command-line-tool-without-web-browser), which provides the user with a URL and a code. The user goes to a web browser on another device, enters the code and signs in. On successful authentication, Azure AD will return a token to the browser-less device.
+- For applications running on devices which don't have a web browser, it's possible to acquire a token through the [device code flow](/azure/active-directory/develop/scenario-desktop-acquire-token?tabs=python#command-line-tool-without-web-browser), which provides the user with a URL and a code. The user goes to a web browser on another device, enters the code and signs in. On successful authentication, Microsoft Entra ID will return a token to the browser-less device.
 
 ### Confidential client applications
 
 Confidential client applications can securely store a secret and can authenticate both on behalf of an application as well as on behalf of a given user. With MSAL Python, developers can use [`ConfidentialClientApplication`](xref:msal.application.ConfidentialClientApplication) to access confidential client application capabilities, such as:
 
 - Acquire token **as the application itself** using [client credentials](/azure/active-directory/develop/scenario-daemon-acquire-token?tabs=python#acquiretokenforclient-api), and not for a user. For example, this can be used in applications which process users in batches and not one particular user, such as syncing tools.
 - In the case of web Apps or web APIs **calling another downstream Web API in the name of the user**, use the [On Behalf Of flow](/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow) to acquire a token based on a user assertion (e.g., SAML, JWT).
-- **For Web apps authenticating in the name of a user**, acquire tokens through [authorization code](/azure/active-directory/develop/scenario-web-app-call-api-acquire-token?tabs=python) after letting the user sign-in through the authorization request URL. This is typically the mechanism used by an application which lets the user sign-in using Open ID Connect but then wants to access Web APIs for this particular user.
+- **For Web apps authenticating in the name of a user**, acquire tokens through [authorization code](/azure/active-directory/develop/scenario-web-app-call-api-acquire-token?tabs=python) after letting the user sign-in through the authorization request URL. This is typically the mechanism used by an application which lets the user sign-in using OpenID Connect but then wants to access Web APIs for this particular user.
 
 ## MSAL Python token caching