5
votes

I have been exploring OAuth version 1.0 for the REST API I am currently working on.

I have 3 authentication scenarios

  1. this involves 3 parties, the service provider, the consumer and the user. The 3-legged Oauth matches this scenario.
  2. 2 parties are involved, the consumer and the service provider. Is this a scenario where 2-legged Oauth is most applicable and if so what is the process as there is hardly a difference between this and HTTP basic authentication based on my understanding.
  3. I also am creating a special type of user that can always access the currently logged in user's data without the user's authorization. How can this fit into the picture while still implementing OAuth.

Using this scenarios? how can I implement Oauth neatly and how can this help me understand the 3-legged and 2-legged Oauth processes?

1
You would store only the access token instead of the password. So, its more secure (no passwords stored) and access can be revoked on a per-app basis (changing your password would have broken all apps that needed that account)Jesvin Jose

1 Answers

1
votes

Number 1: Correct, just use the typical 3-legged oauth flow.

Number 2. 2-legged oauth is pretty much the same as http-basic, except that the oauth signature gives you protection agains MITM attacks (but if you use http-basic over TLS than you get the same protection). The process for 2-legged oauth is just the signing of the request with the consumer key/secret which is synonymous with a username/password over http basic.

Number 3. I'm not 100% clear on what you mean here, but it sounds similar to how google uses 2-legged oauth for google apps domains. Take a look at their documentation here: https://developers.google.com/accounts/docs/OAuth#GoogleAppsOAuth

Have you looked into OAuth 2.0? It's still in draft, but it has a lot more flexibility for different scenarios. May be something to consider. http://oauth.net/2/