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

## 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, you would have to require the access to the user's calendar even if your app never used it for that user. *There are ways around that by using a second application of course.* With v2, you can specify which scopes you need when redirecting the user to authenticate. … ## 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 **small set of APIs that apps can use**. Your app can use: 1. Its own API 2. Outlook Mail, Calendar, and Contacts REST APIs 3. Microsoft Graph API (which contains the Outlook APIs) If you want to use any other API, then currently your only option is to use the v1 endpoint. 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 … } <span class="kw">catch</span> (Exception e) { <span class="kw">throw</span>; } _cache.<span class="fu">HasStateChanged</span> = <span class="kw">false</span>; } }</code> 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**. Same goes the other way, you cannot use the v1 endpoint from a v2 application. A migration path for v1 applications does not exist yet. However v2 application management is planned to be merged with v1 application management in Azure Portal. Once that happens, current v1 applications will be able to use the v2 endpoint, and there will be a documented migration path. 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.