Why is there 3-legged OAuth2 when 2-legged works so well?

Question

2-legged OAuth2 is used for Browser based app, where no client credential can be hidden from public. 3-legged OAuth2 is used by "Web Server Apps" where there's a third call between servers. All well described here.

The question: Why bother with 3-legs, when 2-legs seems to be fine?

It's more work both for the provider and the client. Why didn't one of the big player make a move and removed 3-leg?

Answer 1

Three legged does not imply a certain type of app as in "browser based". Three legged means that an application acts on the direct behalf of a user. In the three legged scenarios there is

1. an application (consumer),
2. a user (resource owner) and
3. an API (service provider).

In two legged scenarios there is no concept of a user. Typically this has to do with application-to-application solutions. There the application (consumer) acts on behalf of itself. So in two legged OAuth, there is:

1. an application (consumer),
2. an API (service provider)

The difference is simply that there is no need of a user authorisation step in the 2-legged approach.

Answer 2

2-legged scenarios exist. For example check the documentation about Google Apps domain-wide delegation of authority. Of course they can only be used in a trusted environment by a super-owner of the accounts - In the example I referred to above: a Google Apps domain administrator being the super-owner of all the users accounts of the domain he is administrating.

3 Legged has to be used in an open web environment of course. You do need the approval of the resource owner to grant access to its data to a third-party application.