The App: Security Selection and Considerations

This has been far more difficult than it ever should have been. None of the pieces of the puzzle ever seemed to fit. But here's what happened and what we're doing:

Constraints:

1. The client (device) side has to run in Xamarin Forms as this is the basis for all non-web users. That means that whatever library we're using has to be available on iOS, Android (the last four or five versions, anyway), Windows and the web.

• The server side has to run on Azure Mobile apps because of the scaling options and built in push notification, authentication/authorization and table support. Not to mention libraries for just about everything else we're trying to do.

• We can't risk storing usernames and passwords anywhere in our system. That rules out any homegrown identity solution. That means we are reliant on external identity providers, such as Facebook, Google, Microsoft, etc.

• Users change social network information all the time. We all know at least one person who has dropped out of Facebook (and I expect that to happen more as it becomes less popular with adults). This means that we must have an identity that is assigned to our app. It's the only way we can be sure that no one loses their connection with the app.

• At the same time, people do like to use social networks as alternative logins for convenience alone, especially the hassle of remembering yet another password.

• In selecting an identity store that is unique to us, the obvious choice is something based on Microsoft Azure, but using a corporate Active Directory account would cost us $1 per month per user. Not bad for corporate America, but absurdly expensive for a consumer facing app.

• That lead to Azure B2C, a consumer facing identity provider that stores data in an Active Directory tenant at Microsoft, but does so for pennies. This is affordable.

• B2C allows customization of the user experience and interfacing to select social identity providers.

So we clearly have to go with B2C for our local accounts. We could go directly to Facebook, etc. for our social identity providers, but there are issues with that. The design we've chosen will permit that in the future if it becomes desirable.

Configuration The Client

The client devices (including browsers) have to connect to our servers as well as the identity servers. And this is where it gets ugly.

Best practices suggest that the client make a direct connection to the desired identity provider using a native SDK supplied by the identity provider. So we'd need the following packages for:

1. Facebook

• An Android library
• An iOS library
• A Windows library (more if you thought you wanted to do Windows Mobile, 8.1, UWP, etc.
• B2C (our accounts)
• An Android library
• An iOS library
• A Windows library (more if you thought you wanted to do Windows Mobile, 8.1, UWP, etc.
• Google
• An Android library
• An iOS library
• A Windows library (more if you thought you wanted to do Windows Mobile, 8.1, UWP, etc.
• Microsoft Personal accounts (that you would have on a Windows PC)
• An Android library
• An iOS library
• A Windows library (more if you thought you wanted to do Windows Mobile, 8.1, UWP, etc.

I tried working with the following Xamarin components:

1. XamarinAuth - Doesn't seem to be getting a lot of support. Basically it just uses a WebView to attempt to login at whatever identity provider you choose. Lots of outstanding support issues and not much activity on the component. Nope.

• Auth0 - Neat. Naturally supported on everything. Way out of our price range.
• ADAL - the Microsoft Active Directory Authentication Library. Works on all the platforms, just not on B2C, even though B2C is an AD tenant. And while this library works well, it's being deprecated for MSAL in the future.
• Azure Mobile App Client library - This attempts to login to our server and if it's not authenticated, the server automatically redirects to B2C prompting the user to login. This works reasonably well, but will not allow us to issue our own identity tokens - which is a requirement for security purposes. This is, effectively, a server controlled approach which is the opposite of the best practices approach as recommended by most developers.
• Custom authentication This allows us to add the security information we need so long as some other identity provider is supplying the authentication. I'm not sure exactly what the flow looks like with the web application if we use this.
• MSAL Microsoft Security Authentication Library is the new library that MS wants everyone to use. It's not really quite ready, though. It appears to work on all the Xamarin platforms, and it does connect to B2C. There are reported issues with social identity providers, but local accounts are supposed to be solid.
• Facebook Component for Android Installing this corrupted my solution. Took me half a day to get it out.
• Facebook for Xamarin Forms The link takes you to a high school homework site. Seriously. Zero documentation.

So the current plan is this:

1. We use the server approach and let the Azure Mobile App Client library tell our servers to use the B2C server flow. Once that authentication is complete, we can use the resulting access token to make another client library call to our custom endpoint, adding the security information we need. This works, it's stable and smooth. It makes at least one (maybe two) more network hops than the client approach and so authenticating takes a bit longer than I like.

• We can also use the client approach using the MSAL client library to authenticate against B2C and using the resulting token with the mobile client library to call a different custom endpoint. This is faster and seems like a smoother user experience. The drawback is that it is still in alpha (not ready for production use).

I'm going with the server approach for now.