Two Legged OAuth Workflow

Question

I'm trying to use two legged oauth to allow a mobile client to log into an api I've created, however I can't quite grok the proper workflow for this and all the tutorials seem to say something different.

From what I've read in the two legged version the oauth consumer key and consumer secret are specifically assigned to a user, and the tokens aren't used. So when a user logs in they (or their device) would have to present their consumer key and secret and we can use that to verify their identity. But then what? Does the client device receive some token that they use to access the API, or do they send the consumer information with every request?

And the user can only be expected to remember a username and password, how do we get from username and password on the client device to a consumer key and secret to send to the server?

Answer 1

You shouldn't have a consumer key/secret pair for each client device. The OAuth notion of "consumer" is a particular site or developer using the API to authenticate to you. Who is creating the username/password pairs? Are these specifically your user accounts, or are you looking for users to be able to log into you with Yahoo, Google, etc. accounts?

At any rate, I would expect the users to have a username and password, not a consumer key and consumer secret.

Answer 2

2-legged OAuth removes a separate authN/authZ server that talks directly to the client that is otherwise present in 3-legged OAuth. It certainly does involve (access) tokens. The client device would receive a token and could use that until it expires.

The advantage of this setup is that you do not need to worry about the security of the client_id/secret on every API call. Sending client_id/secret on every call is basic authentication, and it is not recommended. Instead, by using OAuth, you only need to worry about the security of client_id/secret on the API call used to get the token (e.g., once for the life of each token). And if a token is compromised, it has a TTL, whereas client_id/secret do not.

The client_id/secret are not known to the end-user who provides their own user credentials. The client app is expected to handle the negotiation of client_id/secret for token.