The App: Authentication - Wow This Is Hard

Authentication is the process of making sure you are who you say you are.

The App is a consumer facing app and that will certainly require authentication by a variety of third party Identity Providers; think of Facebook, Google, Amazon, Twitter, Microsoft, LinkedIn, etc.

No one want to remember yet another username and password and I certainly don't want to be storing PII (personal identity information) on my site. That's a great way to give all your money to attorneys.

The trick is that the whole authentication landscape is a collection of slightly different interpretations of a standard (oxymoron, no?) and not yet complete implementations of tools to access them.

There is Active Directory Authentication Library (ADAL), Azure AD B2C, ThinkTecture's Identity Server v3 and Azure Mobile App Authentication. Each one is slightly different and has pros and cons that vary from platform to platform.

AD B2C is awesome in that it abstracts away the entire process, give The App one place to go for everything. Importantly, they also handle:

• Sign up flow
• Sign in flow
• Local identities (for those who don't want to use FB, Google, etc.)
• Branded user interface interactions
• Token storage
• Refresh tokens

This is a great list. Basically, I just make a call to their service and when it returns, I have an identity token for the person who just signed up/in. All interaction is handled on their servers.

The problem is, there is no sample code for Xamarin forms, and in fact, you can't even use the current ADAL libraries. You have to use some "Experimental" libraries and it's clear they're not fully baked yet. After spending two days with them, I have officially given up on AD B2C. There are guys who have it working, but I can't figure it out and they are not sharing their code. So, maybe in the future.

So we're going to use the Azure Mobile App Authentication.

This is a setting you can put on your Mobile App API that simply says everybody must be authenticated before they access any of your endpoints. OK, sounds great. But here's the rub: You have to specify what happens when an unauthenticated user reaches a protected endpoint. They way they have it set up, you can select an Identity Provider, such as Twitter, and everyone who isn't authenticated gets redirected there. Works perfectly and couldn't be more simple.

Except... If you want to have multiple Identity Providers that won't work. So you can change the Azure Mobile App setting to not redirect automatically, but then I'm back to adding that code into my app, which is what I was trying to avoid.

The alternative is to protect the spots in my endpoints in code and turn Azure Mobile App Authentication off, but that's just a variation on the above and I still have to write the code manually to manage the process.

Not to mention the additional work of getting stuff from the Identity Providers so people don't have to re-enter stuff that the system should be able to pick up: name, email address, and so on.

Time to do more digging to pick the best of the above approaches.