Subject: [OAUTH-WG] proposal of a paragraph to add to the security considerations section

From: "Shuo Chen (MSR)" <[email-masked]>
Date: Mon, 18 Jun 2012 20:19:38 +0000

Hi OAuth group,

This is regarding the recent discussion about an implementation issue of some cloud services using OAuth for authentication.
Derek Atkins and Dick Hardt suggested the possibility to discuss with the group a paragraph to add to the security considerations section.

Derek's suggestion:
====   ===  ===  ===
>> Perhaps you could boil it down to a paragraph
>> or two for addition to the security considerations section that basically says
>> "beware of implementing it *this* way because it leads to *that* attack vector", etc.
====   ===  ===  ===

Here is out suggested text:
====   ===  ===  ===
It has been observed that in multiple occasions that the server-side
authentication logic takes an access token from the client, then
queries the user's profile data from the IdP in order to
"authenticate" the user. This implementation must be forbidden. It
will allow an untrusted app running on a victim's client device to
work with an attacker's device to sign into the victim's account on the server side.
====   ===  ===  ===

Thank you.
-Shuo
p.s. below is the email thread giving a better context of the discussion.

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]]
> Sent: Monday, June 18, 2012 11:25 AM
> To: Shuo Chen (MSR)
> Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek
> Atkins; Dick Hardt
> Subject: Re: [OAUTH-WG] web sso study...
>
> Hi,
>
> "Shuo Chen (MSR)" <[email-masked]> writes:
>
>> Hi Hannes, Derek and Stephen,
>>
>> Thank you for your replies.
>>
>>> First, let me ask whether it is OK if I share your post with the
>>> OAuth WG
>>
>> Yes, please feel free to share it.
>>
>>> Second, could you describe the attack in more details to me?
>>
>> Let's consider the mobile+cloud scenario for concreteness (although
>> some other scenarios are also applicable). The attack steps are the
>> following: suppose Alice's tablet runs a Windows 8 Metro app written
>> by attacker Bob. This app is able to request and obtain an access
>> token from the IdP (associated with Alice). The app can then send the
>> access token to Bob's own tablet. Note that there is no security
>> problem up to this point. However the real problem is that some cloud
>> services use the access token to query the user's profile data from
>> the IdP in order to "authenticate" the user. In this case, Bob's
>> tablet will be able to sign into the cloud service as Alice. We have
>> confirmed that the cloud services for Soluto Metro App, Givit Metro
>> App and EuroCup2012 Metro App make this mistake. These are apps in
>> the official Windows 8 App Store. We actually sampled only a small portion of the available apps, but believe this is a vulnerability pattern.
>>
>> We don't think there is anything wrong in the OAuth spec. It is
>> developers who didn't comprehensively understand the usage of the
>> access token. In the meanwhile, this vulnerability pattern is not explicitly excluded by the spec.
>> More importantly, it has been seen in the wild.
>>
>>> [from Derek's email] Perhaps you could boil it down to a paragraph
>>> or two for
>> addition to the security considerations section that basically says
>> "beware of implementing it *this* way because it leads to *that* attack vector", etc.
>>
>> This is a great idea. I think that although it is difficult to
>> anticipate in general all kinds of incomprehensive understandings of
>> average developers, it is very worthwhile to take any common existing
>> vulnerability pattern as a precious feedback to improve the
>> specification text. In this case, since we have already seen this
>> vulnerability pattern on multiple services in the wild, certainly we
>> should be explicit about it in the security considerations section.
>>
>> Our suggested text:
>>
>> It has been observed that in multiple occasions that the server-side
>> authentication logic takes an access token from the client, then
>> queries the user's profile data from the IdP in order to
>> "authenticate" the user. This implementation must be forbidden. It
>> will allow an untrusted app running on a victim's client device to
>> work with an attacker's device to sign into the victim's account on the server side.
>>
>> Any questions or suggestions?
>
> Could you please send this to the [email-masked] mailing list?
>
>> Thanks a lot.
>>
>> -Shuo
>
> -derek
>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[email-masked]]
>> Sent: Friday, June 15, 2012 11:36 AM
>> To: rui wang
>> Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen Zhou;
>> Derek Atkins
>> Subject: Re: [OAUTH-WG] web sso study...
>>
>> Hi Rui,
>>
>> let me independently respond (in addition to the previous responses
>> you had already gotten).
>>
>> First, let me ask whether it is OK if I share your post with the
>> OAuth WG since it is more detailed than the one you distributed on the list mid April.
>>
>> Second, could you describe the attack in more details to me? What I
>> would like to better understand whether this the raised issue is a
>> problem with one of our specifications, with a specific
>> implementation of the IETF OAuth specifications, a problem with other
>> OAuth related work (Facebook, as you know, implements far more than
>> just the IETF OAuth specifications), a violation of the IETF OAuth
>> specification in the way how the Websites use OAuth, whether this is
>> a configuration related aspect, or an aspect we already documented in the threats document.
>>
>> The reason why I am so specific is to know where to put text to
>> address this issue or whether this is even an issue beyond the IETF
>> OAuth working group and needs to be tackled somewhere else.
>>
>> Ciao
>>
>> Hannes
>>

