The App: The Authentication Stuggle Bus

The App: The Authentication Stuggle Bus

This is the end of day two of trying to get this working.

Basically, Microsoft has included this set of Mobile libraries to allow access to Azure Mobile Apps in order to make it really easy to connect up. Like every other one of these "enablers" the devil is in the details.

By using these libraries some of the techniques that I already know no longer apply. It may be that I have to write it from scratch anyway. Really wanted to avoid that.

Basically, the issue is this:

With Azure Mobile Apps we can authenticate the user by using their provider of choice, Facebook, Google, etc. But what those providers can't give us is the additional information relevant to our app. Like: is this person an employee, or a manager or just a customer? Are they signing up, or signing in. For that data, we need to access our own databases.

But...

I don't want to access our database every single time the app makes a request, that would be very slow.

Normally, when a user is authenticated, a token gets stuffed into the header of the HTTP request. That's like scribbling some info in indelible ink on the outside of the envelope before you mail it. Each additional bit of information (such as your name or email address) is called a "claim".

HTTP, Azure Mobile Services and the OWIN stack are really good about making sure that token flows back and forth between the server and the device so you can count on always having that information. That means it's really efficient to see if someone is authenticated on every single request made to the server. That's the only responsible approach to security.

But the information I want to add is more about authorization. Now that we know who you are, using authentication, we need to know what you are authorized to do.

I need to add our own claims to the token, sign it and seal it (with that indelible ink) and stuff it back into the HTTP headers so I don't have to go get it again.

I've done this before, but in that case I was using the Azure Active Directory Business to Consumer approach (AD B2C) and I've had to abandon that because I don't really have any way to make it work on the client. The server is great, naturally.

So today I messed around with AuthorizeAttribute classes to see if I could make those changes. It won't work the way I did it in the past. I could probably force it, but man, would it be ugly.

The added concern is that the Mobile libraries take care of things like storing the tokens on the local device to keep the user from having to authenticate each time they restart the app (which would suck). And they handle what are called refresh tokens, which is a way to get a fresh token all over again without having to login if you haven't used the app in a while. If I write my own stuff, I may well lose all of that.

I've posted some questions in an active forum at Microsoft. I guess I'll just wait to see if anyone replies. I'm thinking Tuesday.