azuread / azure-activedirectory-library-for-dotnet

ADAL authentication libraries for .net

---

This library, ADAL for .NET, will no longer receive new feature improvements. Instead, use the new library MSAL for .NET.

• If you are starting a new project, you can get started with the MSAL for .NET docs for details about the scenarios, usage, and relevant concepts.
• If your application is using the previous ADAL for .NET library, you can follow this migration guide for .NET apps, this migration guide for brokered iOS Xamarin apps, or this migration guide for brokered Android Xamarin apps.
• Existing applications relying on ADAL for .NET will continue to work.

---

Active Directory Authentication Library (ADAL) for .NET, Windows Store, .NET Core, Xamarin iOS and Xamarin Android

Conceptual documentation	Code Samples	Reference Docs	Developer Guide	API Reference	Feedback

Update to MSAL.NET now!

MSAL.NET is the new authentication library to be used with the Microsoft identity platform

Building on top of ADAL, MSAL works with the new and Open ID Connect certified Azure AD V2 endpoint and the new social identity solution from Microsoft, Azure AD B2C.

ADAL.NET is in maintenance mode and no new features will be added to ADAL.NET anymore. All our ongoing efforts will be focused on improving the new MSAL.NET. MSAL’s documentation also contains a migration guide which simplifies upgrading from ADAL.NET, including how to migrate Xamarin.iOS apps using brokers.

ADAL.NET 2.x is no longer supported

ADAL.NET 2.x is no longer supported. ADAL.NET 3.x became generally available more than 3 years ago, superseding ADAL 2.x which was last released in August 2017 If you are still using 2.x, we recommend that you update directly to MSAL.NET

ADAL.NET

Active Directory Authentication Library for .NET (ADAL.NET) is an easy to use authentication library. You can use ADAL.NET to acquire security tokens to access protected Web APIs, for instance Microsoft Graph, or another Web APIs. ADAL.NET is available on various .NET Desktop/Mobile platforms to acquire a token for the signed-in user ( Windows desktop, UWP, Windows 8.1, Xamarin iOS and Xamarin Android). It can also be used in Web applications and Web APIs (ASP.NET, .NET Core, ASP.NET Core) that call other Web APIs in the name of a user, or without a user. ADAL.NET takes advantage of Windows Server Active Directory and Windows Azure Active Directory.

Release	Location
Stable

Build status

dev	adalV3/dev

Branches

dev: Contains newest development of ADAL (v4+) adalV3/dev : Holds the v3 branch. Only security fixes will make it to v3.

Versions

Current version - latest one at nuget.org.
Minimum recommended version - 3.19.8

You can find the changes for each version in the change log.

Security Issue in Multiple Versions of ADAL .Net

A defect in ADAL .Net can result in an elevation of privilege in specific problem scenarios. The problem scenarios involve the On Behalf Of protocol flow and specific use cases of a ClientAssertion/ClientAssertionCertificate/ClientCredential and UserAssertion being passed to the AcquireToken* API. Multiple versions of the library are affected. Affected versions are listed below.

We have emailed owners of active applications that are using an impacted version of the library in the specific problem scenarios.

The latest stable version of the library does not have the defect. To avoid being impacted we strongly recommend you update to at least 2.28.1 for 2.x, 3.13.4 for 3.x, or the latest stable version. If you have questions about this issue, please email [email protected].

Affected 2.x versions: 2.27.306291202, 2.26.305102204, 2.26.305100852, 2.25.305061457, 2.21.301221612, 2.20.301151232, 2.19.208020213, 2.18.206251556, 2.17.206230854, 2.16.204221202, 2.15.204151539, 2.14.201151115, 2.13.112191810, 2.12.111071459, 2.11.10918.1222, 2.10.10910.1511, 2.9.10826.1824, 2.8.10804.1442-rc, 2.7.10707.1513-rc, 2.6.2-alpha, 2.6.1-alpha, 2.5.1-alpha

Affected 3.x versions: 3.11.305310302-alpha, 3.10.305231913, 3.10.305161347, 3.10.305110106, 3.5.208051316-alpha, 3.5.208012240-alpha, 3.5.207081303-alpha, 3.4.206191646-alpha, 3.3.205061641-alpha, 3.2.204281119-alpha, 3.1.203031538-alpha, 3.0.110281957-alpha

