MS Graph VS Outlook REST APIs, OAuth, Win Store / UWP, Xamarin, WebAPI, SSO, Live SDK deprecated - confusion

Question

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.

Answer 1

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,

Answer 2

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.