Acquiring Tokens

Acquiring a token: this depends on the kind of application

There are many ways of acquiring a token. They are detailed in the next topics. Some require user interactions through a web browser. Some don't require any user interactions. In general the way to acquire a token is different depending on if the application is a public client application (Desktop / Mobile) or a confidential client application (Web App, Web API, daemon application like a windows service)

MSAL.NET caches tokens

For both Public client and confidential client applications, MSAL.NET maintains a token cache (or two caches in the case of confidential client applications), and applications should try to get a token from the cache first before any other means. In the case of UWP, Xamarin iOS and Xamarin Android, the token cache serialization to an isolated storage is provided by MSAL.NET. In the case of .NET Desktop (.NET Framework and .NET Core) platforms, though, the application needs to customize the token cache serialization.

Public client application:

• will often acquire token interactively, having the user sign-in.

  Remember that this is not possible yet in .NET Core as .NET core does not provide UI capabilities and this is required for interactive authentication

the other non-interactive public client applications flows/grants are not yet supported in MSAL.NET / the V2 endpoint (these are integrated windows authentication on domain or AAD joint windows machines, username passwords, or device code, for apps running on devices which don't have a Web browser)

Confidential client applications will rather:

• Acquire token for the application itself, not for a user, using client credentials, which can be an application secret or a certificate. This can be used for syncing tools, or tools which process users in general, not a particular user.
• In the case of Web Apps or Web APIs calling the Microsoft Graph in the name of the user (and, in the future, calling another Web API in the name of the user), using the On Behalf Of flow and still identifying the application itself with client credentials to acquire a token based on some User assertion (SAML for instance, or a JWT token). This can be used for applications which need to access resources of a particular user in service to service calls.
• For Web apps, acquire tokens by authorization code after letting the user sign-in through the authorization request URL. This is typically the mechanism used by an open id connect application, which lets the user sign-in using Open ID connect, but then wants to access Web APIs for this particular user.

summary for confidential client applications

The following table summarizes the ways available to acquire tokens in confidential client applications depending on the Operating system, and therefore the chosen platform, and the kind of application.

Operating System	Library Platform	Kind of App	Client Credential	On behalf of	Auth Code
Windows	.NET Framework	Web App	Y		Y
Windows, MacOS, Linux	(ASP).NET Core	Web App	Y		Y
Windows	.NET Framework	Web API	Y	Y
Windows, MacOS, Linux	(ASP).NET Core	Web API	Y	Y
Windows	.NET Framework	Daemon app (windows service)	Y
Windows, MacOS, Linux	.NET Core	Daemon	Y

AuthenticationResult properties in MSAL.NET

In all cases above, methods to acquire tokens return an AuthenticationResult (or in the case of the async methods a Task<AuthenticationResult>.

In MSAL.NET, AuthenticationResult exposes:

• AccessToken for the Web API to access resources. This is a string, usually a base64 encoded JWT but the client should never look inside the access token. The format isn't guaranteed to remain stable and it can be encrypted for the resource. People writing code depending on access token content on the client is one of the biggest sources of errors and client logic breaks
• IdToken for the user (this is a JWT)
• ExpiresOn tells the date/time when the token expires
• TenantId contains the tenant in which the user was found. Note that in the case of guest users (Azure AD B2B scenarios), the TenantId is the guest tenant, not the unique tenant. When the token is delivered in the name of a user, AuthenticationResult also contains information about this user. For confidential client flows where tokens are requested with no user (for the application), this User information is null.
• The Scopes for which the token was issued (See Scopes not resources)
• The unique Id for the user.

IUser

The information about the user is also simpler than in ADAL.NET:

• The displayable id
• The unique identifier (named Identifier)
• The identity provider
• And the name (given name)