Azure AD v2 and MSAL from a developer's point of view

## Incremental and dynamic consent One of the biggest issues with v1, especially for multi-tenant applications, is that you must define every permission your app will ever need in advance. And the user must accept all of these required permissions. So for example, if your application offers an optional calendar integration to Office 365, … ## Only OpenID Connect and OAuth The v2 endpoint only supports the OpenID Connect and OAuth protocols, which are very commonly used by modern applications. It does not support all of the flows for OAuth which v1 supported yet though, like Device Profile and Resource Owner Password Credentials Grant. Those flows will be enabled later. SAML and WS-Federation are protocols used by primarily older applications and were supported in the v1 endpoint, but are not supported in v2 (not yet at least). … The main difference is that with ADAL you would use an `AuthenticationContext` to acquire tokens, whereas in MSAL you use `ConfidentialClientApplication` or `UserAgentApplication`/ `PublicClientApplication`, depending on if the application is running in a back-end or on the user's device. … ## Current limitations and problems In this part we will look at some limitations of the v2 endpoint as well as problems we have faced. **These limitations are going to be removed as time goes by though!** No official schedule exists for when those features will come. But they will be added. Perhaps the biggest limitation currently is the rather … Also, you **cannot build stand-alone Web APIs currently**. Only an app with the same application ID can request an access token for the API. So you cannot register an API and use it from another app currently. If you want to read about the full set of current limitations, you can check the documentation: Azure AD v2 endpoint limitations. The API for token caches in MSAL.NET is a little bit *funky*. Firstly, the `TokenCache` class is `sealed`, so you can't inherit from it as in ADAL. The only way of doing it properly is to instantiate a `TokenCache` and set a couple event handlers that will be called to load and persist cache data. Now this would not be such a bad thing, but the handler methods must return *void*. What this means is that we cannot use asynchronous APIs to load and persist data in token caches. In ASP.NET Core applications with enough requests coming in, this could actually lead to the application going down and requiring a server restart to recover. … So now we cannot take advantage of the asynchronous APIs available on the distributed cache, and we are blocking the thread until we get a response from the cache. This same issue exists in ADAL as well. It is also important to remember that **v1 applications are currently not compatible with the v2 endpoint**. … One problem that we run into some time ago, but did not run into anymore, was that consent was not being granted after logging in and consenting to the permissions. It took a while (like 15 seconds) for the consent to be done. This issue seems to have been fixed.