---

From: John Bradley <[email-masked]>
Date: Mon, 18 Jun 2012 17:04:16 -0400

I blogged about this in the hypothetical several months ago. http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

Nov Matake and others built some tests and found quite a number of deployments vulnerable. 
http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html

The bottom line is that OAuth has no explicit audience restriction for tokens,  hence accepting any token outside of the code flow is subject to attack.

In general it is not a issue for authorization,  it is however a big issue then there is a presumption that the presenter of a token that grants a client access to resource x is the "resource owner" of resource x, when it is possible that the presenter is any client who has ever had a access token for resource x.

We might want to include the why it is insecure in the security consideration,  otherwise people reading the below will likely ignore the advice as it seems on the surface a touch extreme.

There are certainly OAuth flows that allow you to do authentication safely,  just not all of them without additional precautions.

That is why openID Connect has a audience restricted id_token similar to Facebook's signed request to allow the implicit flows to be safely used for authentication.

John B.

On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote:

> Derek’s suggestion:
> will allow an untrusted app running on a victim’s client device to
> work with an attacker’s device to sign into the victim’s account on the server side.
> ====   ===  ===  ===
>  
>  
> Thank you.
> -Shuo
> >> We don’t think there is anything wrong in the OAuth spec. It is
> >> developers who didn’t comprehensively understand the usage of the
> >> will allow an untrusted app running on a victim’s client device to
> >> work with an attacker’s device to sign into the victim’s account on the server side.
> >> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Mon, 18 Jun 2012 17:20:35 -0700

John

Do you have suggested text per your suggestion below?

-- Dick

---

From: John Bradley <[email-masked]>
Date: Mon, 18 Jun 2012 22:50:51 -0400

I can put something together.   

It is mostly a warning about the token substitution attack that any implicit flow is vulnerable to if used for authentication of the presenter.
Otherwise known as why audience restriction is a good thing.

John B.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Jun 2012 12:27:36 +0300

Hi John, 

I read through your blog post. I am not sure whether I can entirely agree with your separation between authentication and authorization. I believe the core issue here is that 

* anyone who has the token will get access to whatever the token entitles him or her to do (unless there are restrictions in the token)

* some attributes are different than others. With authentication you typically associate that the process took place recently (i.e., it is fresh) while other attributes do not require the user (as resource owner) to actively participate in the exchange and the same level of freshness is not implied.  For authentication in a three party protocol to be useful the three parties have to participate (see http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt). 

I understand that one wants to avoid having tokens passed around from one application to the other one, as it is happening here. 

I remember having some of these discussions with Eran a long time ago. He anticipated that implementers will not put any constraints in the tokens and hence they will be misused. This serves as an argument for him to propose the MAC token specification. 

I proposed text for the security consideration section of the bearer document a while ago and it even talks about audience restriction as a recommendation. 

