Scenarios

Introduction

MSAL4J can be used to acquire tokens for a protected API. Tokens can be acquired for a number of application types: Desktop applications, Web applications, Web APIs, and applications 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

MSAL4J 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

MSAL4J can be used in applications running on different operations systems (Windows, Linux, Mac). Scenarios might differ depending on platform.

Web Application signing in a user and calling a Web API in the name of the user

To call the Web API in the name of the user you'll use a ConfidentialClientApplication, leveraging the Authorization code flow, then storing the acquired token in the token cache, and acquiring a token silenttly from the cache when needed. MSAL refreshes the token if needed.

Desktop application calling a Web API in the name of the signed-in user

For desktop applications, acquisition of tokens interactively is not available. If you want to provide interactive sign-in for a desktop application, you could let the application present to the user a code and a URL to go to sign-in interactively (See Device Code Flow)

For desktop applications running on Windows, 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

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.

Desktop/service daemon application calling Web API in without a user (in its own name)

You can write a daemon app acquiring a token for the app on top using a 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.

Application without a browser, or iOT application calling an API in the name of the user

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