Merge branch 'main' into cilwerner/docutune-autopr-20240327-165804-6590790-ignore-build

Author: localden

.openpublishing.publish.config.json

@@ -91,5 +91,8 @@
   "branch_target_mapping": {},
   "skip_source_output_uploading": false,
   "contribution_branch_mappings": {},
-  "need_generate_pdf_url_template": true
+  "need_generate_pdf_url_template": true,
+  "redirection_files": [
+    "redirections/.openpublishing.redirection.simplify-package-structure.json"
+  ]
 }

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

@@ -99,17 +99,17 @@ You would just need to update your HTML template to include new link to, for exa
 
 ## Resource Owner Password Credentials (ROPC) With B2C
 
-There is still no API difference here between B2C and non-B2C scenario.
-The following content serves as a mini-tutorial.
+There exists no API difference between a B2C and non-B2C scenario. The following content serves as a mini-tutorial.
 
-* In your AzureAD B2C tenant, create a new user flow and select **Sign in using ROPC**.
+* In your Azure AD 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,
 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...).
-* Normal caveats on ROPC flow still applies. Please see this [wiki page](https://github.com/AzureAD/microsoft-authentication-library-for-python/wiki/Username-Password-Authentication).
+
+Microsoft [discourages the use of resource owner password credentials grant](https://news.microsoft.com/features/whats-solution-growing-problem-passwords-says-microsoft/). In most scenarios, more secure alternatives are available and recommended. This flow requires a very high degree of trust in the application, and carries risks that are not present in other flows. You should only use this flow when other more secure flows aren't viable. Learn more in the [username and password ](username-password-authentication.md) guidance.
 
 ## Caching with B2C in MSAL Python
 

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

@@ -41,7 +41,8 @@ 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 Microsoft Entra 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). We do not recommend the username and password flow as it presents security risks that are not present in other flows. For more information about why you want to avoid using this grant, see [why Microsoft is working to make passwords a thing of the past](https://news.microsoft.com/features/whats-solution-growing-problem-passwords-says-microsoft/). 
+
 
 ## Connecting directly to AD FS
 

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

@@ -16,9 +16,9 @@ ms.reviewer: shermanouko, rayluo
 
 The content below are applicable to [all MSAL libraries](/entra/msal), not just MSAL Python.
 
-## Using username and password is not recommended
+## The username and password flow is not recommended
 
-In general Microsoft does not advise customers to use it as it's less secure than the other flows. For more information about why you want to avoid using this grant you can read [why Microsoft is working to make passwords a thing of the past](https://news.microsoft.com/features/whats-solution-growing-problem-passwords-says-microsoft/).
+Microsoft recommends you do not use the username and password flow. In most scenarios, more secure alternatives are available and recommended. This flow requires a very high degree of trust in the application, and carries risks that are not present in other flows. You should only use this flow when other more secure flows aren't viable. For more information about why you want to avoid using this grant, see [why Microsoft is working to make passwords a thing of the past](https://news.microsoft.com/features/whats-solution-growing-problem-passwords-says-microsoft/).
 
 ## Constraints