There are two problems with the audience restriction: 

1) There is no mandatory token format defined nor do we mandate token content either. Hence we do not strongly require anything specifically to be put into the tokens. 

2) In the implicit grant flow the client isn't authenticated and hence what do you want to put into a token as an audience restriction? 

Finally, I think that the "audience restriction" terminology is a bit fuzzy for this discussion either. 
Audience restriction can mean two things:

* Allowing the client to verify that the access token has indeed been issued for him / her. 
* Allowing the resource server verify that the received access token from a specific client has indeed been provided by that client. 

My current believe is that the implicit grant flow is unsuitable for providing authentication functionality. 

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Thu, 21 Jun 2012 09:47:23 -0400

Hi Hannes,

MAC tokens protect resources against token leakage to third parties.  That is useful but a different threat.  

The easiest way to get a access token for someone is to have them log into your site.   

If you can do that the token type makes no difference unless we move to a asymmetric holder of key token (different discussion).

The bad client gets the access MAC token and token secret and can re use it just as it would a bearer token.

The origin of the post was a contention by someone at Facebook that profiling OAuth 2.0 on its own is sufficient to produce an Authentication protocol.

I was trying to point out that OAuth 2 without any extensions, only profiling is difficult to impossible to use for authentication as the attack surface and security considerations are different.

As it turned out Facebook had extended OAuth 2 with signed requests and token introspection techniques to address these issues for themselves.   

The problem as it turned out was that individual apps and  app frameworks like the iOS one made some bad mistakes, by not using the perhaps under documented extensions.

The problem is not unique to Facebook in any way they are just a convenient example.

Oauth 2  is not surprisingly mostly about protecting the resource.  

Authentication is about protecting the client.

Audience restriction from openID 2, SAML,  WS* etc prevents replay of tokens issued to one RP/SP at another.  
That is sort of authentication protocol threat number 1.

OAuth has no way to do that with access tokens.

It can however do it with "code" if the client is confidential.

