Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 09 Mar 2011 21:45:41 +0100

Hi Phil,

that's great help for anyone looking for advice how to use OAuth.

One remark: In my opinion, the decision process for authorization code 
vs. implicit grant involves more parameters.

refresh token required? --> authz code
client in question is a web application? --> authz code
client in question is a JavaScript app? --> implicit grant
client authentication required --> authz code
else --> implicit grant

regards,
Torsten.

Am 22.02.2011 01:45, schrieb Phil Hunt:
> FYI. I published a blog post with a flow-chart explaining the legs of OAuth.
> http://independentidentity.blogspot.com/2011/02/does-oauth-have-legs.html
>
> Please let me know if any corrections should be made, or for that matter, any improvements!
>
> Phil
> [email-masked]
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Wed, 9 Mar 2011 13:02:07 -0800

Torsten,

Thanks!  Yes...I kind of omitted some of the flow decisions to keep the diagram simpler.

I also note that there has been quite a lot of discussion on the pre-ambles to Implicit grant, etc.

That said, I'm not sure I like binding application type (web app, javascript app) to a particular flow. Some have said that the spec shouldn't deal in best-practices (what flow should be used by specific client types) as much as just focusing on the normative requirements for each flow type. 
It seems conceivable to me that people will come up with new scenarios that don't fit the current definitions and the spec will 'break'. 

With that  in mind, the only real difference I saw between 4.1 and 4.2 was one had client auth and an extra step, and while implicit did 2 steps at once with only user authentication as a requirement.

Though this has been discussed on another thread and I'll probably update once a decision is made (draft 14?).

Phil
[email-masked]

On 2011-03-09, at 12:45 PM, Torsten Lodderstedt wrote:

> One remark: In my opinion, the decision process for authorization code vs. implicit grant involves more parameters.
>

---

From: David Primmer <[email-masked]>
Date: Fri, 18 Mar 2011 15:55:49 -0700

Hi Phil,

I actually think this rephrasing of the rule of thumb is not really
helpful based on how the word "legs" has been used in my experience of
discussing and teaching OAuth. I actually tried to be pretty explicit
about this topic in a talk I did at Google I/O last year because we
have lots of questions about 2 versus 3 legged OAuth since the launch
of the Google Apps Marketplace.
http://www.youtube.com/watch?v=0L_dEOjhADQ. I speak about 17mins in.

We have traditionally used the terms two legged OAuth and three legged
OAuth to describe the trust relationships involved in the grant. I
think your interpretation is very different and not a common way to
use the terms 'legs' in relation to OAuth and will simply confuse
people. 2LO involves a client authenticating itself to a server. 3LO
involves those two previous actors, plus a user/resource owner who
delegates permissions to the client. In everyday use, 2LO is 'server
to server' auth with out of band permissions and user identity and 3LO
involves an individual grant where the user's grant is identified by a
token given to the client and passed to the server on access. Another
way to look at it is 2LO is just HTTP request signing.

davep

---

From: Phillip Hunt <[email-masked]>
Date: Fri, 18 Mar 2011 17:06:57 -0700

I agree with what you are saying. We were having trouble understanding legs too, so I came up with the diagram. The diagram does show the parties aspect. But I remain uncomfortable about the terminology. 

Phil

Sent from my phone.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 18 Mar 2011 17:20:27 -0700

The legs terminology is just plain awful. I prefer parties, roles, anything else.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Phillip Hunt
> Sent: Friday, March 18, 2011 5:07 PM
> To: David Primmer
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth
> 
> I agree with what you are saying. We were having trouble understanding legs
> too, so I came up with the diagram. The diagram does show the parties
> aspect. But I remain uncomfortable about the terminology.
> 
> Phil
> 
> Sent from my phone.
> 
> >> http://independentidentity.blogspot.com/2011/02/does-oauth-have-
> legs.
> >> html
> >>

---

From: Anil Saldhana <[email-masked]>
Date: Sat, 19 Mar 2011 13:37:22 -0500

I agree.  "2 party oauth", "3 party oauth"  tells  what it is, rather than
"3 legged oauth".

On 03/18/2011 07:20 PM, Eran Hammer-Lahav wrote:
>> On 2011-03-18, at 15:55, David Primmer<[email-masked]>  wrote:
>>
>>> Hi Phil,
>>>
>>> On Mon, Feb 21, 2011 at 4:45 PM, Phil Hunt<[email-masked]>  wrote:

---

From: Phil Hunt <[email-masked]>
Date: Wed, 23 Mar 2011 11:11:54 -0700

FYI. I have posted a new version of the flows on my blog showing the new terminology as discussed here.  Feedback appreciated.
http://independentidentity.blogspot.com/2011/03/oauth-flows-extended.html

Phil
[email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 23 Mar 2011 20:56:04 +0100

Hi Phil,

looks even better now :-)

As already pointed out 
(http://www.ietf.org/mail-archive/web/oauth/current/msg05599.html), 
"Have client credentials? No" does not automatically imply usage of 
implicit grant. The client could also use the authorization code (for 
various reasons).

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 31 Mar 2011 16:41:49 -0700

On Wed, Mar 23, 2011 at 12:56 PM, Torsten Lodderstedt
<[email-masked]> wrote:
> (http://www.ietf.org/mail-archive/web/oauth/current/msg05599.html), "Have
> client credentials? No" does not automatically imply usage of implicit
> grant. The client could also use the authorization code (for various
> reasons).

+1, no client credentials does not necessarily imply the implicit grant.

Marius

---

From: Phil Hunt <[email-masked]>
Date: Thu, 31 Mar 2011 16:46:30 -0700

Thanks, I'll put it on the next version.

Phil
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Thu, 31 Mar 2011 16:56:45 -0700

Done. 

It isn't quite what the flow shows in the earlier diagram. I was originally avoiding client type and trying to focus on section 4 options.

But this should be a better diagram.

Phil
[email-masked]

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 31 Mar 2011 18:00:27 -0700

> http://independentidentity.blogspot.com/2011/03/oauth-flows-extended.html

A native app with no client secret is still advised to use the
implicit grant, which is wrong IMO.

The right question I think is "does the client need long term offline access"?

JavaScript clients typically don't need offline access (only with the
user at the browser). Some native apps and web apps could be OK with a
short term offline access, one off import for example.

Marius