OAuth Flows - Extended

Updated: Revised flow to add javascript implicit flow.

I received a lot of interesting comments on my previous post, "Does OAuth Have Legs". That post was about trying to understand what was meant by legs in OAuth. It included a useful diagram which I have since updated based on feedback. The revised diagram is available below (click to enlarge).

A couple of notes:

• The flows depicted are from the perspective of what a client app has to do to access a protected resource.
• The general consensus was that "legs" was meant to refer to parties and not the number of steps though co-incidentally, it was often the same. The consensus on the OAuth mailing list seems to be to now refer to, 2-party or 3-party flows.
• Each party has one or more "roles" as defined in OAuth: Resource role (the resource being requested), Token Service Role (the server issuing access tokens), and Authorization Service Role (the server that determines if the end-user has granted permission, and if not obtains it).
• The Implicit Request (OAuth v13, sec 4.2) is actually a dual-role request. It requires that the authorizing server also issue tokens. I have put this in a separate "dual-role" box in the diagram.
• There may be additional exchanges not shown in the diagram such as logging in the user in order to obtain authorization. These are not shown since they are out of scope of the OAuth specification and should not impact the client (i.e. because authorization is obtained from the user using an external browser).