OAuth 1.0 - how to implement both 2-legged and 3-legged authentication?

Question

I have implemented an OAuth 1.0a provider and have OAuth clients that can successfully authenticate against it, using the standard 3-legged authentication.

OAuth protects a REST API on my server and I have a mobile app consuming it.

In my mobile app, I have some functionalities (endpoints) that can be accessible even before the end-user logins to their private account.
Some user may even just want to use the public functionalities without creating an account.

I would like to protect with OAuth both "public" and "private-to-the-user" endpoints.

Therefore I think the way to go is to use OAuth the following way (but I may be wrong...very wrong).

The mobile app will first do 2-legged authentication as soon as the app is launched the first time. That way the mobile app will get a "2-legged" token. The mobile app will use this token to access public endpoints.

When (and if) the user requests to login to the application, the mobile app will do a 3-legged authentication and will get a "3-legged token". From now on, the app will forget about the previous 2-legged token and use the 3-legged token to access both public and private endpoints.

1) First question. Does that make sense? Is there another good way to do that?

Now my problem is: how can I (the server provider) know whether the mobile app wants to authenticate using 2-legged? I guess, as the provider, I need to know that in order to decide whether I will redirect the client to the login form for the user to fill (in the case of 3-legged) or I will just issue an already-authorised request token (in the case of 2-legged) so that that can be exchanged for an access token (as for the 3-legged).

My idea for doing that was to provide the client with 2 consumer keys: one to use when they want 2-legged and one to use when they want 3-legged. Me, as a provider, I will know which flow to provide based on the consumer key I receive.

2) Second (and last question). Is this sensible? Is there a better way to implement it?

I have seen people implementing 2-legged by just allowing the client (consumer) to send an empty access token. Is that the way, instead?

Thanks.

Answer 1

OAuth is intended to manage access to your REST API by third party applications. E.g. some other company develops an app that will consume your API. And you do not want your customers to provide password to these services to third-party. In this case OAuth is the solution. If there is no third party applications then no OAuth is required.

If you have single service and just your apps consuming it then you do not need to implement any OAuth. You need to create usual user/password login (and probably right check) mechanism.

Using HTTPS is enough to secure end-points interaction. If you want to secure store content on mobile app or some other REST consumers then you will have to encrypt it before saving.

UPDATE: If you want to protect "end-point", then 3-legged OAuth is the solution. 2-legged solution will require to install third-party app + your OAuth app (or lib) to the user device. Otherwise user might be fakened by similar UI and just give some third-party user and password.

• 2- and 3- legged OAuth comparison
• If your REST API service is java-based the best solution is to twitter OAuth library.
• The best java OAuth consumer lib (I found and use) is Scribe