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]

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.

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

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?

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.

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)
{
}

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.

Switch from SHA256Managed to a FIPS compliant class

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.

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)

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

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.

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.

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.

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.

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

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.

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.

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?

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

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.

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#

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

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.

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

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.

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).

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.

"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."

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.

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.

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...

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…

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.

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

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

if ADAL_WINPHONE

            return "ARM";

else

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.

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 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.

Please publish symbols to help debugging.

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

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.

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.

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]

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.