2

I recently updated to the stable version of Microsoft.IdentityModel.Clients.ActiveDirectory v3. I read here that the class UserCredential no longer support the overload UserCredential(username, password), and it has been renamed to UserPasswordCredential(username, password).

The old working code that worked in versions prior to v3:

var authContext = new AuthenticationContext(Authority);
var userCredential = new UserCredential(username, password);
var token = await authContext.AcquireTokenAsync(ResourceUrl, ClientId, userCredential);

Replaced by this in v3:

var authContext = new AuthenticationContext(Authority);
var userCredential = new UserPasswordCredential(username, password); /*Error UserPasswordCredential does not exist*/
var token = await authContext.AcquireTokenAsync(ResourceUrl, ClientId, userCredential); /*Error AcquireTokenAsync does not contain the overloaded method*/

Updating to v3 removed the overload of UserCredential as expected, but the new UserPasswordCredential subclass does not exist (atleast not in the same namespace, and with no help from VS light bulb helper).

I am using the [Platform] versions of ADAL for iOS and Android, as this project is a Xamarin shared project. Is there someone that can confirm it works in these versions of the library?

IDE: Visual Studio 2015 with Xamarin

Community
  • 1
  • 1
Simen Tjøtta Vie
  • 166
  • 1
  • 1
  • 10
  • 1
    I can't believe this is removed from the library, very frustrating, this is a completely valid and actually the preferred workflow for any native mobile client, popping up an ugly webview login UI to authenticate is very unsightly and disruptive to the user. I am trying to use this myself right now and am very disappointed to see that there is not clear documentation for it and that the previously obscure way of doing it has now been removed. Have you found any other good alternatives? – Dmitry Samuylov Oct 05 '16 at 19:06
  • 1
    @Dmitry we ended up using a completely different framework for our authentication. – Simen Tjøtta Vie Oct 11 '16 at 23:18
  • do you mind sharing what you ended up using? – Dmitry Samuylov Oct 12 '16 at 18:12
  • 2
    We ended up implementing and hosting an authentication server using the IdentityServer framework – Simen Tjøtta Vie Oct 14 '16 at 12:00

1 Answers1

0

This is by design. For xamarin you must use the webview.

Kanishk Panwar
  • 1,105
  • 8
  • 7
  • I can't seem to find any documentation around this. Am I right to say the intention behind this is to provide a uniform login pattern while going through AD login? – Simen Tjøtta Vie Jun 23 '16 at 13:18
  • Yes, webview is the way to go. – Kanishk Panwar Jun 23 '16 at 21:00
  • Do you know why this is "by design" by any chance? There's little to no information on this online that I was able to find. This is a very limiting and counter intuitive move, vast majority of mobile apps in the app store use a custom login/registration UI, this is what well built/designed mobile apps are known for, intuitiveness and ease of use, forcing a web view approach that you have no control over in terms of look and feel will undoubtedly make many choose another approach. – Dmitry Samuylov Oct 05 '16 at 19:20
  • Apps should not be collecting user credentials to authenticate. It breaks the purpose of oauth. In fact in the future we will delegate the auth to a system webview to protect user creds. – Kanishk Panwar Oct 05 '16 at 20:16
  • @Kanishk Again, this is an opinion grounded in trying to have the best security possible but not in reality, applications need to have control over the login/registration UI to make it a seamless experience on par with the top apps in the app store. The webview presented with Azure's sdk is not even responsive or mobile friendly, presenting a UI like that to your users is a quick way to lose trust and satisfaction of your users. I'm frankly very disappointed, no clear documentation of this, if I knew this was the case I would not waste time trying to use Azure for this. – Dmitry Samuylov Oct 12 '16 at 18:12
  • Well, it is a bad design IMO. Like now I have an application running under AirWatch where I can get username and password (collected by AirWatch) and it'd be highly silly to force user to authenticate again using a webiew. So, I really don't appreciate blocking this from us. – Miha Markic Jun 15 '17 at 14:29