In the previous few blog posts, I’ve talked about what OAuth is and when and why I recommend it.
This time, let's explore some of the reasons why OAuth is more cumbersome and complicated for developers than plain passwords as well as some recommendations to help you make the decision between OAuth 2.0 or 1.0a.
Because OAuth eliminates password sharing between web apps, and password storage on mobile devices, and importantly for the sake of your end-users’ experience and security, I believe it is worth the effort.
How many versions of OAuth and which one should you use?
OAuth 1.0 The first "production" version of OAuth 1.0 didn't actually do authentication delegation correctly and as a result, the spec itself had to be patched. No one should be using OAuth 1.0 now.
OAuth 1.0a Not an IETF standard but stable and well understood.
Uses a signature to exchange credentials between client and server. This means that you get API security without SSL (not only is the password never exchanged but the OAuth token is never exchanged – it’s encrypted inside the signature). But coding the signature right is tricky.
OAuth 2.0 Actively under development in the IETF.
It is getting more stable and changes less with each draft – core flows are unlikely to change. Supports a ‘bearer token’, which is easier to code than the signature but requires SSL. However, most APIs should be using SSL by default anyway. Optional specs support signatures, SAML, and so on, but those specs are not yet stable.
The authentication dance is painful
There are a lot of great sites where you can get the details of the OAuth 1.0a authentication flow chart, so I'm not going to tackle that here. It’s not simple. It gets a little simpler with bearer tokens in OAuth 2.0 but because of the security requirements and the fact that you have to exchange identity without a password, it's always going to be a little complex.
Signatures are painful
The good news is that in OAuth 2.0 signatures are optional. You can do SSL and use a bearer token.
As I mentioned above, getting the OAuth 1.0a signature algorithm right is difficult. If you’re going to use OAuth 1.0a, I recommend you use one of the many libraries that are available.
Where do you store the credentials on the client?
There is no magic. You have an OAuth token and secret that needs to be on your mobile device and accessible.
You could encrypt it, but then you need access to the key that decrypts it. You could also break them into smaller pieces.
What should you do?
Be patient. If your API can require HTTPS, use OAuth 2.0 with bearer tokens. (Use the latest draft of 2.0.) Otherwise, use OAuth 1.0a.
It's possible to build an effective API right now using either a current draft of OAuth 2.0 (see Facebook) or OAuth 1.0a (see Twitter).
Bottom line, with your end-users’ experience and security top-of-mind, I believe OAuth is worth the effort.
Next time: Implementing OAuth 2.0