During the Build 2016 conference, Vittorio Bertocci, the Principal Program Manager at the Microsoft Identity division announced the availability of a new authentication library named MSAL (Microsoft Authentication Library). It is poised to become one unified library that provides a single programming model for different identity providers such as Microsoft Accounts, and Azure Active Directory.
MSAL finds its origins in ADAL which was tailored to work exclusively with Azure AD and ADFS. MSAL is better in terms that it supports apps, agnostic of the authority mechanism being MSA or any Azure AD tenant. It also provides better protocol compliance and overcomes some of the issues with ADAL such as working with cache in multi-tenant applications. Another feature that makes it a universal identity provider is that it supports standard definition scopes instead of resources that are proprietary to Active Directory. With MSAL you don’t need to know native protocols like OAuth and Open ID Connect. It provides the necessary wrappers for you to program with the library and perform identity related operations at a high level without having to know a lot of details about the native protocols. Notably multi-factor authentication is supported out of the box. Overall, however, the most fascinating feature of this library is the ability for the app to ask for permissions incrementally and support transparent refresh tokens.
The two primary operations exposed by MSAL are:
- PublicClientApplication — used for desktop clients and mobile apps
- ConfidentialClientApplication — for server side apps and other web based resources
You can start using MSAL using the new authority endpoint. Note that you need to register your app first and get the client id. The new endpoint supports both personal and work accounts. During the authentication process you will receive both the sign in info and also an authorization code that can be used to obtain an access token. In a single sign-on scenario, that token can be used to access other secured resources that are part of the same sign-in. The following code illustrates how the ConfidentialClientApplication primitive is used to fetch the token and access the resource securely:
ConfidentialClientApplication clientApp = new ConfidentialClientApplication(clientId, null,
new ClientCredential(appKey), new MSALSessionCache(userId, this.HttpContext));
You can then use the
AcquireTokenSilentAsync method to get the token by asking for the scopes you need.
authentication, APIs, Authentication Systems, user authentication, identity verification, Microsoft Identity Manager, .NET 2015