MicrosoftDocs · localden · May 23, 2024 · May 21, 2024
@@ -47,6 +47,10 @@ Supported ADFS versions in this federated scenario are ADFS v2 , ADFS v3 (Window
 
 When acquiring a token using the `AcquireTokenByIntegratedAuthentication` or `AcquireTokenByUsernamePassword` methods, MSAL.NET gets the identity provider to contact based on the username.  MSAL.NET receives a [SAML 1.1 token](/azure/active-directory/develop/reference-saml-tokens) after contacting the identity provider.  MSAL.NET then provides the SAML token to Microsoft Entra ID as a user assertion (similar to the [on-behalf-of flow](../web-apps-apis/on-behalf-of-flow.md) to get back a JWT.
 
+
+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/).
+
+
 ## Case where MSAL connects directly to ADFS
 
 MSAL.NET supports connecting to AD FS 2019, which is OpenID Connect compliant and understands PKCE and scopes. This support requires that a service pack [KB 4490481](https://support.microsoft.com/help/4490481/windows-10-update-kb4490481) is applied to Windows Server. When connecting directly to AD FS, the authority you'll want to use to build your application is similar to `https://mysite.contoso.com/adfs/`.

@@ -9,7 +9,7 @@ ms.service: msal
 ms.subservice: msal-dotnet
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 08/24/2023
+ms.date: 05/21/2024
 ms.author: dmwendia
 ms.reviewer: ddelimarsky, saeeda, jeferrie
 ms.custom: devx-track-csharp, aaddev, devx-track-dotnet
@@ -148,21 +148,22 @@ Or whichever special logic you were doing to process the `AADB2C90118` error.
 
 ## Resource Owner Password Credentials (ROPC) With B2C
 
-For more details on the ROPC flow, please see this [documentation](./username-password-authentication.md).
+For more details on the ROPC flow, please see the [username and password flow documentation](./username-password-authentication.md).
 
 ### This flow is not recommended
 
-This flow is **not recommended** because your application asking a user for their password is not secure. For more information about this problem, see [this article](https://news.microsoft.com/features/whats-solution-growing-problem-passwords-says-microsoft/).
+This flow is **not recommended** because your application asking a user for their password is not secure. For more information about this problem, 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/).
+
 
 By using username/password you are giving-up a number of things:
 
 - Core tenants of modern identity: password gets fished, replayed. Because we have this concept of a share secret that can be intercepted. This is incompatible with passwordless.
 - Users who need to do MFA won't be able to sign-in (as there is no interaction)
 - Users won't be able to do single sign-on
 
-### Configure the ROPC flow in AzureAD B2C
+### Configure the ROPC flow in Azure AD B2C
 
-In your AzureAD B2C tenant, create a new user flow and select **Sign in using ROPC**. This will enable the ROPC policy for your tenant. See [Configure the resource owner password credentials flow](/azure/active-directory-b2c/configure-ropc) for more details.
+In your Azure AD B2C tenant, create a new user flow and select **Sign in using ROPC**. This will enable the ROPC policy for your tenant. See [Configure the resource owner password credentials flow](/azure/active-directory-b2c/configure-ropc) for more details.
 
 `IPublicClientApplication` contains a method called `AcquireTokenByUsernamePassword`:
 
@@ -191,7 +192,7 @@ If you are a B2C developer using Google as an identity provider we recommend you
 
 ## Caching with B2C in MSAL.NET
 
-### Known issue with Azure B2C
+### Known issue with Azure AD B2C
 
 MSAL.Net supports a [token cache](/dotnet/api/microsoft.identity.client.tokencache). The token caching key is based on the claims returned by the Identity Provider. Currently MSAL.Net needs two claims to build a token cache key:
 

@@ -152,7 +152,7 @@ ms-appx-web://microsoft.aad.brokerplugin/{client_id}
 This flow, also known as Resource Owner Password Credentials (ROPC), is not recommended except in test scenarios or in scenarios where service principal access to a resource gives it too much access and you can only scope it down with user flows. When using WAM, [`AcquireTokenByUsernamePassword`](xref:Microsoft.Identity.Client.PublicClientApplication.AcquireTokenByUsernamePassword*) will let WAM manage the protocol and fetch tokens.
 
 >[!WARNING]
->There are a few important considerations that you need to account for when using the ROPC flow. One of the main ones is that it **doesn't support personal Microsoft accounts** and **Microsoft Entra accounts with enabled multi-factor authentication**. Check out [Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials](/azure/active-directory/develop/v2-oauth-ropc) for the full overview.
+>Microsoft does not recommend using the username and password flow as the application will be asking a user for their password directly, which is an insecure pattern. Additionally, the ROPC flow **doesn't support personal Microsoft accounts** and **Microsoft Entra accounts with enabled multi-factor authentication**. Check out [Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials](/azure/active-directory/develop/v2-oauth-ropc) for the full overview.
 
 ## WAM limitations
 

@@ -8,10 +8,10 @@ ms.service: msal
 ms.subservice: msal-dotnet
 ms.topic: reference
 ms.workload: identity
-ms.date: 03/17/2023
+ms.date: 05/20/2024
 ms.author: dmwendia
 ms.reviewer: localden
-ms.custom: devx-track-csharp, aaddev, engagement-fy23
+ms.custom: devx-track-csharp, aaddev
 # Customer intent: As an application developer, I want to learn how to acquire security tokens in public and confidential client applications using MSAL.NET
 ---
 

@@ -25,9 +25,9 @@ Pros: end to end testing with real tokens
 
 Cons: UI automation is flaky. It's tedious to automate the login screens. Live accounts and "Work and School" have slightly different UI flows.
 
-**Strategy 2**: Use ROPC (Username/Password flow) to get tokens and test only your controllers
+**Strategy 2**: Use ROPC (Username/Password flow) to get tokens and test only your controllers. Microsoft does not recommend using the ROPC flow in production as it presents some security risks not present in other flows. Use this flow for testing purposes only.
 
-Pros: no ui automation
+Pros: No ui automation
 
 Cons: Does not work for Live accounts, where ROPC is not supported.
 

@@ -1,7 +1,6 @@
 ---
 title: MSAL.NET scenarios
 description: Learn the application scenarios and authentication flows supported by MSAL.NET
-services: active-directory
 author: Dickson-Mwendia
 manager: CelesteDG
 
@@ -12,7 +11,7 @@ ms.workload: identity
 ms.date: 03/17/2023
 ms.author: dmwendia
 ms.reviewer: localden
-ms.custom: devx-track-csharp, aaddev, engagement-fy23
+ms.custom: devx-track-csharp, aaddev
 # Customer intent: As an application developer, I want to know the application scenarios and authentication flows supported by MSAL.NET. 
 ---
 

@@ -1,15 +1,14 @@
 ---
 title: Migrate public client applications to MSAL.NET
 description: Learn how to migrate a public client application from Azure Active Directory Authentication Library for .NET to Microsoft Authentication Library for .NET.
-services: active-directory
 author: Dickson-Mwendia
 manager: CelesteDG
 
 ms.service: msal
 ms.subservice: msal-dotnet
 ms.topic: how-to
 ms.workload: identity
-ms.date: 08/31/2021
+ms.date: 05/20/2024
 ms.author: dmwendia
 ms.reviewer: celested, saeeda, shermanouko, jmprieur
 ms.custom: devx-track-csharp, aaddev, has-adal-ref, devx-track-dotnet
@@ -38,7 +37,7 @@ This article describes how to migrate a public client application from Azure Act
    - [Web Authentication Manager](/azure/active-directory/develop/scenario-desktop-acquire-token-wam) the preferred broker-based authentication on Windows.
    - [Interactive authentication](/azure/active-directory/develop/scenario-desktop-acquire-token-interactive) where the user is shown a web-based interface to complete the sign-in process.
    - [Integrated Windows authentication](/azure/active-directory/develop/scenario-desktop-acquire-token-integrated-windows-authentication) where a user signs using the same identity they used to sign into a Windows domain (for domain-joined or Microsoft Entra joined machines).
-   - [Username/password](/azure/active-directory/develop/scenario-desktop-acquire-token-username-password) where the sign-in occurs by providing a username/password credential.
+   - [Username/password](/azure/active-directory/develop/scenario-desktop-acquire-token-username-password) where the sign-in occurs by providing a username/password credential. Microsoft does not recommend the username and password flow because the application will be asking a user for their password directly, which is an insecure pattern.
    - [Device code flow](/azure/active-directory/develop/scenario-desktop-acquire-token-device-code-flow) where a device of limited UX shows you a device code to complete the authentication flow on an alternate device.
 
 
@@ -235,7 +234,8 @@ result = await context.AcquireTokenAsync(resource, clientId,
 
 ## [Username Password](#tab/up)
 
-Username Password authentication is where the sign-in occurs by providing a username/password credential.
+Username Password authentication is where the sign-in occurs by providing a username/password credential. Microsoft does not recommend this flow because it presents security risks that are not present in other flows.If you're using the username and password flow in production, we recommend switching to other secure alternatives available for your scenario.
+
 #### Find out if your code uses Username Password authentication
 
 The ADAL code for your app uses Username password authentication scenarios if it contains a call to `AcquireTokenAsync` available as an extension method of the `AuthenticationContextIntegratedAuthExtensions` class, with the following parameters:

@@ -1,15 +1,14 @@
 ---
 title: Token cache serialization
 description: Learn about serialization and custom serialization of the token cache using the Microsoft Authentication Library for .NET (MSAL.NET).
-services: active-directory
 author: Dickson-Mwendia
 manager: CelesteDG
 
 ms.service: msal
 ms.subservice: msal-dotnet
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 08/24/2023
+ms.date: 05/20/2024
 ms.author: dmwendia
 ms.reviewer: ddelimarsky, jmprieur
 ms.custom: devx-track-csharp, aaddev, has-adal-ref, devx-track-dotnet

@@ -11,13 +11,13 @@ Microsoft defines the following [data classification](https://www.microsoft.com/
 
 ## What MSAL will never log
 
-- tokens (access tokens, ID tokens, refresh tokens, client assertions generated by MSAL, etc.)
-- passwords (MSAL is only given the password during the Username / Password (ROPC) flow. MSAL does not have access to the password entered by the user in a browser.)
-- authorization codes
+- Tokens (access tokens, ID tokens, refresh tokens, client assertions generated by MSAL, etc.)
+- Passwords (MSAL is only given the password during the Username / Password (ROPC) flow. MSAL does not have access to the password entered by the user in a browser.)
+- Authorization codes
 - PKCE code
-- successful network responses from the _/authorize_ or _/token_ endpoints (because they may contain tokens or auth codes)
-- network requests (they may contain passwords)
-- private keys of certificates
+- Successful network responses from the _/authorize_ or _/token_ endpoints (because they may contain tokens or auth codes)
+- Network requests (they may contain passwords)
+- Private keys of certificates
 
 ## What MSAL considers as PII