Acquiring a token return AuthenticationResult and possibly UserInfo

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)

ADAL.NET caches tokens

For both Public client and confidential client applications, ADAL.NET maintains a token cache, and applications can try to get a token from the cache first.

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 a UI is required for interactive authentication

• But it's also possible for an application running on a Windows machine which is joined to a domain or to Azure AD, to get a token silently for the user signed-in on the machine, leveraging Windows Integrated Authentication (WIA).
• On .NET framework applications, it's also possible (but not recommended) to get a token with a username and password (U/P).
• Finally, for applications running on devices which don't have a Web browser, it's possible to acquire a token through the device code (Device Code) mechanism, which provides the user with a URL and a code. The user goes to a web browser on another device, enters the code and signs-in, which has Azure AD get them a token back on the browser-less device.

Summary for public client applications

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

Operating System	Library Platform	Kind of App	Interactive Auth	WIA	U/P	Device Code
Windows desktop	.NET Framework	Desktop (WPF, Windows.Forms, Console)	Y	Y	Y	(Y)
Windows 10	UWP	Store app	Y	Y
Windows 8.1	WinRT	Win 8.1 Store App	Y	Y
Android	Xamarin Android	Mobile	Y
iOS	Xamarin iOS	Mobile	Y			Y (iOT)
Mac OS, Linux, Windows	.NET Core	Console	N/C			Y

Confidential client applications:

• Will rather acquire tokens for the application itself (client credential), and not for a user. 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 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.
• 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 ADAL.NET

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

In ADAL.NET, AuthenticationResult exposes:

• AccessToken for the Web API to access to. 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. Writing code depending on access token content on the client is one of the biggest sources of errors and client logic failures
• 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 AccessTokenType (usually "Bearer" for Azure AD tokens)
• The Authority which has delivered the token
• The ExtendedLifeTimeToken boolean is used in resiliency scenarios (See the constructor of Construction of an AuthenticationContext for more details)

UserInfo

In ADAL.NET, when the token is acquired for a given user, the information about the user is exposed through the UserInfo class which exposes:

• The displayable id for the user (this can be an email address)
• The user's family name
• The user's given name (which can be an email address)
• The identity provider holding the user identity. This is the STS associated with the authority containing the user (for instance https://sts.windows.net//). Note that in the case when the user is a user of the tenant, the usersHomeTenantId part of the IdentityProvider will be the TenantId. If the user is a guest user of the tenant, the usersHomeTenantId will be the home tenant id of the user.
• A Uri related to the authority enabling the user to change his password. This can be null
• The password expiration date for the user. This can be null
• A unique ID (this is usually a GUID) for the user in the identity provider.

The AuthenticationResult in ADAL.NET does not expose the resource for which the token was issued. This means you can use the token to get access to another resource (which might require user interaction, for instance to consent)