Merge pull request #88945 from jmprieur/adalOnBackBurner

Proposing to make it clear ADAL is on the back burner

Author: PRMerger14

articles/active-directory/develop/msal-net-migration.md

@@ -23,16 +23,24 @@ ms.collection: M365-identity-device-management
 
 # Migrating applications to MSAL.NET
 
-Both Microsoft Authentication Library for .NET (MSAL.NET) and Azure AD Authentication Library for .NET (ADAL.NET) are used to authenticate Azure AD entities and request tokens from Azure AD. Up until now, most developers have worked with Azure AD for developers platform (v1.0) to authenticate Azure AD identities (work and school accounts) by requesting tokens using Azure AD Authentication Library (ADAL). Now, using MSAL.NET, you can authenticate a broader set of Microsoft identities (Azure AD identities and Microsoft accounts, and social and local accounts through Azure AD B2C) through the Microsoft identity platform endpoint. 
+Both Microsoft Authentication Library for .NET (MSAL.NET) and Azure AD Authentication Library for .NET (ADAL.NET) are used to authenticate Azure AD entities and request tokens from Azure AD. Up until now, most developers have worked with Azure AD for developers platform (v1.0) to authenticate Azure AD identities (work and school accounts) by requesting tokens using Azure AD Authentication Library (ADAL). Using MSAL:
 
-This article describes how to choose between the Microsoft Authentication Library for .NET (MSAL.NET) and Azure AD Authentication Library for .NET (ADAL.NET) and compares the two libraries.  
+- you can authenticate a broader set of Microsoft identities (Azure AD identities and Microsoft accounts, and social and local accounts through Azure AD B2C) as it uses the Microsoft identity platform endpoint,
+- your users will get the best single-sign-on experience.
+- your application can enable incremental consent, and supporting conditional access is easier
+- you benefit from the innovation.
+
+**MSAL.NET is now the recommended auth library to use with the Microsoft identity platform**. No new features will be implemented on ADAL.NET. The efforts are focused on improving MSAL.
+
+This article describes the differences between the Microsoft Authentication Library for .NET (MSAL.NET) and Azure AD Authentication Library for .NET (ADAL.NET) and helps you migrate to MSAL.  
 
 ## Differences between ADAL and MSAL apps
+
 In most cases you want to use MSAL.NET and the Microsoft identity platform endpoint, which is the latest generation of Microsoft authentication libraries. Using MSAL.NET, you acquire tokens for users signing-in to your application with Azure AD (work and school accounts), Microsoft (personal) accounts (MSA), or Azure AD B2C. 
 
 If you are already familiar with the Azure AD for developers (v1.0) endpoint (and ADAL.NET), you might want to read [What's different about the Microsoft identity platform (v2.0) endpoint?](active-directory-v2-compare.md).
 
-However, you still need to use ADAL.NET if your application needs to sign in users with earlier versions of [Active Directory Federation Services (ADFS)](/windows-server/identity/active-directory-federation-services). For more details, see [ADFS support](https://aka.ms/msal-net-adfs-support).
+However, you still need to use ADAL.NET if your application needs to sign in users with earlier versions of [Active Directory Federation Services (ADFS)](/windows-server/identity/active-directory-federation-services). For more information, see [ADFS support](https://aka.ms/msal-net-adfs-support).
 
 The following picture summarizes some of the differences between ADAL.NET and MSAL.NET
 ![Side-by-side code](./media/msal-compare-msaldotnet-and-adaldotnet/differences.png)
@@ -204,7 +212,7 @@ var scopes = new [] {  ResourceId+"/.default"};
 
 ### Scopes to request in the case of client credential flow / daemon app
 
-In the case of client credential flow, the scope to pass would also be `/.default`. This tells to Azure AD: "all the app-level permissions that the admin has consented to in the application registration.
+In the case of client credential flow, the scope to pass would also be `/.default`. This scope tells to Azure AD: "all the app-level permissions that the admin has consented to in the application registration.
 
 ## ADAL to MSAL migration
 
@@ -213,9 +221,9 @@ Some of those solutions were used in scenarios such as:
 * Long running services that do actions including refreshing dashboards on behalf of the users whereas the users are no longer connected. 
 * WebFarm scenarios for enabling the client to bring the RT to the web service (caching is done client side, encrypted cookie, and not server side)
 
-This is not the case with MSAL.NET, however as we no longer recommend utilizing refresh tokens in this manner for security reasons. This would make it difficult to migrate to MSAL 3.x as the API does not provide a way to pass in previously acquired refresh tokens. 
+MSAL.NET does not expose refresh tokens, for security reasons: MSAL handles refreshing tokens for you. 
 
-Fortunately, MSAL.NET now has an API that allows you to migrate your previous refresh tokens into the `IConfidentialClientApplication` 
+Fortunately, MSAL.NET now has an API that allows you to migrate your previous refresh tokens (acquired with ADAL) into the `IConfidentialClientApplication`:
 
 ```CSharp
 /// <summary>