Scenarios
The .NET authentication libraries support scenarios involving Protecting a Web API 
and Acquiring tokens for a protected Web API 
. MSAL.NET is only about the later.
The token can be acquired from a number of application types: Web applications, Mobile or Desktop applications, Web APIs, and application running on devices that don't have a browser (or iOT). Applications tend to be separated into two categories:
- Public client applications (Desktop / Mobile) use the PublicClientApplication class
- Confidential client applications (Web apps, Web APIs, and daemon applications - desktop or Web). These type of apps use the ConfidentialClientApplication
MSAL.NET supports acquiring tokens either in the name of a user 
, or, (and only for confidential client applications), in the name of the application itself (for no user). In that case the confidential client application shares a secret with Azure AD 
MSAL.NET supports a number of platforms (.NET Framework, .NET Core, Windows 10/UWP, Xamarin.iOS, Xamarin.Android). .NET Core apps can also run on different operating systems (Windows, but also Linux and MacOs). The scenarios can be different depending on the platforms
The picture below summarizes the supported scenarios and shows on which platform, and to which Azure AD protocol this corresponds:
To protected a Web App (signing in the user) you'll use ASP.NET or ASP.NET Core with the ASP.NET Open ID Connect middleware. Under the hood. This involves validating the token which is done by the IdentityModel extensions for .NET library, not MSAL.NET
To call the Web API in the name of the user you'll use MSAL.NET ConfidentialClientApplication, leveraging the Authorization code flow, then storing the acquired token in the token cache, and acquiring silently a token from the cache when needed. MSAL refreshes the token if needed.
To call a Web API from a mobile application, you will use MSAL.NET's PublicClientApplication's interactive token acquisition methods. These interactive methods enable you to control the sign-in UI experience, as well as the location of the interactive dialog on some platforms. To enable this interaction, MSAL.NET leverages a web browser. There are specificities depending on the mobile platform UWP, iOS, Android). On iOS and Android, you can even choose if you want to leverage the system browser (the default), or an embedded web browser. You can enable some kind of token cache sharing on iOS
Some scenarios, involving conditional access related to a device being enrolled require a broker (Microsoft Company portal or Microsoft Authenticator) to be installed on a device. MSAL.NET is not yet capable of interacting with these brokers, but this is on the backlog
You can write a daemon app acquiring a token for the app on top using MSAL.NET's ConfidentialClientApplication's client credentials acquisition methods. These suppose that the app has previously registered a secret (application password or certificate) with Azure AD, which it then shares with this call.
Desktop applications can use the same interactive authentication as the mobile applications.
For Windows hosted applications, it's also possible for applications running on computers joined to a Windows domain or AAD joined to acquire a token silently by using Integrated Windows Authentication
If your desktop application is a .NET Core application running on Linux or Mac, you will be able to use neither the interactive authentication (as .NET Core does not provide a Web browser), nor Integrated Windows Authentication. The best option in that case is to use device code flow (See Application without a browser, or iOT application calling an API in the name of the user) below
Finally, and although it's not recommended, you can use Username/Password in public client applications; It's still needed in some scenarios (like DevOps), but beware that using it will impose constraints on your application. For instance it won't be able to sign-in user who need to perform Multi Factor Authentication (conditional access) and it won't enable your application to benefit from Sigle Sign On. It's also against the principles of modern authentication and is only provided for legacy reasons.
In desktop applications, if you want the token cache to be persistent, you will need to customize the token cache serialization
Applications running on a device without a browser will still be able to call an API in the name of a user, after having the user sign-in on another device which has a Web browser. For this you'll need to use the Device Code flow
If you want your ASP.NET or ASP.NET Core protected Web API to call another Web API on behalf of the user represented by the access token was used to call you API, you will need to:
- validate the token. For this you'll use the ASP.NET JWT middleware. Under the hood. This also involves validating the token which is done by the IdentityModel extensions for .NET library, not MSAL.NET
- then you will need to acquire a token for the downstream Web API by using the ConfidentialClientApplication's method Acquiring a token on behalf of a user in Service to Services calls.
- Web APIs calling other web API will also need to provide a custom cache serialization
like in the case of a desktop/service daemon application, a daemon Web API (or a daemon Web App) can use MSAL.NET's ConfidentialClientApplication's client credentials acquisition methods
In all the scenarios you might want to:
- troubleshoot yourself by activating logs or Telemetry
- understand how to react to exceptions due to the Azure AD service MsalServiceException, or to something wrong happening in the client itself MsalClientException
- use MSAL.NET with a proxy