Client Applications

Public Client and Confidential Client applications

Contrary to ADAL (which proposes the notion of AuthenticationContext, which is a connection to Azure AD), MSAL, introduces a separation between public client applications, and confidential client applications:

• Confidential client applications are applications which run on servers (Web Apps, Web API, or even service/daemon applications). They are considered difficult to access, and therefore capable of keeping an application secret. Confidential clients are able to hold configuration time secrets. Each instance of the client has a distinct configuration (including clientId and secret). These values are difficult for end users to extract. A web app is the most common confidential client. The clientId is exposed through the web browser, but the secret is passed only in the back channel and never directly exposed.

  Confidential client apps:

  

• public client applications are applications which run on devices (phones for instance) or desktop machines. They are not trusted to safely keep application secrets, and therefore access Web APIs in the name of the user only (they only support public client flows). Public clients are unable to hold configuration time secrets, and as a result have no client secret.

  Public client applications:

  

MSAL4J defines IPublicClientApplication interfaces for public client applications and IConfidentialClientApplication for confidential client applications, as well as a base interface IClientApplicationBase for the contract common to both types of applications.

View of the application interfaces.

High level commonalities and differences

• Both kinds of applications maintain a TokenCache and can acquire a token silently (in cases where the token is already in the token cache).
• Both manage user accounts (get the accounts from the user token cache (getAccounts), get an account from its identifier (getAccounts), or remove an account (removeAccounts))

If you used ADAL in the past, you might notice that, contrary to ADAL's Authentication context, in MSAL the clientID (also named applicationID or appId) is passed once at the construction of the Application, and no longer needs to be repeated when acquiring a token. This is the case both for a public and a confidential client applications. Constructors of confidential client applications are also passed client credentials: the secret they share with the identity provider.

Instantiating an Application

Pre-requisites

Before instantiating your app, you'll need to register it. You will therefore know:

• Its clientID (a string representing a GUID)
• The identity provider URL (named the instance) and the sign-in audience for your application. These two parameters are collectively known as the authority.
• Possibly the TenantID in the case you are writing a line of business application (just for your organization, also named single-tenant application)
• In case it's a confidential client app, its application secret (clientSecret string) or certificate (of type X509Certificate2)
• For web apps, and sometimes for public client apps (in particular when your app needs to use a broker), you'll have also set the redirectUri where the identity provider will contact back your application with the security tokens.