OAuth: Implementing OAuth 2.0
In a recent OAuth post, we recommended that if your API can require HTTPS, use OAuth 2.0. Otherwise, use OAuth 1.0a.
How should you use OAuth 2.0?
There are three types of credentials in OAuth 2.0.
BEARER TOKEN: This type requires SSL. A bearer token is a big random number. Bearer tokens are easier for developers than OAuth 1.0a because they don’t have to write the signature. This is the most straightforward of the credential types to implement. Use it!
MAC TOKEN: Like OAuth 1.0a, uses signature instead of SSL. The spec is still changing so I recommend that you wait.
SAML: Makes sense if the API Team and the developers really want SAML. The OAuth standards team is working on ways to use OAuth with SAML but that option is still changing. I recommend that you wait to implement SAML.
In short, I recommend that you use bearer tokens, as it is the simplest to implement.
How many legs?
I often get this question – how many legs does OAuth have and how many legs should I use?
Let’s look at the 3-legged and 2-legged terminology that’s developed around OAuth.
3-legged OAuth refers to the fact that there are three entities - a user, a client (application), and a server (service) involved. Both the user and the app have credentials.
2-legged OAuth refers to the case where the OAuth signature method is being used to identify just the application – that is, to identify just the client and not the user. This is often done using SSL. But the OAuth 1.0 signature can be used.
In my opinion, 2-legged OAuth uses only a part of OAuth and 3-legged OAuth is really OAuth.
If your API needs to authenticate users, you should use 3-legged OAuth. It has benefits for the API Providers and above all, it will mean improved security and better end user and consumer experiences with web and mobile apps.
Would love to hear your thoughts or questions over on the API Craft Google groups.