Authentication, Authorization and other things we shouldn’t worry about any moreBy eidias on (tags: authentication, categories: architecture)
Recently I needed to do some research on the topic of authentication, authorization and related stuff. After spending quite some time on it, I was pretty depressed – one would imagine, that a topic so common has already been handled in a standardized, common and comfortable (both for the user and the developer) way – well, it hasn’t, or do I demand to much?
I had a couple of requirements (obviously) which were:
- single sign-on
- cross platform possibilities
- security (hmm, secure authentication, that’s interesting)
Doesn’t look like much – at least that’s what I thought, but let’s expand the topic a little more.
Single sign-on for me meant that we should be able to handle logging in with you’re favorite identity provider like LiveID, Google, Yahoo, OpenID and of course, for those that do not use these, or prefer to create a profile on our system there should be a possibility to do so. Personally, I hate creating a new account every time I try to log in to any application – and I can hardly ever remember the email I used for registration or the password.
Cross platform possibilities meant, that our system will have several clients on different platforms – there’s going to be a web app, a wpf client and a mobile client (wp7, android, iOS – maybe for one of them, maybe for all). So the authentication and authorization needs to be possible on all of the mentioned platforms
Security – we’ll that should be obvious.
So I started digging, and what did I find…
- Passport authentication mode is deprecated
- LiveID uses OAuth WRAP for authentication
- Google and Yahoo are both OpenID providers
- Microsoft provides a package called Windows Identity Foundation which uses a bunch of protocols (WS-Federation, WS-Trust, …) to perform authentication and authorization which is utilized by Windows Azure Access Control Services – which are at the moment free, but that won’t necessarily stick
- There’s a Windows Live SDK which provides some sort of means to authenticate using LiveID (no luck in using it)
- The recommended way of securing oData services is using OAuth 2.0
- Google supports OAuth 2.0 but the api is in beta stage (but on the other hand, what’s not a beta in google…)
So, in order to secure a web application along with oData services that it provides, I’d have to support OpenID, OAuth WRAP, OAuth 2.0 and custom authentication. At first I thought that it’s not going to be a lot of work, but that assumption turned out to be wrong.
The easiest way to achieve my goals was the windows azure approach (it’s described here) – that handled the web part of our system, but as it turns out it’s not really possible to utilize in wpf, so it would require a service that would be between the wpf client and the azure service. That could probably be handled using WIF, but building something like that would involve a pretty decent amount of work. Who knows if windows phone 7 wouldn’t require another custom layer.
All of these thing piled up into one big project, and I just needed a common way to handle authentication.
In the end I decided to go with the good old forms authentication. It’s quick and easy to implement on any device (get the authentication cookie and send it with each request), it’s not attached to any platform, so I won’t have to worry that it’s not going to be possible to implement it in an iOS app, and provided that obtaining the authentication cookie is handled via SSL – it’s pretty secure. The authorization part is going to be performed inside the data service and all should be good.
I'm not particularly proud of this solution – it’s not very agile, but it should work and well, simple is always better. In the next post, I’ll show you how to wire everything up.
If any of you guys have a better idea, I’d love to hear it.