5

After hours of googling, reading MS documentation and code samples, I am now just more confused, and in need of some architectural advice.

Basically I need to work out which APIs are applicable and how to start with them.

Background

I have an existing app (currently a XAML + c# win store 8.1 app) with a WebAPI 2.2 odata (and also some MVC pages) backend.

The client app runs nicely on Win 8.1 and win 10 machines The server side is in an azure VM.

Currently

  • Users are logged into the app (as the user they are logged into windows with) using their Microsoft Account
  • They do not have to type usernames / passwords, they simply accept the permissions (1x) I specify with the scopes e.g. "wl.basic", "wl.emails", "wl.calendars"
  • To do this I am using the Live Connect libraries (Microsoft.Live.dll, v5.6.0.0)
  • I then get an AuthenticationToken from LiveLoginResult

e.g.

_loginResult.Session.AuthenticationToken
  • Which I pass up to the server along with the odata requests.
  • The server uses this to find their LiveID / UserID

e.g.

LiveAuthClient authClient = new LiveAuthClient(clientId, clientSecret, redirectUrl); 
string liveIdGuidAsString = authClient.GetUserId(authenticationToken);
  • Which I then use to find the relevant user in my DB and serve their odata content down to the client app

All is good.

I want to extend my application to synchronize with / integrate with the user's Outlook's calendars

Seems the sensible way to do this these days would be either using

  • Outlook REST APIs
  • MS Graph

It also seems MS might turn off the Live APIs I am currently using at any time?

https://msdn.microsoft.com/en-us/library/hh243641.aspx

Additional Complexity

I'd also (in a couple of months time) like to extend the application to

  • be X-platform (probably using Xamarin traditional with PCL code sharing and "xamarin traditional" platform specifc projects for UI, probably using MVVMCross)
  • allow users to use other services for authentication (all OAuth 2.0) - e.g. google / gmail accounts

This means I'd like if possible to make things as "raw OAuth" for compatibility and NOT tie myself to any particular MS APIs (obviously the outlook / outlook.com calendar integration would only be a feature available to those users with MS accounts)

Also, some existing users have outlook.com accounts (which they use to login to windows with) but have their calendar data in Hosted Exchange 2010

Seems to access this calendar data, these users would have to either move all their outlook 2016 data into outlook.com, or be setup as office 365 accounts and have the data migrated up to the new accounts.

Questions

1. Where / with whom should I authenticate to get my authorization code and access token - MS Graph ? or Outlook REST API

I have seen this answer (i.e. basically prefer MS Graph)

2. Can I retain the awesome "no username / password, just accept permissions functionality" for my Users on Windows 8.1 and 10 using "Microsoft Accounts" ?

Certainly with MS Graph it seems my Outlook.com / Microsoft Account users would not be able to continue to login to my app based on their windows user without Username + Password?

Documentation also seems to suggest that to use that to use MS Graph my users will need to be Office 365 / Azure Active Directory so to try and minimise impact, and keep a wider audience should I use Outlook REST APIs

But then the suggested library for the Outlook REST APIs seems to be ADAL which seems to rely on Azure Active Directory? So will my existing outlook.com users not be able to use this?

3. How long do I have to replace the Live SDK and be using something else?

Basically I am baffled by the array of options and considerations and could do with any advice whatsoever as to which direction(s) to take.

Community
  • 1
  • 1
MemeDeveloper
  • 6,457
  • 2
  • 42
  • 58

3 Answers3

3

There are other options here for you. We've not fully updated our documentation yet, so please bear with us. Microsoft Graph supports tokens issued by the new v2 endpoint - and this supports sign in with a Microsoft Account OR a work/school AAD account. After sign in they'll be asked to consent to allow your app access to their data. If they sign in with a Microsoft Account, MS Graph will route the service requests to their outlook.com mailbox, whereas with an AAD account it'll get routed to their O365 mailbox. Your app and the APIs your app calls (through MS Graph) work the same, independent of the type of user. We also have a new .Net client library for MS Graph, and a preview .Net client library for auth called MSAL (ADAL uses the v1 endpoint which only supports AAD, while MSAL supports the v2 endpoint which supports MSA and AAD).

We'll be releasing more samples soon, but we already have samples that demonstrate calling MS Graph, using MSAL to acquire tokens, which will work for consumer and commercial users: https://github.com/Azure-Samples/active-directory-xamarin-native-v2. Plus this sample uses Xamarin too!

Hope this helps,

Dan Kershaw - MSFT
  • 5,833
  • 1
  • 14
  • 23
  • That's amazing, thanks, I will check that all out and report back here. I had been trying to use ADAL - all makes more sense now ! – MemeDeveloper Apr 09 '16 at 13:57
1

I'm doing something similar right now. I'm using Xamarin.Forms and I'm working on the UWP/Windows side first. Here's how I think it's going to work in the long run:

  1. I'm using a PCL to write all the logic, so I have to use an interface that I load using var auth = DependencyService.Get<IAuthorization>(). This is a Xamarin trick so read about it to get the details.

  2. I'm implementing the UWP side using WebAuthenticationBroker:

    var startUri = new System.Uri($"https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={Constants.AuthID}&redirect_uri={WebAuthenticationBroker.GetCurrentApplicationCallbackUri().ToString()}&response_type=code&scope={WebUtility.UrlEncode(Constants.Scopes)}");

var webAuthenticationResult = await WebAuthenticationBroker.AuthenticateAsync(Windows.Security.Authentication.Web.WebAuthenticationOptions.None, startUri,
        WebAuthenticationBroker.GetCurrentApplicationCallbackUri());

  3. I have NOT figured out how to get SSO to work. However, in a UWP app, it remembers my login and password (and permissions) so I only need to hit the username when it prompts me to login. I'm still looking but the scope, wl-signin, is not working here.

  4. For iOS and Android, there is a Xamarin component called Xamarin.Auth which seems to have similar functionality to WebAuthenticaionBroker. I'll know more when I start to implement these features. (Just tested with Android and works fine for MS account...see comments for quirk.)

  5. These methods should work for all of the other services, too.

Lee McPherson
  • 931
  • 6
  • 20
  • That's great Lee - really appreciate the info. Am paused on this for the moment waiting for Auth0 to come back with info on their implementation of the MS stuff - basically want to know if they use the "new v2 endpoint" as @Dan mentions above - which it seems you are using there? – MemeDeveloper Apr 14 '16 at 12:16
  • I'm having problems with Xamarin.Auth for Android at the moment. If you look at the GitHub project issues, someone's reporting that it's not working at all. (I'm getting null reference exceptions after the modal window tries to close.) I read somewhere else that Xamarin is rewriting Xamarin.Auth completely and will demonstrate their new stuff at the end of April though. – Lee McPherson Apr 14 '16 at 14:08
  • I haven't tried to use Auth0 because it is a paid service. – Lee McPherson Apr 14 '16 at 14:09
  • Finally, according to docs, SSO is supposed to work when you use the overload of AuthenticateAsync that only has two parameters (the callback Uri is omitted) AND it is allowed on the server side. Well, it doesn't seem to work for me very well. I think it might be a caching problem, but I'm not sure yet. – Lee McPherson Apr 14 '16 at 14:11
  • 1
    It seems my NullReferenceException on Xamarin.Android was just a lost context problem in the debugger. If I don't hit any breakpoints inside the event handler for the login, it works just fine. So Xamarin.Auth so far works for me... – Lee McPherson Apr 14 '16 at 15:40
  • I'll report back here once I get onto this, so we can compare notes. Hopefully next few days. Also wondering - why Xamarin instead of using the MS .net native execution stuff (this MS stuff is all new to me) but have used Xamarin classic / traditional in the past (android + winRT app) with MVVMCross (which I'd recommend) – MemeDeveloper Apr 14 '16 at 16:33
  • I think since it's using UI elements to actually let you input your login and password (WebView or something like it), it has to be implemented natively. UWP apps have WebAuthenticationBroker that works perfectly. iOS and Android don't so it was implemented in the Xamarin.Auth package. There are alternatives such as using the native SDKs for each service... I've read that since Facebook has its own SDK for Android and iOS, you are required to use them for logins rather doing it yourself. Not sure if that has changed since those comments I saw were posted. – Lee McPherson Apr 14 '16 at 17:24
  • 1
    Wow, what a mess... I've been working with the Graph/Outlook/Live REST APIs since I can't figure out how to incorporate the beta SDKs into each of the Xamarin projects. It turns out that if you want access to the mailbox (or calendar) of the user, you're out of luck. The Outlook.com mailboxes have not been upgraded to get queried by the REST API yet. You can request a dev account that has it enabled though. This probably needs a whole new answer... – Lee McPherson Apr 15 '16 at 04:24
  • yes I had seen that - and saw that my own account was not yet enabled. I think if you create a fresh outlook.com account it will be enabled though, think they're working through a backlog of them pulling them over. This is what we get for being bleeding edge I guess ;) – MemeDeveloper Apr 15 '16 at 08:10
0

It seems Auth0.com is probably the way to go here, as should allow me to handle things fairly generically for various identity providers, including Microsoft Account and they seem to have an addon / connection type (enterprise) for Azure AD. Plus I used them before (although app never went into production) and was a pleasant experience.

It seems I should be able to get users logged in using Auth0 easily enough, and they have various client libraries for going x-platform (including xamarin)

The Microsoft Account (live) "social connection" seems to have scopes / permissions for accessing calendars etc.

I am not yet 100% that once logged in I will be able to access the MS Graph APIs / Outlook REST APIs on behalf of Azure AD users.

It looks like the Azure AD enterprise connection type only has some v limited permissions / scopes for the Azure AD APIs (i.e. listing users in the azure domain etc). However I have not yet added a connection for Azure AD, so perhaps those are not available globally but will pop up once I have done that?

MemeDeveloper
  • 6,457
  • 2
  • 42
  • 58