So my recommendation is that without extensions to OAuth like structured tokens (signed_request, id_token) or token introspection endpoints like 
Facebook ( https://graph.facebook.com/app?access_token=[The Access Token]), there is no safe way to use an implicit flow for authentication.
A code flow where a native app exchanges code for the access token and then passes the access token back to it's server is also vulnerable (lots of this in circulation I understand)

The only safe flow (without extensions) is the code flow where the client is confidential and the code is directly exchanged for the access token.
This also requires the definition of a identity API that is protected by the access token, and out of scope for OAuth.

So at the end of the day the rational conclusion is that OAuth 2 is a authorization protocol.   
It may be used by Authentication protocols, but it is up to other specs to define the security considerations for that.

That however doesn't remove the need to mention the token substitution attack that non confidential clients are subject to, do to there being no other mechanism for the client to know who the token was issued to.

John B.

---

From: Eran Hammer <[email-masked]>
Date: Thu, 21 Jun 2012 14:17:08 +0000

The sad reality is, we've spent 3 years producing a specification that is less secure, more complex, and does not interoperate the way OAuth 1.0 does.

It does scale better for huge companies like Google, Microsoft, and Yahoo. No wonder they wanted it this way.

When asked, I tend to advise people using OAuth 1.0 to just keep using it.

Oh well.

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Thursday, June 21, 2012 6:47 AM
To: Hannes Tschofenig
Cc: rui wang; Yuchen Zhou; Shuo Chen (MSR); Derek Atkins; [email-masked]
Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section

Hi Hannes,

So my recommendation is that without extensions to OAuth like structured tokens (signed_request, id_token) or token introspection endpoints like
Facebook ( https://graph.facebook.com/app?access_token=[The<https://graph.facebook.com/app?access_token=%5bThe> Access Token]), there is no safe way to use an implicit flow for authentication.
A code flow where a native app exchanges code for the access token and then passes the access token back to it's server is also vulnerable (lots of this in circulation I understand)

John B.

Hi John,

Ciao
Hannes

John B.

John

-- Dick

John B.

Hi OAuth group,

Derek's suggestion:
====   ===  ===  ===

Thank you.
-Shuo

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, June 18, 2012 11:25 AM
To: Shuo Chen (MSR)
Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek
Atkins; Dick Hardt

Hi,

"Shuo Chen (MSR)" <[email-masked]<mailto:[email-masked]>> writes:

Our suggested text:

Could you please send this to the [email-masked]<mailto:[email-masked]> mailing list?

Thanks a lot.

-Shuo

-derek

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, June 15, 2012 11:36 AM
To: rui wang
Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen Zhou;
Derek Atkins

Hi Rui,

Ciao

Hannes

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Antonio Sanso <[email-masked]>
Date: Thu, 21 Jun 2012 18:04:35 +0100

Hi Eran,

as a potential user of the specification this is bit sad as well to hear.
If you really think this, being on of the editors, you might take a stab and trying to improve it (but I guess it is too late ....)

Regards

Antonio

On Jun 21, 2012, at 4:17 PM, Eran Hammer wrote:

Oh well.

EH

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Thursday, June 21, 2012 6:47 AM
To: Hannes Tschofenig
Cc: rui wang; Yuchen Zhou; Shuo Chen (MSR); Derek Atkins; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section

Hi Hannes,

John B.

Hi John,

Ciao
Hannes

John B.

John

-- Dick

John B.

Hi OAuth group,

Derek’s suggestion:
====   ===  ===  ===

Thank you.
-Shuo

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, June 18, 2012 11:25 AM
To: Shuo Chen (MSR)
Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek
Atkins; Dick Hardt

Hi,

Our suggested text:

Thanks a lot.

-Shuo

-derek

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, June 15, 2012 11:36 AM
To: rui wang
Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen Zhou;
Derek Atkins

Hi Rui,

Ciao

Hannes

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 23 Jun 2012 20:24:06 +0200

Hi John,

I fully agree with your assessment. This attack utilizes the fact that 
some clients rely on the result of a resource server request to login an 
user. It is not an attack on the OAuth protocol. And even if a similar 
attack on authorization codes will happen to fail for confidential 
clients does not mean OAuth is supposed to solve this problem.

We nevertheless should mention it in the security considerations 
section. To make things simple, I suggest to describe and ban this 
anti-pattern _in general_ in the security consideration section (similar 
to Shuo's initial proposal but more generalized). Additionally, the text 
should recommend to use an appropriate technique for id providing such 
as OpenID or SAML.

We also could add a detailed analaysis to the security document.

best regards,
Torsten.

Am 21.06.2012 15:47, schrieb John Bradley:
> If you can do that the token type makes no difference unless we move 
> to a asymmetric holder of key token (different discussion).
>
> The origin of the post was a contention by someone at Facebook that 
> profiling OAuth 2.0 on its own is sufficient to produce an 
> Authentication protocol.
>
> I was trying to point out that OAuth 2 without any extensions, only 
> profiling is difficult to impossible to use for authentication as the 
> attack surface and security considerations are different.
>
> As it turned out Facebook had extended OAuth 2 with signed requests 
> and token introspection techniques to address these issues for 
> themselves.
>
> The problem as it turned out was that individual apps and  app 
> frameworks like the iOS one made some bad mistakes, by not using the 
> perhaps under documented extensions.
>
> So my recommendation is that without extensions to OAuth like 
> structured tokens (signed_request, id_token) or token introspection 
> endpoints like
> Facebook ( https://graph.facebook.com/app?access_token=[The Access 
> Token]), there is no safe way to use an implicit flow for authentication.
> A code flow where a native app exchanges code for the access token and 
> then passes the access token back to it's server is also vulnerable 
> (lots of this in circulation I understand)
>
> The only safe flow (without extensions) is the code flow where the 
> client is confidential and the code is directly exchanged for the 
> access token.
> This also requires the definition of a identity API that is protected 
> by the access token, and out of scope for OAuth.
>
> It may be used by Authentication protocols, but it is up to other 
> specs to define the security considerations for that.
>
> That however doesn't remove the need to mention the token substitution 
> attack that non confidential clients are subject to, do to there being 
> no other mechanism for the client to know who the token was issued to.
>
> John B.
>
>
>
>
>
>> I read through your blog post. I am not sure whether I can entirely 
>> agree with your separation between authentication and authorization. 
>> I believe the core issue here is that
>>
>> * anyone who has the token will get access to whatever the token 
>> entitles him or her to do (unless there are restrictions in the token)
>>
>> * some attributes are different than others. With authentication you 
>> typically associate that the process took place recently (i.e., it is 
>> fresh) while other attributes do not require the user (as resource 
>> owner) to actively participate in the exchange and the same level of 
>> freshness is not implied.  For authentication in a three party 
>> protocol to be useful the three parties have to participate (see 
>> http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt). 
>>
>>
>> I understand that one wants to avoid having tokens passed around from 
>> one application to the other one, as it is happening here.
>>
>> I remember having some of these discussions with Eran a long time 
>> ago. He anticipated that implementers will not put any constraints in 
>> the tokens and hence they will be misused. This serves as an argument 
>> for him to propose the MAC token specification.
>>
>> I proposed text for the security consideration section of the bearer 
>> document a while ago and it even talks about audience restriction as 
>> a recommendation.
>>
>> 1) There is no mandatory token format defined nor do we mandate token 
>> content either. Hence we do not strongly require anything 
>> specifically to be put into the tokens.
>>
>> 2) In the implicit grant flow the client isn't authenticated and 
>> hence what do you want to put into a token as an audience restriction?
>>
>> * Allowing the resource server verify that the received access token 
>> from a specific client has indeed been provided by that client.
>>
>>> It is mostly a warning about the token substitution attack that any 
>>> implicit flow is vulnerable to if used for authentication of the 
>>> presenter.
>>>>> I blogged about this in the hypothetical several months ago. 
>>>>> http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
>>>>>
>>>>> The bottom line is that OAuth has no explicit audience restriction 
>>>>> for tokens,  hence accepting any token outside of the code flow is 
>>>>> subject to attack.
>>>>>
>>>>> In general it is not a issue for authorization,  it is however a 
>>>>> big issue then there is a presumption that the presenter of a 
>>>>> token that grants a client access to resource x is the "resource 
>>>>> owner" of resource x, when it is possible that the presenter is 
>>>>> any client who has ever had a access token for resource x.
>>>>>
>>>>> We might want to include the why it is insecure in the security 
>>>>> consideration,  otherwise people reading the below will likely 
>>>>> ignore the advice as it seems on the surface a touch extreme.
>>>>>
>>>>> There are certainly OAuth flows that allow you to do 
>>>>> authentication safely,  just not all of them without additional 
>>>>> precautions.
>>>>>
>>>>> That is why openID Connect has a audience restricted id_token 
>>>>> similar to Facebook's signed request to allow the implicit flows 
>>>>> to be safely used for authentication.
>>>>>
>>>>> John B.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> This is regarding the recent discussion about an implementation 
>>>>>> issue of some cloud services using OAuth for authentication.
>>>>>> Derek Atkins and Dick Hardt suggested the possibility to discuss 
>>>>>> with the group a paragraph to add to the security considerations 
>>>>>> section.
>>>>>>
>>>>>> Derek's suggestion:
>>>>>> ====   ===  ===  ===
>>>>>>>> the official Windows 8 App Store. We actually sampled only a 
>>>>>>>> small portion of the available apps, but believe this is a 
>>>>>>>> vulnerability pattern.
>>>>>>>>
>>>>>> [email-masked] <mailto:[email-masked]>
>>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Sat, 23 Jun 2012 14:54:43 -0400