Samples and Documentation

We provide a full suite of sample applications and ADAL documentation to help you get started with learning the Azure Identity system. Our Azure AD Developer Guide includes tutorials for native clients such as Windows, Windows Phone, iOS, OSX, Android, and Linux. We also provide full walkthroughs for authentication flows such as OAuth2, OpenID Connect, Graph API, and other awesome features.

Community Help and Support

We leverage Stack Overflow to work with the community on supporting Azure Active Directory and its SDKs, including this one! We highly recommend you ask your questions on Stack Overflow (we're all on there!) Also browser existing issues to see if someone has had your question before.

We recommend you use the "adal" tag so we can see it! Here is the latest Q&A on Stack Overflow for ADAL: http://stackoverflow.com/questions/tagged/adal

Submit Feedback

We'd like your thoughts on this library. Please complete this short survey.

Security Reporting

If you find a security issue with our libraries or services please report it to [email protected] with as much detail as possible. Your submission may be eligible for a bounty through the Microsoft Bounty program. Please do not post security issues to GitHub Issues or any other public site. We will contact you shortly upon receiving the information. We encourage you to get notifications of when security incidents occur by visiting this page and subscribing to Security Advisory Alerts.

Contributing

All code is licensed under the MIT license and we triage actively on GitHub. We enthusiastically welcome contributions and feedback. You can clone the repo and start contributing now, but check this document first.

Diagnostics

The following are the primary sources of information for diagnosing issues:

• Exceptions
• Logs
• Network traces

Also, note that correlation IDs are central to the diagnostics in the library. You can set your correlation IDs on a per request basis (by setting CorrelationId property on AuthenticationContext before calling an acquire token method) if you want to correlate an ADAL request with other operations in your code. If you don't set a correlations id, then ADAL will generate a random one which changes on each request. All log messages and network calls will be stamped with the correlation id.

Exceptions

This is obviously the first diagnostic. We try to provide helpful error messages. If you find one that is not helpful please file an issue and let us know. Please also provide the target platform of your application (e.g. Desktop, Windows Store, Windows Phone).

Logs

In order to configure logging, see the wiki page for implementation details.

Using brokers

See Leveraging brokers on Android and iOS

Network Traces

You can use various tools to capture the HTTP traffic that ADAL generates. This is most useful if you are familiar with the OAuth protocol or if you need to provide diagnostic information to Microsoft or other support channels.

Fiddler is the easiest HTTP tracing tool. In order to be useful it is necessary to configure fiddler to record unencrypted SSL traffic.

NOTE: Traces generated in this way may contain highly privileged information such as access tokens, usernames and passwords. If you are using production accounts, do not share these traces with 3rd parties. If you need to supply a trace to someone in order to get support, reproduce the issue with a temporary account with usernames and passwords that you don't mind sharing.

License

Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License (the "License");

We Value and Adhere to the Microsoft Open Source Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

azure-activedirectory-library-for-dotnet's Issues

Race condition can happen in parallel token requests when sending client metrics

There is a static object which tracks the metrics from previous calls. Setting it to null when the metrics are sent may create null reference for a parallel thread which may be sending metrics as well.

Update AcquireTokenByAuthCode and AcquireTokenByRefreshToken to cache tokens

In web apps that use OpenId connect handler, we rely on using ADAL for getting access tokens using AcquireTokenByAuthCode and AcquireTokenByRefreshToken methods. Since these methods do not store or retrieve tokens from cache, developers are forced to do token management themselves, which includes storing and retrieving tokens to/from cache, checking the expiration time on the tokens etc.

Token cache has no size limit.

AcquireToken(resource, userAssertion, clientAssertion) throws while getting an access token using a multi-resource refresh token

A first chance exception of type 'Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException' occurred in Microsoft.IdentityModel.Clients.ActiveDirectory.dll

Additional information: AADSTS90014: The request body must contain the following parameter: 'client_secret or client_assertion'.

Call Stack

Microsoft.IdentityModel.Clients.ActiveDirectory.HttpHelper.SendPostRequestAndDeserializeJsonResponseAsync<Microsoft.IdentityModel.Clients.ActiveDirectory.TokenResponse>(string uri, Microsoft.IdentityModel.Clients.ActiveDirectory.RequestParameters requestParameters, Microsoft.IdentityModel.Clients.ActiveDirectory.CallState callState)
Microsoft.IdentityModel.Clients.ActiveDirectory.OAuth2Request.SendHttpMessageAsync(string uri, Microsoft.IdentityModel.Clients.ActiveDirectory.RequestParameters requestParameters, Microsoft.IdentityModel.Clients.ActiveDirectory.CallState callState)

Microsoft.IdentityModel.Clients.ActiveDirectory.OAuth2Request.SendTokenRequestByRefreshTokenAsync(string uri, string resource, string refreshToken, string clientId, Microsoft.IdentityModel.Clients.ActiveDirectory.CallState callState)

Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.SendOAuth2RequestByRefreshTokenAsync(string resource, string refreshToken, string clientId, Microsoft.IdentityModel.Clients.ActiveDirectory.CallState callState)

Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.RefreshAccessTokenAsync(Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationResult result, string resource, string clientId, Microsoft.IdentityModel.Clients.ActiveDirectory.CallState callState)

Microsoft.IdentityModel.Clients.ActiveDirectory.TokenCacheManager.LoadFromCacheAndRefreshIfNeededAsync(string resource, Microsoft.IdentityModel.Clients.ActiveDirectory.CallState callState, string clientId, string userId)

Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.AcquireTokenOnBehalfCommonAsync(string resource, Microsoft.IdentityModel.Clients.ActiveDirectory.UserAssertion userAssertion, Microsoft.IdentityModel.Clients.ActiveDirectory.ClientKey clientKey, bool callSync)

Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.AcquireToken(string resource, Microsoft.IdentityModel.Clients.ActiveDirectory.UserAssertion userAssertion, Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredential clientCredential)

Signout-Signin experience issue in WinPhone

Using 2.7.10729.1634-rc bits of ADAL

When user Sign out and sign-in, I expect to provide the credentials directly. But I see a message saying you are already signed in.
Below screen that provides 2 options

1. Remain signed in with this account
2. Sign out and sign in with another account

Reading this, I expected that I won’t be prompted for credential when clicking (1) That is not the case. I had to provide my credentials.
On clicking (2), I expected to provide credential (either as same or different user)  I get error saying "Sorry we're having trouble signing you out"...
Both seems wrong to me.

Extra space appears in first ADAL prompt for username, causing auth failures unless removed

The first ADAL prompt which appears, asking for your username, is pre-populated with a single space. Users do not see the space, and enter their username. Since the space+username combination is not valid, authentication fails. Even removing the space in the subsequent page (where password is also prompted) does not seem to fix it, and the user has to close the ADAL prompt and start over.

This is a blocking issue.

[email protected]

The ActorToken JWT constant doesn't appear to be used any where?

In JsonWebTokenConstants.cs the ReservedClaims.ActorToken constant is defined. However, it doesn't appear to be used anywhere. If not, it should probably be removed. In dev there is a PCL version as well.

Update token cache logic in AcquireTokenByAuthoricationCode

"The lack of a resource would make a cached access token inaccessible in subsequent calls, however if its associated refresh token is an MRRT then having it cached would help making subsequent AcquireTokenSilent calls succeed. Hence, it looks like we should cache the acquiretokenbyauthorizationcode result, at least when we know that the origin authority trades MRRTs."

Errors should return 'ErrorUri'

Errors from OAuth have 3 parts: ErrorCode, ErrorDescription, ErrorUri. This library doesn't surface ErrorUri.

AuthenticationContext should not update the authority after retrieving a token.

The library should no longer be replacing the common tenant with a specific tenant after retrieving a token. The method UpdateAuthorityTenantAsync should disappear.

AcquireTokenInteractiveHandler throws System.IndexOutOfRangeException when empty extraQueryParameters is passed.

Latest dev branch sources (2.7.10804.0745-rc)
AcquireTokenInteractiveHandler throws System.IndexOutOfRangeException when empty extraQueryParameters is passed.

Below is the code that throws this. We should be checking for string.IsNullorEmpty not just null.
if (extraQueryParameters != null && extraQueryParameters[0] == '&')
{
extraQueryParameters = extraQueryParameters.Substring(1);
}

Microsoft.IdentityModel.Clients.ActiveDirectory.winmd!Microsoft.IdentityModel.Clients.ActiveDirectory.AcquireTokenInteractiveHandler.AcquireTokenInteractiveHandler(Microsoft.IdentityModel.Clients.ActiveDirectory.Authenticator authenticator = {Microsoft.IdentityModel.Clients.ActiveDirectory.Authenticator}, Microsoft.IdentityModel.Clients.ActiveDirectory.TokenCache tokenCache = {Microsoft.IdentityModel.Clients.ActiveDirectory.TokenCache}, string resource = "api.aadrm.com", string clientId = "6507DFAF-F19E-47C6-82C3-08AFEE79D74E", System.Uri redirectUri = {System.Uri}, Microsoft.IdentityModel.Clients.ActiveDirectory.PromptBehavior promptBehavior = Always, Microsoft.IdentityModel.Clients.ActiveDirectory.UserIdentifier userId = {Microsoft.IdentityModel.Clients.ActiveDirectory.UserIdentifier}, string extraQueryParameters = "", Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.IWebUI webUI = {Microsoft.IdentityModel.Clients.ActiveDirectory.WebUI}, bool callSync = false) Line 62 C#
Microsoft.IdentityModel.Clients.ActiveDirectory.winmd!Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.AcquireTokenAndContinueCommon(string resource = "api.aadrm.com", string clientId = "6507DFAF-F19E-47C6-82C3-08AFEE79D74E", System.Uri redirectUri = {System.Uri}, Microsoft.IdentityModel.Clients.ActiveDirectory.UserIdentifier userId = {Microsoft.IdentityModel.Clients.ActiveDirectory.UserIdentifier}, string extraQueryParameters = "", Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContextDelegate authDelegate = {Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContextDelegate}) Line 208 C#
Microsoft.IdentityModel.Clients.ActiveDirectory.winmd!Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.AcquireTokenAndContinue(string resource = "api.aadrm.com", string clientId = "6507DFAF-F19E-47C6-82C3-08AFEE79D74E", System.Uri redirectUri = {System.Uri}, Microsoft.IdentityModel.Clients.ActiveDirectory.UserIdentifier userId = {Microsoft.IdentityModel.Clients.ActiveDirectory.UserIdentifier}, string extraQueryParameters = "", Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContextDelegate authDelegate = {Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContextDelegate}) Line 154 C#
UILib.DLL!UILib.AuthenticationManager.GetToken.AnonymousMethod__3() Line 73 C#

Distinguish between 'AnyUser' and 'UnknownUser' with regards to cache

We need to distinguish between ‘I don’t care’ and ‘I don’t know’ when it comes to user. Currently, when UserAssertion is created without explicit user in On Behalf Of scenario, we assume it means ‘AnyUser’ and match it with any user we find in the cache. However, there is a user in the assertion that we don’t know as we cannot look inside that assertion. In this case, we can say ‘we don’t know’ the user and do not match any token from the cache. This reduces cache usage, but can avoid such confusions. The good news is that this is not an interactive flow, so the change in behavior does not lead to more user involvement.

Native projects calling AcquireTokenAndContinue in winphone throws exception

Create a Winphone Store Native project or WinJS project.
Add reference to ADAL.
Call AcquireTokenAndContinue method

There seems to be an issue in calling WebAuthenticationBroker.GetCurrentApplicationCallbackUri in winphone. If a native project calls into a managed winmd that calls GetCurrentApplicationCallbackUri we are getting an exception.

With this bug, overload w/o redirect uri will fail – which is ok as the underlying platform code is throwing.
We fail even for the overload developers specify the redirect uri. This is due to the fact that , In WEbUI::Authenticate method we check whether this is SSO mode or not. This is failing.
if (redirectUri.AbsoluteUri == WebAuthenticationBroker.GetCurrentApplicationCallbackUri().AbsoluteUri)

Till the issue is fixed in platform, we should catch the exception and continue…

Send redirect uri original string to STS without canonicalizing it

Use OriginalString property of Uri class instead of AbsoluteUri to send redirectUri to STS. Service uses string comparison instead of Uri comparison, so the string passed should be identical to the one registered.

ADAL winphone: Callbackdelegate is not getting called in failure cases

Call Context.AcquireTokenAndContinue with a callbackdelegate

In continuation method,
Call Context.ContinueAcquireTokenAsync(args)

When executing this, cancel the WAB (press back key).
Callback comes to continuation method. But call back delegate is not getting called.

GetNativeSystemInfo causes Windows Phone 8.1 app certification to fail

Windows Phone 8.1 App Store Certification fails for any app that includes ADAL due to the following error:

This API is not supported for this application type - Api=GetNativeSystemInfo. Module=kernel32.dll. File=Microsoft.IdentityModel.Clients.ActiveDirectory.winmd.

ADAL needs to link against api-ms-win-core-sysinfo-l1-2-2.lib instead of kernel32.dll for this method.

[email protected]

Not able to sign out and sign in as different user

I would like to provide a sign out and sign in as different user experience in my app.
In sign out, I am clearing the token cache
Ctx.TokenCacheStore.Clear() And Call 'AcquireTokenAndContinue'.

Since I do not know the user id upfront, I am using the below overload
public void AcquireTokenAndContinue(string resource, string clientId, Uri redirectUri, AuthenticationContextDelegate authDelegate);

Calling AcquireTokenAndContinue return the token for previous user. I don't get any prompt to enter new credentials.

Rename AcquireTokenAsync overloads without redirectUri in WinRT and WinPhone

Library crashes on re-entry in WinJS phone app

Crashes with the error message

The text associated with this error code could not be found.

System.UriFormatException: Invalid URI: The hostname could not be parsed.
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at System.Uri..ctor(String uriString)
at Microsoft.IdentityModel.Clients.ActiveDirectory.AcquireTokenInteractiveHandler..ctor(Authenticator authenticator, TokenCache tokenCache, IWebAuthenticationBrokerContinuationEventArgs args)
at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.ContinueAcquireTokenAsync(IWebAuthenticationB

Regex update for AuthenticationParameters

It will be similar to node.js and ios ADAL
This is related to the Authentication Challenge. ADAL receives 401 challenge and gets authority information from the header using regex.

Handling of SSO and non SSO modes in ADAL RT needs improvement

As per the ADAL documentation on the apis, below api would set the SSO mode
AcquireTokenAsync(string resource, string clientId);

This naturally meant to me that rest of the overloads would not set the SSO mode.However, I experienced that SSO mode was set by other overloads too when redirectUri parameter passed to them was same as the ms-App uri of the RT app.
So in another words, if developer does not want SSO mode, then redirectUri parameter passed to the api should be different than the ms-App uri of the app itself. To better educate developer on SSO/non SSO modes, this fact should be documented.

Or consider other ways to simplify this experience like:
Give EnableSSO flag on AuthenticationContext object similar to UseCorporateNetwork flag

SSO is broken on WinPhone

The method WebAuthenticationBroker.GetCurrentApplicationCallbackUri returns exception

System.UriFormatException: Invalid URI: The hostname could not be parsed.
Result StackTrace:
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at System.Uri..ctor(String uriString)
at Windows.Security.Authentication.Web.WebAuthenticationBroker.GetCurrentApplicationCallbackUri()

Following up with the WAB team...

Username/Password out-of-focus issues when redirecting to a 3rd party IDP: Shibboleth

Impact:

• All Shibboleth users and potential other 3rd party federated Identity Provider users.
• Unacceptable UX experience

To repro:

1. Enter the user name: [email protected]
2. The ADAL.NET library will redirect the user to her IDP sign in page, in this case Shibboleth

Expected Result:
User can see the full user name and password field, and the realm they are trying to sign in to.

Actual Result:
These three fields are out of focus, and there is no scroll bar for the user to move to locate the focus properly.

Need better documentation on UseCorporateNetwork usage in ADAL RT

Thanks for fixing #75

I am using ADAL 2.9.10828.0745 from my get. This has some fixes in AcuireTokenAsync apis.

Current documentation on UseCorporateNetwork says "...this flag works only in SSO mode.
But with the latest ADAL bits, I don't see anything (documentation, property, method) to set the SSO mode. As a developer, how do I learn about setting SSO mode using ADAL?

Need better documentation on UseCorporateNetwork usage in ADAL RT

Integrated auth mode in the app (UseCorporateNetwork flag) using ADAL RT works only in case of SSO mode. If developer is not setting SSO mode, UseCorporateNetwork will be ignored. Api documentation needs to make developer aware of this.

PromptBehavior in non-SSO API in WinRT does not have any effect

In non-SSO mode, WAB does not preserve cookies (neither session not persistent) and WIA does not work either. So, none of the prompt behavior modes work in non-SSO case except Always.

WIA does not work with PromptBehavior.Never (prompt=none)

This flag is not working for federated users. We need a better solution (either changing the behavior of prompt=none or passing another flag to AAD to make sure it redirects to ADFS for federated cases while maintaining prompt=none behavior for managed users).

Change log entry format to match other ADAL libraries.

ADAL libraries are moving to this standard log entry format.

timestamp:correlation-id - ClassOrComponent: description

If it makes sense on this platform, then dotnet should adopt this format as well, or the closest natural equivalent.

AuthenticationResult.UserInfo.IdentityProvider field is populated as null, which is confusing

I am using a native client application to get an access token for a resource, registered in a standard Azure AD tenant e.g. mytenant.onmicrosoft.com.
I am using ADAL RT in my app to get the access token. After successful authentication for
admin@ mytenant.onmicrosoft.com user, I see that AuthenticationResult.UserInfo.IdentityProvider field is null. How can it be null? I assume it should look like https://sts.windows.net/mytenant.onmicrosoft.com. Right?

If I uses Microsoft user e.g. [email protected] for authentication, then I see that IdentityProvider is populated as live.com.

I think the reason for this is , in first case you don't get "idp" claim, in later case you get "idp" claim from
AAD.

However, as a developer, this is confusing/ambiguous experience for me. I would expect a valid value for IdentityProvider in both the cases.

Need better help/documentation on UserIdentifierType

The help available on the fields of UserIdentifierType is not intuitive. e.g. it is not clear when to use OptionalDisplayableId or RequiredDisplayableId or UniqueId. Also, it is not clean how result will be different in each case.

x-client CPU should be X86 when running in WinPhone Emulator

It should follow the same code as RT - If we remove the special case for phone in NativeHelpers

if ADAL_WINPHONE

            return "ARM";

else

AuthenticationParameters should use common RegEx for parsing values.

The other code bases use a standard RegEx to parse out the AuthenticationParameters. This library should do the same.

Windows Integrated Authentication not working

I'm trying to get Windows Integrated Authentication to work as described in this blog post
http://www.cloudidentity.com/blog/2014/07/10/adal-v2-and-windows-integrated-authentication/

I'm getting error code invalid_authority_type using code similar to what's in the blog post

AuthenticationResult result = 
     authContext.AcquireToken(todoListResourceId, clientId, new UserCredential());

From a quick look at the code, it appears that the condition on line 286 of AcquireTokenHandlerBase.cs is evaluating to false because AcquireTokenNonInteractiveHandler.SupportADFS is false. Is that the expected behavior? Is there a different overload I should be calling?

Update AuthenticationResult.Serialize() to return an encoded string

An authenticationResult object should be base64 encoded before adding it to the token cache store because ADAL tries to decode it while trying to read the result from the cache. This is not obvious and fragile - if ADAL changes it's implementation, the apps that are adding tokens into the cache would be broken.

Consider updating AuthenticationResult.Serialize() to return an encoded string.

AcquireTokenSilent

Hi! I'm having this exception when trying to run the AcquireTokenSilent method on AuthenticationContext class :
AdalSilentTokenAcquisitionException
Message : Failed to acquire token silently. Call method AcquireToken.

I'm following this sample code https://github.com/AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet, so the scenario is the same. I searched on the web but every solution I found wasn't the right one. I also took a look at the source code and I found this code in the AcquireTokenSilentHandler class :

protected override Task<AuthenticationResult> SendTokenRequestAsync()
{
    Logger.Verbose(this.CallState, "No token matching arguments found in the cache");
    throw new AdalSilentTokenAcquisitionException();
}

So, is this feature not implemented or I just can't figure out what is going on?

Thanks a lot.

Rodrigo

Check the build process to make sure there is always a clean build

Add some checks to make sure no old file is left in the build path

Add exception AcquireTokenSilentAdalExcetion

This is to make exception handling for error code failed_to_acquire_token_silently easier.

Refactor AcquireTokenForMSAHandler code in to another class.

The AcquireTokenForMSAHandler class repeats code that is already in AcquireTokenNonInteractiveHandler. Further, there really isn't anything MSA specific going on in the class. The code should be refactored to remove the redundancy and to remove the reference to MSA.

In ADFS case, should not generate GUID UserID in case of client only scenario

Update MRRT logic based on open id connect document

The current behavior to determine whether a refresh token is MRRT or not is based on presence of the field 'resource' in token response, but that needs to change as MRRT is a behavior of the STS, not the refresh token and needs to be determined from STS metadata using Open ID Connect Discovery.

Publish symbols for the latest build

Please publish symbols to help debugging.

Generate value for jti claim internally instead of receiving in the API

The jti value used in JWT token needs to be a unique value, but there is no reason to ask developer to provide it.

Also need to verify to make sure passing jti claim to AAD does not cause rejection of the JWT.

Contents of ADAL dialogs render too small and sometimes offset on Windows Phone

ADAL dialogs render at a very small size on Windows Phone, requiring the user to manually zoom in to be able to read the text or confidently click on buttons or input boxes. There is a large amount of empty white space which serves no purpose.

The dialogs also sometimes render offset, partially offscreen in one direction or another. Fixing this requires first zooming out, then zooming back in with a new center.

Both of these issues make the scenario feel unpolished and unprofessional.

[email protected]

Switch hashing algorithm in ADAL desktop to a FIPS compliant one

Switch from SHA256Managed to a FIPS compliant class

ADAL RT: AcquireTokenAsync(resource, ClientId) fails when app access to account info is off

Go to Control panel --> PC Settings --> Privacy --> General.
Make sure that option for 'Let apps access my name, picture & account info' is set to off.
This is the default settings.

In RT app, call
authContext.AcquireTokenAsync(resource, ClientId)

Getting below error.
"user_information_access_failed: Cannot access user information. Check machine's Privacy settings or initialize UserCredential with userId"

My app doesn't need to access any local info (authContext.UseCorporateNetwork = false). I should be able to get tokens without changing privacy settings.

Remove AcquireTokenAsync overloads without redirectUri from both WinRT and WinPhone

Here are the implications of this change:

1. Our interactive overloads become identical across .NET, WinRT and WinPhone.
2. Common code across platforms can be used.
3. We accept ‘null’ as a sign for ‘Application Callback Uri’ which means in WinRT, we call the WAB overload without callbackUri. In WinPhone, we never call that overload anyway (to be able to pass state parameter).
4. Developer also has the option of passing ms-app which would be pass through and give SSO functionality.
5. We preserve PromptBehavior argument as each of its values works in some cases depending on the other arguments.
6. No rename of the API would be needed.

AcquireTokenSilent should throw specific adal exception in case of no tokens in cache

Users can rely on exception and not errorcode/message for their fall back action.

try{
result = authContext.AcquireTokenSilent(todoListResourceId, clientId);
}
Catch(SilentLoginFailedAdalException)
{
}
Catch(AdalException ex)
{
}

Test WinRT silent mode with persistent cookies

In WinPhone, set PromptBehavior internally to appropriate value

We do not pass PromptBehavior explicitly in WinPhone, so we need to decide what value to use internally. Similar to WinRT, in non-SSO mode, it does not matter what value we pick. They are all the same. In SSO mode, the only case that makes difference is when user selects KMSI.

Pass ms-app Uri as is to WAB is passed as redirectUri