Yes it is probably best to keep it short in the main spec, but go into more detail in the security document.

OAuth is fine as it is.  If you use OAuth as part of another protocol that protocol should be taking responsibility for it's own security considerations and not assuming that OAuth will cover everything you are doing.

Like it or not once you do federated authentication with OAuth you have created a different protocol that needs different security considerations.

We all sort of know that, the problem is that some people confuse authentication and authorization as the same thing, so it is worth point ing out.

John B.

On 2012-06-23, at 2:24 PM, Torsten Lodderstedt wrote:

> Hi John,
> 
> I fully agree with your assessment. This attack utilizes the fact that some clients rely on the result of a resource server request to login an user. It is not an attack on the OAuth protocol. And even if a similar attack on authorization codes will happen to fail for confidential clients does not mean OAuth is supposed to solve this problem.
> 
> We nevertheless should mention it in the security considerations section. To make things simple, I suggest to describe and ban this anti-pattern _in general_ in the security consideration section (similar to Shuo's initial proposal but more generalized). Additionally, the text should recommend to use an appropriate technique for id providing such as OpenID or SAML.
>

---

From: Dick Hardt <[email-masked]>
Date: Sat, 23 Jun 2012 20:14:50 -0700

Would someone enlighten me on why the implicit flow is needed? Is it the extra round trip? If so, I think that would be useful to call out both the advantages and disadvantages in the spec. (I did not realize this flow was in OAuth -- it was not in WRAP because of the security issue)

-- Dick

---

From: Eran Hammer <[email-masked]>
Date: Sun, 24 Jun 2012 07:19:22 +0000

You must be joking. Have you ever read the spec?

It has been there from draft -00:

http://tools.ietf.org/html/draft-ietf-oauth-v2-00#section-3.5.1

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Saturday, June 23, 2012 8:15 PM
To: John Bradley
Cc: rui wang; Yuchen Zhou; Shuo Chen (MSR); Derek Atkins; [email-masked]
Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section

-- Dick

John B.

Hi John,

best regards,
Torsten.

John B.

Hi John,

Ciao
Hannes

John B.

John

-- Dick

John B.

Hi OAuth group,

Derek's suggestion:
====   ===  ===  ===

Thank you.
-Shuo

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]]
Sent: Monday, June 18, 2012 11:25 AM
To: Shuo Chen (MSR)
Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek
Atkins; Dick Hardt

Hi,

Our suggested text:

Thanks a lot.

-Shuo

-derek

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Friday, June 15, 2012 11:36 AM
To: rui wang
Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen Zhou;
Derek Atkins

Hi Rui,

Ciao

Hannes

OAuth mailing list

---

From: Dick Hardt <[email-masked]>
Date: Sun, 24 Jun 2012 11:38:41 -0700

No. Not joking.

I thought that concept had been removed from David's draft. Given all the rearrangements you did to the specs, what was in and out was difficult to track. I have been focusing on ensuring the key features that were in WRAP continued to be in the spec.

Clearly the implicit flow can only be used for authorization to the resources and not as an identity mechanism. That should be added in. Would you not agree with me on that and do something as editor to resolve?

-- Dick

On Jun 24, 2012, at 12:19 AM, Eran Hammer wrote:

> I blogged about this in the hypothetical several months ago.http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
>  
> Could you please send this to the [email-masked] list?
>  
> Thanks a lot.
>  
> -Shuo
>  
> -derek
>

---

From: Dick Hardt <[email-masked]>
Date: Sun, 24 Jun 2012 11:41:25 -0700

Speaking from personal experience, OAuth 1.0 sucks to implement -- even with libraries, stupid shit happens and it is a bitch to debug.

Implementing and exploring an API with OAuth 2.0 (well, the good features that came from WRAP) is a dream in comparison.

The implicit flow is evil -- why did you put that in?

-- Dick

On Jun 21, 2012, at 7:17 AM, Eran Hammer wrote:

> * some attributes are different than others. With authentication you typically associate that the process took place recently (i.e., it is fresh) while other attributes do not require the user (as resource owner) to actively participate in the exchange and the same level of freshness is not implied.  For authentication in a three party protocol to be useful the three parties have to participate (seehttp://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt). 
> 
> From: Hannes Tschofenig[mailto:[email-masked]]