[oauth] Re: One-time only token exchange?

[J. Adam Moore]

I agree. "The Request Token has never been exchanged for an Access
Token." isn't explicitly saying one-time only token, but I believe
that is what was intended. Clarifying this line would be sufficient as
would requiring the Service Provider log the User out after any
request token attempt. This forces the User to login to the Service
Provider to start the process of requesting access all over.

On Apr 28, 3:13 pm, Leah Culver  wrote:
> Actually, I think it's a pretty small change to the spec.
>
> In section 6.3.2 Service Provider Grants an Access Token 
> (http://oauth.net/core/1.0/#auth_step3), it says:
>
> The Service Provider MUST ensure that:
>
>    - The request signature has been successfully verified.
>    - The Request Token has never been exchanged for an Access Token.
>    - The Request Token matches the Consumer Key.
>
> ...
> If the request fails verification or is rejected for other reasons, the
> Service Provider SHOULD respond with the appropriate response code as
> defined in HTTP Response Codes (HTTP Response
> Codes)
> .
>
> Perhaps an updated version could say something like (changes in red):
>
>  The Service Provider MUST ensure that:
>
>    - The request signature has been successfully verified.
>    - The Request Token has never been exchanged for an Access Token.
>    - There have been no prior attempts to exchange this Request Token for an
>    Access Token.
>    - The Request Token matches the Consumer Key.
>
> ...
> If the request fails verification or is rejected for other reasons, the
> Service Provider SHOULD invalidate or delete the request token and respond
> with the appropriate response code as defined in HTTP Response Codes (HTTP
> Response Codes) .
>
> On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver  wrote:
>
> > Hmm... I feel like this has been lost in all the hubbub about
> > callbacks.
>
> > I strongly advocate saying something in the spec about making the
> > token exchange (access token endpoint) one-time use only.
>
> > By one-time only, I mean that the first time there is an attempt to
> > exchange a request token for an access token, if the request token has
> > not been authorized, then that request token should be marked as
> > invalid. This will make a session fixation attack nearly impossible
> > without a callback.
>
> > If a service provider allows multiple attempts to exchange the request
> > token a callback is not even necessary for the attack to work! The
> > attacker must only keep trying to exchange the token.
>
> > I know it's up to the service provider to implement one-time only
> > token exchange, but putting it in the documentation (and libraries)
> > will make it much easier for service providers to do the right thing.
>
> > Am I missing the discussion about this? Is it on the wiki and I just
> > can't find it? Or is everyone in agreement that this should be added
> > to the docs?
>
> > Thanks,
> > Leah
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Nat Sakimura]

I think C can send the info that it is A who is requesting the data to S:V.

In the four legged case, the privacy leakage is not a problem, because
the data acquirer must identify himself to the data provider anyways
to obtain permission.

In the tree legged case, it might pose a sort of correlation problem
(privacy), but since S cannot learn too much activity of V at C, it
probably would not be that bad.

And, yes. This is not a technical approach, but legal and social
approach, but is valid IMHO.

=nat

On Wed, Apr 29, 2009 at 11:01 AM, George Fletcher  wrote:
>
> Nat Sakimura wrote:
>> On Tue, Apr 28, 2009 at 11:32 PM, Dossy Shiobara  wrote:
>>
>>> On 4/28/09 8:41 AM, Hubert Le Van Gong wrote:
>>>
 I also saw 2 additional ideas that might help
 (and are not necessarily exclusive with the 2 proposals):

 (3) Make Request tokens one-time only
 (4) Request that the user logs in at the Consumer before the request
 token request

>>> Requiring the user authenticate to the Consumer doesn't prevent the
>>> attack, as the attacker is a legitimate user of Consumer in the attack
>>> scenario.
>>>
>>> What I keep proposing is that the user must authenticate at the
>>> _Provider_ before the request token request.  This would completely
>>> eliminate the attack in the scenario.
>>>
>>
>> Right. I think I have seen something like this on this list recently,
>> but the problem is in this wholesale grant model.
>>
>> Let S:=Service Provider, C:=Consumer, V:=Victim, A:=Attacker,
>> S:V:= User V at S, S:V:Data := Data of user V at S, C:* := any user in C.
>>
>> Then, what OAuth does right now is:
>>
>> [1] Get Permission on (Grant access on S:V:data to C:*)
>>
>> by misguiding the user as (Grant access on S:V:data to C)
>>
>> This is not pretty. It is illegal in many countries (not in U.S. though.)
>>
>> And, what you are proposing is to deny the wild card in [1] above and
>> make it explicit, so that it will be like:
>>
>> [2] Get Permission on (Grant access on S:V:data to C:A)
>>
>> which, I think, is a good idea.
>>
>> Under this scenario, in the last vulnerability that we encountered,
>> the victim will be asked to grant permission to C:A, which, he
>> probably would not.
>>
>>
> But isn't the issue that there is no way for C to communicate A to S in
> a way that V can determine their being "attacked"? One of the principles
> of OAuth has been that it works without identity federation (i.e. that S
> doesn't need to know about V's identity at C nor C know about V's
> identity at S).
>
> It's possible for C to send the requesting user's "identifier" to S (in
> the request_token request) for presentation to the user during
> "authorization" at S, but then there is a leakage of identifiers that
> could lead to privacy/correlation issues. This has been suggested by a
> number of others as a good UX enhancement but not "solving" the
> technical problem. Note that this also presumes that the user must first
> be authenticated to C before starting the OAuth flow.
>
> Thanks,
> George
>> =nat
>>
>>
>>
>>
>>> And yes, making request tokens one-time only is a MUST, IMHO.
>>>
>>> --
>>> Dossy Shiobara              | do...@panoptic.com | http://dossy.org/
>>> Panoptic Computer Network   | http://panoptic.com/
>>>   "He realized the fastest way to change is to laugh at your own
>>>     folly -- then you can let go and quickly move on." (p. 70)
>>>
>>>
>>
>>
>>
>>
>
> >
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[George Fletcher]

Nat Sakimura wrote:
> On Tue, Apr 28, 2009 at 11:32 PM, Dossy Shiobara  wrote:
>   
>> On 4/28/09 8:41 AM, Hubert Le Van Gong wrote:
>> 
>>> I also saw 2 additional ideas that might help
>>> (and are not necessarily exclusive with the 2 proposals):
>>>
>>> (3) Make Request tokens one-time only
>>> (4) Request that the user logs in at the Consumer before the request
>>> token request
>>>   
>> Requiring the user authenticate to the Consumer doesn't prevent the
>> attack, as the attacker is a legitimate user of Consumer in the attack
>> scenario.
>>
>> What I keep proposing is that the user must authenticate at the
>> _Provider_ before the request token request.  This would completely
>> eliminate the attack in the scenario.
>> 
>
> Right. I think I have seen something like this on this list recently,
> but the problem is in this wholesale grant model.
>
> Let S:=Service Provider, C:=Consumer, V:=Victim, A:=Attacker,
> S:V:= User V at S, S:V:Data := Data of user V at S, C:* := any user in C.
>
> Then, what OAuth does right now is:
>
> [1] Get Permission on (Grant access on S:V:data to C:*)
>
> by misguiding the user as (Grant access on S:V:data to C)
>
> This is not pretty. It is illegal in many countries (not in U.S. though.)
>
> And, what you are proposing is to deny the wild card in [1] above and
> make it explicit, so that it will be like:
>
> [2] Get Permission on (Grant access on S:V:data to C:A)
>
> which, I think, is a good idea.
>
> Under this scenario, in the last vulnerability that we encountered,
> the victim will be asked to grant permission to C:A, which, he
> probably would not.
>
>   
But isn't the issue that there is no way for C to communicate A to S in 
a way that V can determine their being "attacked"? One of the principles 
of OAuth has been that it works without identity federation (i.e. that S 
doesn't need to know about V's identity at C nor C know about V's 
identity at S).

It's possible for C to send the requesting user's "identifier" to S (in 
the request_token request) for presentation to the user during 
"authorization" at S, but then there is a leakage of identifiers that 
could lead to privacy/correlation issues. This has been suggested by a 
number of others as a good UX enhancement but not "solving" the 
technical problem. Note that this also presumes that the user must first 
be authenticated to C before starting the OAuth flow.

Thanks,
George
> =nat
>
>
>
>   
>> And yes, making request tokens one-time only is a MUST, IMHO.
>>
>> --
>> Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
>> Panoptic Computer Network   | http://panoptic.com/
>>   "He realized the fastest way to change is to laugh at your own
>> folly -- then you can let go and quickly move on." (p. 70)
>>
>> 
>
>
>
>   

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Nat Sakimura]

Ah, you are conflating two issues.

What Dossy is talking about is the user consent process in the four
legged case,
while what you are talking about is the special case that the two
users needs to
be equal, i.e., three legged case. In three legged case, we clearly need
an authentication at the Consumer based on the SP's user record.
PIN, like you propose, is one way of doing it, and identity federation
is another.

=nat

On Tue, Apr 28, 2009 at 11:40 PM, Peter Keane  wrote:
>
> On Tue, Apr 28, 2009 at 9:32 AM, Dossy Shiobara  wrote:
>>
>> On 4/28/09 8:41 AM, Hubert Le Van Gong wrote:
>>> I also saw 2 additional ideas that might help
>>> (and are not necessarily exclusive with the 2 proposals):
>>>
>>> (3) Make Request tokens one-time only
>>> (4) Request that the user logs in at the Consumer before the request
>>> token request
>>
>> Requiring the user authenticate to the Consumer doesn't prevent the
>> attack, as the attacker is a legitimate user of Consumer in the attack
>> scenario.
>>
>> What I keep proposing is that the user must authenticate at the
>> _Provider_ before the request token request.  This would completely
>> eliminate the attack in the scenario.
>>
>
> Hi Dossy-
>
> But the consumer will still need to communicate back to the SP that it
> has some unique knowledge that it could only have been offered at the
> SP authentication point.  Most proposals do this with the
> "verification token" -- my reasoning leads me to believe that needs to
> be passed "out-of-band."  I'm not sure that moving the authentication
> before request token necessarilly guarantees that.
>
> --peter
>
>> And yes, making request tokens one-time only is a MUST, IMHO.
>>
>> --
>> Dossy Shiobara              | do...@panoptic.com | http://dossy.org/
>> Panoptic Computer Network   | http://panoptic.com/
>>   "He realized the fastest way to change is to laugh at your own
>>     folly -- then you can let go and quickly move on." (p. 70)
>>
>> >
>>
>
> >
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: One-time only token exchange?

[Gilles Devaux]

Limiting the lifetime of the Request Token can also reduce the risk.

In the attack scenario described an abuser must trick a user to click
on the "User Authorization URL" -> this takes some time.
The OAuth flow is somewhat 'instant' (I might miss some scenarios on
mobile devices or devices without a browser).

Of course this does not resolves the underlying problem but might be a
good practice.

Correct me if I am missing something

--Gilles

On Tue, Apr 28, 2009 at 3:45 PM, Josh Roesslein  wrote:
> The SP could optionally add a "buffer" to account for mistypes. Maybe allow
> 2, 3, 4, etc attempts.
> To the consumer it doesn't really matter how many attempts are allowed, they
> can just keep trying until they
> are notified the request token is no longer valid. The spec should outline
> how the client will be notified when a token becomes invalid (status code,
> parameter?).
>
> On Tue, Apr 28, 2009 at 5:21 PM, Breno de Medeiros  wrote:
>>
>> Sometimes users may hit the 'reload' button in the consumer page and that
>> may result in the request token swap being sent twice. So, this implies a
>> requirement on consumers to immediately redirect users to a different page
>> so that the "back" and "reload" buttons won't re-submit the request.
>>
>> In practice, with the new changes, it would be hard for an attacker to get
>> hold of the user's response within a short time frame. Since the request
>> tokens are single time use already, I believe there is no reason for
>> additional spec changes, though probably a discussion on a security
>> considerations section of the spec (which should be moved from appendix to
>> main document) may well be indicated.
>>
>> On Tue, Apr 28, 2009 at 3:13 PM, Leah Culver 
>> wrote:
>>>
>>> Actually, I think it's a pretty small change to the spec.
>>>
>>> In section 6.3.2 Service Provider Grants an Access Token
>>> (http://oauth.net/core/1.0/#auth_step3), it says:
>>>
>>> The Service Provider MUST ensure that:
>>>
>>> The request signature has been successfully verified.
>>> The Request Token has never been exchanged for an Access Token.
>>> The Request Token matches the Consumer Key.
>>>
>>> ...
>>> If the request fails verification or is rejected for other reasons, the
>>> Service Provider SHOULD respond with the appropriate response code as
>>> defined in HTTP Response Codes (HTTP Response Codes).
>>>
>>>
>>> Perhaps an updated version could say something like (changes in red):
>>>
>>> The Service Provider MUST ensure that:
>>>
>>> The request signature has been successfully verified.
>>> The Request Token has never been exchanged for an Access Token.
>>> There have been no prior attempts to exchange this Request Token for an
>>> Access Token.
>>> The Request Token matches the Consumer Key.
>>>
>>> ...
>>> If the request fails verification or is rejected for other reasons, the
>>> Service Provider SHOULD invalidate or delete the request token and respond
>>> with the appropriate response code as defined in HTTP Response Codes (HTTP
>>> Response Codes).
>>>
>>>
>>>
>>>
>>> On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver 
>>> wrote:

 Hmm... I feel like this has been lost in all the hubbub about
 callbacks.

 I strongly advocate saying something in the spec about making the
 token exchange (access token endpoint) one-time use only.

 By one-time only, I mean that the first time there is an attempt to
 exchange a request token for an access token, if the request token has
 not been authorized, then that request token should be marked as
 invalid. This will make a session fixation attack nearly impossible
 without a callback.

 If a service provider allows multiple attempts to exchange the request
 token a callback is not even necessary for the attack to work! The
 attacker must only keep trying to exchange the token.

 I know it's up to the service provider to implement one-time only
 token exchange, but putting it in the documentation (and libraries)
 will make it much easier for service providers to do the right thing.

 Am I missing the discussion about this? Is it on the wiki and I just
 can't find it? Or is everyone in agreement that this should be added
 to the docs?

 Thanks,
 Leah

>>>
>>>
>>>
>>
>>
>>
>> --
>> --Breno
>>
>> +1 (650) 214-1007 desk
>> +1 (408) 212-0135 (Grand Central)
>> MTV-41-3 : 383-A
>> PST (GMT-8) / PDT(GMT-7)
>>
>>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Nat Sakimura]

On Tue, Apr 28, 2009 at 11:32 PM, Dossy Shiobara  wrote:
>
> On 4/28/09 8:41 AM, Hubert Le Van Gong wrote:
>> I also saw 2 additional ideas that might help
>> (and are not necessarily exclusive with the 2 proposals):
>>
>> (3) Make Request tokens one-time only
>> (4) Request that the user logs in at the Consumer before the request
>> token request
>
> Requiring the user authenticate to the Consumer doesn't prevent the
> attack, as the attacker is a legitimate user of Consumer in the attack
> scenario.
>
> What I keep proposing is that the user must authenticate at the
> _Provider_ before the request token request.  This would completely
> eliminate the attack in the scenario.

Right. I think I have seen something like this on this list recently,
but the problem is in this wholesale grant model.

Let S:=Service Provider, C:=Consumer, V:=Victim, A:=Attacker,
S:V:= User V at S, S:V:Data := Data of user V at S, C:* := any user in C.

Then, what OAuth does right now is:

[1] Get Permission on (Grant access on S:V:data to C:*)

by misguiding the user as (Grant access on S:V:data to C)

This is not pretty. It is illegal in many countries (not in U.S. though.)

And, what you are proposing is to deny the wild card in [1] above and
make it explicit, so that it will be like:

[2] Get Permission on (Grant access on S:V:data to C:A)

which, I think, is a good idea.

Under this scenario, in the last vulnerability that we encountered,
the victim will be asked to grant permission to C:A, which, he
probably would not.

=nat



>
> And yes, making request tokens one-time only is a MUST, IMHO.
>
> --
> Dossy Shiobara              | do...@panoptic.com | http://dossy.org/
> Panoptic Computer Network   | http://panoptic.com/
>   "He realized the fastest way to change is to laugh at your own
>     folly -- then you can let go and quickly move on." (p. 70)
>
> >
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: How should I distinguish between approved or denied authorization?

[Mike Williams]

On 29/04/2009, at 6:40 AM, Jesse Myers wrote:

> Upon receiving the callback, the Consumer should try to get an Access
> Token. You should return a 401 to indicate that authorization was
> denied.

Yup, cool.

So, section 6.2.3 of the spec says:

After the User authenticates with the Service Provider and grants  
permission for Consumer access, the Consumer MUST be notified that the  
Request Token has been authorized and ready to be exchanged for an  
Access Token. If the User denies access, the Consumer MAY be notified  
that the Request Token has been revoked.

My reading was that there was some way of representing the revocation  
(lack of authorization) in the callback.  What I'm hearing here,  
though, is that there isn't ... or at least no standard way.

-- 
cheers,
Mike Williams


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Manish Pandit]

On Apr 28, 1:37 pm, Jonathan Sergent  wrote:
> I can't help but think that if our libraries were good enough, people
> wouldn't run into these problems in the first place.  Maybe I'm too
> optimistic, but I would hope that most people using OAuth never have to
> implement the parameter encoding themselves.
>
> There were really specific reasons we did the parameter encoding the way we
> did...

I'd say a complete stack of test cases with coverage should help folks
gain more confidence in sections 5 and 9, which I think seem to be the
hardest ones. I like http://oauth.pbworks.com/TestCases but it could
be evolved more (I'd look into items that I can add there). Overall I
found the beginner's guide and the editor's cut of the spec helping me
a lot. Another factor is familiarity with something like OAuth (like
experience with writing Flickr/Facebook apps using their non-OAuth
API) also helps to hit the ground running, as the core concept is more
or less the same albeit non-standard. From my experience I'd say that
the spec is hard, OAuth as a concept is not, and if a broader range of
test cases would accompany the documentation, that'd make the consumer
+provider implementors' lives a lot easier.

-cheers,
Manish
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: One-time only token exchange?

[Josh Roesslein]

The SP could optionally add a "buffer" to account for mistypes. Maybe allow
2, 3, 4, etc attempts.
To the consumer it doesn't really matter how many attempts are allowed, they
can just keep trying until they
are notified the request token is no longer valid. The spec should outline
how the client will be notified when a token becomes invalid (status code,
parameter?).

On Tue, Apr 28, 2009 at 5:21 PM, Breno de Medeiros  wrote:

> Sometimes users may hit the 'reload' button in the consumer page and that
> may result in the request token swap being sent twice. So, this implies a
> requirement on consumers to immediately redirect users to a different page
> so that the "back" and "reload" buttons won't re-submit the request.
>
> In practice, with the new changes, it would be hard for an attacker to get
> hold of the user's response within a short time frame. Since the request
> tokens are single time use already, I believe there is no reason for
> additional spec changes, though probably a discussion on a security
> considerations section of the spec (which should be moved from appendix to
> main document) may well be indicated.
>
>
> On Tue, Apr 28, 2009 at 3:13 PM, Leah Culver wrote:
>
>> Actually, I think it's a pretty small change to the spec.
>>
>> In section 6.3.2 Service Provider Grants an Access Token (
>> http://oauth.net/core/1.0/#auth_step3), it says:
>>
>> The Service Provider MUST ensure that:
>>
>>- The request signature has been successfully verified.
>>- The Request Token has never been exchanged for an Access Token.
>>- The Request Token matches the Consumer Key.
>>
>> ...
>> If the request fails verification or is rejected for other reasons, the
>> Service Provider SHOULD respond with the appropriate response code as
>> defined in HTTP Response Codes (HTTP Response 
>> Codes)
>> .
>>
>>
>> Perhaps an updated version could say something like (changes in red):
>>
>>  The Service Provider MUST ensure that:
>>
>>- The request signature has been successfully verified.
>>- The Request Token has never been exchanged for an Access Token.
>>- There have been no prior attempts to exchange this Request Token for
>>an Access Token.
>>- The Request Token matches the Consumer Key.
>>
>> ...
>> If the request fails verification or is rejected for other reasons, the
>> Service Provider SHOULD invalidate or delete the request token andrespond 
>> with the appropriate response code as defined in HTTP
>> Response Codes (HTTP Response Codes)
>> .
>>
>>
>>
>>
>>  On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver wrote:
>>
>>>
>>> Hmm... I feel like this has been lost in all the hubbub about
>>> callbacks.
>>>
>>> I strongly advocate saying something in the spec about making the
>>> token exchange (access token endpoint) one-time use only.
>>>
>>> By one-time only, I mean that the first time there is an attempt to
>>> exchange a request token for an access token, if the request token has
>>> not been authorized, then that request token should be marked as
>>> invalid. This will make a session fixation attack nearly impossible
>>> without a callback.
>>>
>>> If a service provider allows multiple attempts to exchange the request
>>> token a callback is not even necessary for the attack to work! The
>>> attacker must only keep trying to exchange the token.
>>>
>>> I know it's up to the service provider to implement one-time only
>>> token exchange, but putting it in the documentation (and libraries)
>>> will make it much easier for service providers to do the right thing.
>>>
>>> Am I missing the discussion about this? Is it on the wiki and I just
>>> can't find it? Or is everyone in agreement that this should be added
>>> to the docs?
>>>
>>> Thanks,
>>> Leah
>>>
>>>
>>
>>
>>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: One-time only token exchange?

[Breno de Medeiros]

Sometimes users may hit the 'reload' button in the consumer page and that
may result in the request token swap being sent twice. So, this implies a
requirement on consumers to immediately redirect users to a different page
so that the "back" and "reload" buttons won't re-submit the request.

In practice, with the new changes, it would be hard for an attacker to get
hold of the user's response within a short time frame. Since the request
tokens are single time use already, I believe there is no reason for
additional spec changes, though probably a discussion on a security
considerations section of the spec (which should be moved from appendix to
main document) may well be indicated.

On Tue, Apr 28, 2009 at 3:13 PM, Leah Culver  wrote:

> Actually, I think it's a pretty small change to the spec.
>
> In section 6.3.2 Service Provider Grants an Access Token (
> http://oauth.net/core/1.0/#auth_step3), it says:
>
> The Service Provider MUST ensure that:
>
>- The request signature has been successfully verified.
>- The Request Token has never been exchanged for an Access Token.
>- The Request Token matches the Consumer Key.
>
> ...
> If the request fails verification or is rejected for other reasons, the
> Service Provider SHOULD respond with the appropriate response code as
> defined in HTTP Response Codes (HTTP Response 
> Codes)
> .
>
>
> Perhaps an updated version could say something like (changes in red):
>
>  The Service Provider MUST ensure that:
>
>- The request signature has been successfully verified.
>- The Request Token has never been exchanged for an Access Token.
>- There have been no prior attempts to exchange this Request Token for
>an Access Token.
>- The Request Token matches the Consumer Key.
>
> ...
> If the request fails verification or is rejected for other reasons, the
> Service Provider SHOULD invalidate or delete the request token and respond
> with the appropriate response code as defined in HTTP Response Codes (HTTP
> Response Codes) .
>
>
>
>
> On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver wrote:
>
>>
>> Hmm... I feel like this has been lost in all the hubbub about
>> callbacks.
>>
>> I strongly advocate saying something in the spec about making the
>> token exchange (access token endpoint) one-time use only.
>>
>> By one-time only, I mean that the first time there is an attempt to
>> exchange a request token for an access token, if the request token has
>> not been authorized, then that request token should be marked as
>> invalid. This will make a session fixation attack nearly impossible
>> without a callback.
>>
>> If a service provider allows multiple attempts to exchange the request
>> token a callback is not even necessary for the attack to work! The
>> attacker must only keep trying to exchange the token.
>>
>> I know it's up to the service provider to implement one-time only
>> token exchange, but putting it in the documentation (and libraries)
>> will make it much easier for service providers to do the right thing.
>>
>> Am I missing the discussion about this? Is it on the wiki and I just
>> can't find it? Or is everyone in agreement that this should be added
>> to the docs?
>>
>> Thanks,
>> Leah
>>
>>
>
> >
>


-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: One-time only token exchange?

[Brian Eaton]

Are you proposing this for the existing protocol, or for a fixed version?

For the existing protocol, seems reasonable.

For the fixed version, we need to take into considerations cases where
a user needs to manually type the callback token and they make a
mistake: http://groups.google.com/group/oauth/msg/4ccea6ccc2ecbd98

Cheers,
Brian

On Tue, Apr 28, 2009 at 3:13 PM, Leah Culver  wrote:
> Actually, I think it's a pretty small change to the spec.
>
> In section 6.3.2 Service Provider Grants an Access Token
> (http://oauth.net/core/1.0/#auth_step3), it says:
>
> The Service Provider MUST ensure that:
>
> The request signature has been successfully verified.
> The Request Token has never been exchanged for an Access Token.
> The Request Token matches the Consumer Key.
>
> ...
> If the request fails verification or is rejected for other reasons, the
> Service Provider SHOULD respond with the appropriate response code as
> defined in HTTP Response Codes (HTTP Response Codes).
>
>
> Perhaps an updated version could say something like (changes in red):
>
> The Service Provider MUST ensure that:
>
> The request signature has been successfully verified.
> The Request Token has never been exchanged for an Access Token.
> There have been no prior attempts to exchange this Request Token for an
> Access Token.
> The Request Token matches the Consumer Key.
>
> ...
> If the request fails verification or is rejected for other reasons, the
> Service Provider SHOULD invalidate or delete the request token and respond
> with the appropriate response code as defined in HTTP Response Codes (HTTP
> Response Codes).
>
>
>
>
> On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver  wrote:
>>
>> Hmm... I feel like this has been lost in all the hubbub about
>> callbacks.
>>
>> I strongly advocate saying something in the spec about making the
>> token exchange (access token endpoint) one-time use only.
>>
>> By one-time only, I mean that the first time there is an attempt to
>> exchange a request token for an access token, if the request token has
>> not been authorized, then that request token should be marked as
>> invalid. This will make a session fixation attack nearly impossible
>> without a callback.
>>
>> If a service provider allows multiple attempts to exchange the request
>> token a callback is not even necessary for the attack to work! The
>> attacker must only keep trying to exchange the token.
>>
>> I know it's up to the service provider to implement one-time only
>> token exchange, but putting it in the documentation (and libraries)
>> will make it much easier for service providers to do the right thing.
>>
>> Am I missing the discussion about this? Is it on the wiki and I just
>> can't find it? Or is everyone in agreement that this should be added
>> to the docs?
>>
>> Thanks,
>> Leah
>>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: One-time only token exchange?

[Leah Culver]

Actually, I think it's a pretty small change to the spec.

In section 6.3.2 Service Provider Grants an Access Token (
http://oauth.net/core/1.0/#auth_step3), it says:

The Service Provider MUST ensure that:

   - The request signature has been successfully verified.
   - The Request Token has never been exchanged for an Access Token.
   - The Request Token matches the Consumer Key.

...
If the request fails verification or is rejected for other reasons, the
Service Provider SHOULD respond with the appropriate response code as
defined in HTTP Response Codes (HTTP Response
Codes)
.


Perhaps an updated version could say something like (changes in red):

 The Service Provider MUST ensure that:

   - The request signature has been successfully verified.
   - The Request Token has never been exchanged for an Access Token.
   - There have been no prior attempts to exchange this Request Token for an
   Access Token.
   - The Request Token matches the Consumer Key.

...
If the request fails verification or is rejected for other reasons, the
Service Provider SHOULD invalidate or delete the request token and respond
with the appropriate response code as defined in HTTP Response Codes (HTTP
Response Codes) .




On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver  wrote:

>
> Hmm... I feel like this has been lost in all the hubbub about
> callbacks.
>
> I strongly advocate saying something in the spec about making the
> token exchange (access token endpoint) one-time use only.
>
> By one-time only, I mean that the first time there is an attempt to
> exchange a request token for an access token, if the request token has
> not been authorized, then that request token should be marked as
> invalid. This will make a session fixation attack nearly impossible
> without a callback.
>
> If a service provider allows multiple attempts to exchange the request
> token a callback is not even necessary for the attack to work! The
> attacker must only keep trying to exchange the token.
>
> I know it's up to the service provider to implement one-time only
> token exchange, but putting it in the documentation (and libraries)
> will make it much easier for service providers to do the right thing.
>
> Am I missing the discussion about this? Is it on the wiki and I just
> can't find it? Or is everyone in agreement that this should be added
> to the docs?
>
> Thanks,
> Leah
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: One-time only token exchange?

[Josh Roesslein]

I agree with you Leah that it should be outlined in the spec that the SP
should limit the number of access token requests
to prevent brute force attacks. This would really make session fixation
impossible w/o a callback.

On Tue, Apr 28, 2009 at 5:02 PM, Leah Culver  wrote:

>
> Hmm... I feel like this has been lost in all the hubbub about
> callbacks.
>
> I strongly advocate saying something in the spec about making the
> token exchange (access token endpoint) one-time use only.
>
> By one-time only, I mean that the first time there is an attempt to
> exchange a request token for an access token, if the request token has
> not been authorized, then that request token should be marked as
> invalid. This will make a session fixation attack nearly impossible
> without a callback.
>
> If a service provider allows multiple attempts to exchange the request
> token a callback is not even necessary for the attack to work! The
> attacker must only keep trying to exchange the token.
>
> I know it's up to the service provider to implement one-time only
> token exchange, but putting it in the documentation (and libraries)
> will make it much easier for service providers to do the right thing.
>
> Am I missing the discussion about this? Is it on the wiki and I just
> can't find it? Or is everyone in agreement that this should be added
> to the docs?
>
> Thanks,
> Leah
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] One-time only token exchange?

[Leah Culver]

Hmm... I feel like this has been lost in all the hubbub about
callbacks.

I strongly advocate saying something in the spec about making the
token exchange (access token endpoint) one-time use only.

By one-time only, I mean that the first time there is an attempt to
exchange a request token for an access token, if the request token has
not been authorized, then that request token should be marked as
invalid. This will make a session fixation attack nearly impossible
without a callback.

If a service provider allows multiple attempts to exchange the request
token a callback is not even necessary for the attack to work! The
attacker must only keep trying to exchange the token.

I know it's up to the service provider to implement one-time only
token exchange, but putting it in the documentation (and libraries)
will make it much easier for service providers to do the right thing.

Am I missing the discussion about this? Is it on the wiki and I just
can't find it? Or is everyone in agreement that this should be added
to the docs?

Thanks,
Leah
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Amusing Flickr Support Message

[Leah Culver]

http://www.flickr.com/help/forum/en-us/96092/

User messaging ftw!

Leah
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[jr conlin]

Agreed.

Granted, I'm starting to think that there ought to be a specification 
for how the libraries are put together, but that's probably beside the 
point. I will note that from the library point of view, you really want 
to minimize the amount of thought that your end user has to give in 
order to use your stuff. Case in point: .Net has the nasty habit of 
returning lower case hex values in the encoded results. If your library 
doesn't return a fully formed result (and instead just returns a 
calculated signature string), you're rolling out the red carpet of 
frustration for whoever picks up your library and tries to use it since 
they now have to replicate how the SBS was generated to give your 
signature.

There are definite, valid reasons for why OAuth is built the way it is. 
It's also really easy for folks here to get lost in the details of OAuth 
and forget that it's just a tiny part of a much larger set of issues for 
whatever developer wants to use it to solve a problem. For folks out 
there building apps and services: Easy trumps detailed.


Jonathan Sergent wrote:
> I can't help but think that if our libraries were good enough, people 
> wouldn't run into these problems in the first place.  Maybe I'm too 
> optimistic, but I would hope that most people using OAuth never have 
> to implement the parameter encoding themselves.
>
> There were really specific reasons we did the parameter encoding the 
> way we did...
>
> On Tue, Apr 28, 2009 at 12:15 PM, John Panzer  > wrote:
>
> IIRC, I believe the signing is a workaround for environments that
> can't or don't want to support SSL.  And SSL is problematic
> primarily for small SPs that can't justify purchase of their own
> certs.  Unfortunately, this puts a burden on clients.
>
> Also, most of these come down to encoding issues, which are just
> always tricky IMHO.  Either you end up breaking immediately
> (because your signature doesn't match) or breaking in edge/subtle
> cases (because your data mostly matches, except when some idiot
> sticks an ampersand in the middle of that one string...).  Not
> sure which is worse in the long term, though obviously the
> break-immediately-with-no-feedback paradigm feels much more
> frustrating.
>
> Perhaps any interop tester service should have a 'forgiving' mode
> that just logs signature validation failures (but lets the code
> proceed), but also displays very explicitly what it thought the
> signature base string was and what it calculated. 
> feedvalidator.org  does something
> similar for RSS and Atom feeds, and it's a fantastic resource for
> experimenting and fixing things.  OAuth is more complicated than
> feeds but it didn't have even that level of testing support.
>
> -John
>
>
> On Mon, Apr 27, 2009 at 11:12 PM, Hans Granqvist
> mailto:h...@granqvist.com>> wrote:
>
>
> OAuth is complex. Witness last weeks crazy rush to fix
> something that
> was visible
> in the protocol all along. But no one saw it ... most likely
> because
> of protocol complexity.
>
> Seeing as Kent's confessions are mostly around signature: it's odd
> that an authorization
> protocol needs to specify signature mechanisms ... at all.
>
> The end result of an OAuth protocol flow is:
> * some state on the provider, and
> * some manifestation of this state on the consumer, who uses
> this to
> authenticate
> the provider when accessing the resource.
>
> An authz protocol should encompass how to clearly describe
> resources,
> operations,
> and parties authorized. To do that you really need no other
> info than URLs and
> operations.
>
> There is no need to bounce this information via the consumer:
> * The consumer performs an operation on a resource, and
> * The provider checks to see whether the consumer is allowed.
>
> The manner in which the provider authenticates the consumer
> should be completely
> independent from the authorization protocol. Forcing any style of
> authentication is
> a bit draconian. (A token is tied to a secret for authentication)
>
> There are also other issues with baking this all into one
> protocol.
> For example, only
> the provider has to be the one issuing and consuming tokens. This
> format is opaque.
> This means I cannot issue my own authorizations -- ahead of
> time if I
> wants -- nor
> can I move them around providers...
>
> For some reason OAuth came out as a bit of a REST
> anti-pattern. Access
> to resources
> now are shrouded inside an odd mix of additional protocol
> flows and
> signature mechanisms.

[oauth] Re: CANCELLED: San Francisco meetup this Tuesday 5pm

[Allen Tom]

Actually, I was going to go too, but I didn't RSVP.

Allen


Gilles Devaux wrote:
> Do you plan to postpone it?
>
> I did not realize I had to respond and was going to show up.
>
> --Gilles
>
> On Mon, Apr 27, 2009 at 11:32 PM, Chris Messina  
> wrote:
>   
>> :(
>> Seems like 5 people would be a good-sized group to actually get some real
>> work done.
>> Of course it's up to you and then folks who had signed up to attend, but I
>> wouldn't be discouraged by what might appear to be a relatively small sized
>> number of attendees.
>> Chris
>>
>> On Mon, Apr 27, 2009 at 2:04 PM, Leah Culver  wrote:
>> 
>>> Since less than 5 people have responded, I'm cancelling this meeting.
>>>
>>> Sorry about the short notice,
>>> Leah
>>>
>>> On Fri, Apr 24, 2009 at 2:42 PM, Leah Culver 
>>> wrote:
>>>   
 Hi all,

 My eyes hurt from trying to read long email threads. There's quite a
 few good ideas for helping protect against the current security issue
 and it will be helpful to get together to discuss. Here's the details:

 OAuth Meetup
 Tuesday, Apr 28th at 5pm
 Six Apart
 548 4th Street

 I'll try to get the conference call stuff working too - more about
 this later.

 Sorry for the short notice! I'll try to summarize the meeting and get
 the notes back in the mailing list or wiki.

 Leah
 
>>>   
>>
>> --
>> Chris Messina
>> Open Web Advocate
>>
>> factoryjoe.com // diso-project.org // openid.net // vidoop.com
>> This email is:   [ ] bloggable[X] ask first   [ ] private
>>
>> 
>
> >
>   


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Peter Keane]

On Tue, Apr 28, 2009 at 8:46 AM, Blaine Cook  wrote:
>
> On Tue, Apr 28, 2009 at 2:27 PM, Peter Keane  wrote:
>> Yes, that's right.  What it does (for the sake of the SP) is assert
>> "this user on the consumer is indeed the same user that authenticated
>> at the SP."  Authorization always requires authentication (system
>> needs to know "who" it is authorizing).
>
> For OAuth, this relationship is simple. The SP authenticates the user,
> but authorizes the consumer-plus-request-token pair. The SP *does not*
> authorize an authenticated user at the consumer end. That relationship
> is up to the consumer to decide.
>
> Put another way, if TweetCash had been given authorization by many
> users to access Twitter accounts, they (TweetCash) could impersonate
> any one of those accounts in any way they choose. However, it's a
> trust relationship. If TweetCash were to abuse that trust, then
> Twitter has the ability to disable their access wholesale (via the
> consumer key) or the users have the ability to revoke access on a
> case-by-case bases. At no point can Twitter *guarantee* that TweetCash
> isn't abusing the trust, but it's probably impossible to do so without
> creating an unusable technology, particularly for the sorts of
> problems we're trying to solve.
>

Sorry -- I did not completely get what you were saying at first.  Yes,
the SP definitely places a lot of trust in the consumer to "do the
right thing" regarding the authorizations it has granted that
consumer, and the ability to disable that access wholesale is a great
feature of OAuth.  I certainly did not mean to suggest that the SP
should be able to guarantee that the consumer is not abusing that
trust (indeed the SP-consumer trust is a core basis upon which OAuth
is based).  My goal is to make sure we have a spec that,  given a
"good" consumer and a "good" SP, will not allow a bad user to
victimize a good user.

--peter

> The exploit that we're dealing with is that the consumer has no way to
> ensure that the SP has authorized access to the intended party. The
> verification token *does* ensure this, since it guarantees that the
> person that clicks "Authorize {consumer}" is the same one that is
> interacting with the consumer, and that's all we're trying to solve.
> OAuth does not, and should not, attempt to authenticate identity
> across sites.
>
> b.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: How should I distinguish between approved or denied authorization?

[Jesse Myers]

Upon receiving the callback, the Consumer should try to get an Access
Token. You should return a 401 to indicate that authorization was
denied.


On Tue, Apr 28, 2009 at 1:30 PM, Mike Williams  wrote:
>
> On 28/04/2009, at 9:45 PM, J. Adam Moore wrote:
>
>>> How does one typically indicate, in the authorization callback,
>>> whether the Request Token was approved or denied?
>
>> I think you send a 401 error...
>
>
> Er, sorry, perhaps my question was unclear.  Authorization of a
> request token is an exchange between User and Service Provider.  After
> a rejected authorization, I want to notify the Consumer that it was
> rejected, and the spec suggests that it "MAY" be done by invoking the
> callback.  What I want to know is, how should I let the Consumer know
> the token was rejected vs approved?
>
> --
> cheers,
> Mike Williams
>
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Apps using OAUTH and REST API in orkut environment

[Chris Messina]

This sounds like an issue specific to Orkut's implementation, in which case
you'll want to see help in the Orkut developer forums:
http://groups.google.com/group/opensocial-orkut

Chris

On Tue, Apr 28, 2009 at 4:00 AM, suhasini wrote:

>
> I want to implement REST concept in my application development in
> orkut environment. Is there any apps that already implemented REST and
> OAUTH?
>
>
> If yes, How can i do that? I already tried with PHP libraries but no
> use. It's throwing some errors(fatal errors).
>
> >
>


-- 
Chris Messina
Open Web Advocate

factoryjoe.com // diso-project.org // openid.net // vidoop.com
This email is:   [ ] bloggable[X] ask first   [ ] private

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Jonathan Sergent]

I can't help but think that if our libraries were good enough, people
wouldn't run into these problems in the first place.  Maybe I'm too
optimistic, but I would hope that most people using OAuth never have to
implement the parameter encoding themselves.

There were really specific reasons we did the parameter encoding the way we
did...

On Tue, Apr 28, 2009 at 12:15 PM, John Panzer  wrote:

> IIRC, I believe the signing is a workaround for environments that can't or
> don't want to support SSL.  And SSL is problematic primarily for small SPs
> that can't justify purchase of their own certs.  Unfortunately, this puts a
> burden on clients.
>
> Also, most of these come down to encoding issues, which are just always
> tricky IMHO.  Either you end up breaking immediately (because your signature
> doesn't match) or breaking in edge/subtle cases (because your data mostly
> matches, except when some idiot sticks an ampersand in the middle of that
> one string...).  Not sure which is worse in the long term, though obviously
> the break-immediately-with-no-feedback paradigm feels much more frustrating.
>
> Perhaps any interop tester service should have a 'forgiving' mode that just
> logs signature validation failures (but lets the code proceed), but also
> displays very explicitly what it thought the signature base string was and
> what it calculated.  feedvalidator.org does something similar for RSS and
> Atom feeds, and it's a fantastic resource for experimenting and fixing
> things.  OAuth is more complicated than feeds but it didn't have even that
> level of testing support.
>
> -John
>
>
> On Mon, Apr 27, 2009 at 11:12 PM, Hans Granqvist wrote:
>
>>
>> OAuth is complex. Witness last weeks crazy rush to fix something that
>> was visible
>> in the protocol all along. But no one saw it ... most likely because
>> of protocol complexity.
>>
>> Seeing as Kent's confessions are mostly around signature: it's odd
>> that an authorization
>> protocol needs to specify signature mechanisms ... at all.
>>
>> The end result of an OAuth protocol flow is:
>> * some state on the provider, and
>> * some manifestation of this state on the consumer, who uses this to
>> authenticate
>> the provider when accessing the resource.
>>
>> An authz protocol should encompass how to clearly describe resources,
>> operations,
>> and parties authorized. To do that you really need no other info than URLs
>> and
>> operations.
>>
>> There is no need to bounce this information via the consumer:
>> * The consumer performs an operation on a resource, and
>> * The provider checks to see whether the consumer is allowed.
>>
>> The manner in which the provider authenticates the consumer should be
>> completely
>> independent from the authorization protocol. Forcing any style of
>> authentication is
>> a bit draconian. (A token is tied to a secret for authentication)
>>
>> There are also other issues with baking this all into one protocol.
>> For example, only
>> the provider has to be the one issuing and consuming tokens. This
>> format is opaque.
>> This means I cannot issue my own authorizations -- ahead of time if I
>> wants -- nor
>> can I move them around providers...
>>
>> For some reason OAuth came out as a bit of a REST anti-pattern. Access
>> to resources
>> now are shrouded inside an odd mix of additional protocol flows and
>> signature mechanisms.
>>
>> With non-easily addressable consumers (like desktop apps) you run into
>> the "turtles all
>> the way down" problem when introducing authentication inside an
>> authorization protocol:
>> you can issue secrets and tokens to an app, or try one of the n-legged
>> approaches, but
>> they fail as you never can be sure who or what you're ultimately
>> authenticating.
>>
>> I'm probably rambling a bit, just some thoughts,
>> Hans
>>
>>
>> On Mon, Apr 27, 2009 at 10:42 PM, Chris Messina 
>> wrote:
>> > Is OAuth this hard for everyone else?
>> > http://kentbrewster.com/oauth-confessions/
>> > *Sniff*.
>> > Chris
>> >
>> >
>> > --
>> > Chris Messina
>> > Open Web Advocate
>> >
>> > factoryjoe.com // diso-project.org // openid.net // vidoop.com
>> > This email is:   [ ] bloggable[X] ask first   [ ] private
>> >
>> > >
>> >
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: How should I distinguish between approved or denied authorization?

[Mike Williams]

On 28/04/2009, at 9:45 PM, J. Adam Moore wrote:

>> How does one typically indicate, in the authorization callback,
>> whether the Request Token was approved or denied?

> I think you send a 401 error...


Er, sorry, perhaps my question was unclear.  Authorization of a  
request token is an exchange between User and Service Provider.  After  
a rejected authorization, I want to notify the Consumer that it was  
rejected, and the spec suggests that it "MAY" be done by invoking the  
callback.  What I want to know is, how should I let the Consumer know  
the token was rejected vs approved?

-- 
cheers,
Mike Williams





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Peter Keane]

On Tue, Apr 28, 2009 at 1:00 PM, John Kemp  wrote:
>
> Hi Brian,
>
> On Apr 28, 2009, at 1:36 PM, Brian Eaton wrote:
>
>>
>> On Mon, Apr 27, 2009 at 8:25 PM, pkeane  wrote:
>>> I'm happy with  OAuth for the typical sorts of social networking,
>>> photo-sharing, etc. use cases, and I use it for that.  But I'd very
>>> much like to be able recommend it for more highly secure scenarios
>>> here on campus (I work in higher ed) that might involve confidential
>>> records.  For OAuth to replace or be used in conjunction with the
>>> cuurent campus SSO and federated systems like Shibboleth, we would
>>> really need that extra level of verifiable security.
>>
>> Hi Peter -
>>
>> SSO systems such as SAML/OpenID/others all use the equivalent of a
>> callback token to bind the session at the identity provider to the
>> relying party.  The fix to the OAuth protocol is to make it look just
>> like the "campus SSO and federated systems" that you mention above:
>>
>> OpenID: signature on authentication response.
>> SAML POST profile: signature on authentication response.
>> SAML artifact profile: random single-use artifact value.
>>
>> All of those systems pass a value that is unpredictable to the
>> attacker to a trusted location at the consumer site.  None of those
>> systems force the user to do anything as obnoxious as manually type a
>> pin at the consumer site.
>
> All of these protocols are for Web-browser based SSO, and establish
> the trust between the consumer and SP (using the OAuth terminology) by
> relying on Web-browser technologies (ie. an HTTP redirect sent through
> the user's browser assures that the browser is the same one at SP as
> it was at consumer).
>

Hi John-

On our campus this is indeeed true -- SSO relies on web browser
technologies.  In cases when we need to authorize third party services
(we currently have Blackboard as a "consumer" for our digital asset
management "service provider") we have implemented something similar
to OAuth.  The problems currently under discussion are not an issue,
since we DO have consumer authentication (users must sign into
Blackboard) and the we use the same AuthN mechanism in both places
(our SSO).

> I do not think the assumptions of OAuth are the same as for those
> protocols. At least not currently. And I would be wary of going that
> way without more thought.
>
>> If you think manually typing a pin increases security, you should
>> explain the attack you're trying to prevent.  Why should OAuth have
>> such a requirement if SAML and OpenID don't?
>
>
> I think the security requirement is that you ensure that the entity
> making a request to the consumer to start the OAuth process is the
> same entity which is authenticated to the SP. Are you arguing that the
> callback URL suffices in that regard?
>

I agree that ensuring that u...@consumer (either at the start OR when requesting
access token) == u...@sp is the key.  The main reasons I have for
pushing this are:

1. it guards against scenarios we do not yet envision (like
"whitelisting good guys" rather than trying to "blacklist bad guys")
2. it offers the chance to keep the protocol very simple (perhaps even
make some things simpler), although at the expense of a slightly more
cumbersome user experience.

--peter


> Cheers,
>
> - johnk
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[pkeane]

On Apr 28, 1:25 pm, Josh Roesslein  wrote:
> On Tue, Apr 28, 2009 at 1:12 PM, Brian Eaton  wrote:
>
> > For apps that can't receive callback URLs, you need a PIN.
>
> Yes we will need to manually pass the callback secrete to the application
> (aka the pin).
>
> I think the solution of signed callbacks w/ a callback secrete adequately
> closes the security hole
> while not drastically changing the protocol or the user experience. In fact
> the user won't even be aware of any of these changes
> unless the application required the transfer of the pin (the callback
> secrete). Before all they had to do is notify the application.
>
> This solution is quick to implement and can be deployed in a timely matter
> to close this session fixation flaw.
> We can continue working on a future spec that can change the flow some more
> or add additional security, but for now we should focus on the current
> security threat.
> Tackle one issue at a time.

I'd agree on all of this -- it fixes the session fixation flaw and it
can be implemented more easily than other solutions.  My advocating
possible of a PIN or other human-enabled-state mechanism can be worked
on as a later spec or an extension to this one if there is sufficient
interest.  It needn't hold up this process if folks do not want to go
that route.

--peter


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[John Panzer]

IIRC, I believe the signing is a workaround for environments that can't or
don't want to support SSL.  And SSL is problematic primarily for small SPs
that can't justify purchase of their own certs.  Unfortunately, this puts a
burden on clients.

Also, most of these come down to encoding issues, which are just always
tricky IMHO.  Either you end up breaking immediately (because your signature
doesn't match) or breaking in edge/subtle cases (because your data mostly
matches, except when some idiot sticks an ampersand in the middle of that
one string...).  Not sure which is worse in the long term, though obviously
the break-immediately-with-no-feedback paradigm feels much more frustrating.

Perhaps any interop tester service should have a 'forgiving' mode that just
logs signature validation failures (but lets the code proceed), but also
displays very explicitly what it thought the signature base string was and
what it calculated.  feedvalidator.org does something similar for RSS and
Atom feeds, and it's a fantastic resource for experimenting and fixing
things.  OAuth is more complicated than feeds but it didn't have even that
level of testing support.

-John

On Mon, Apr 27, 2009 at 11:12 PM, Hans Granqvist  wrote:

>
> OAuth is complex. Witness last weeks crazy rush to fix something that
> was visible
> in the protocol all along. But no one saw it ... most likely because
> of protocol complexity.
>
> Seeing as Kent's confessions are mostly around signature: it's odd
> that an authorization
> protocol needs to specify signature mechanisms ... at all.
>
> The end result of an OAuth protocol flow is:
> * some state on the provider, and
> * some manifestation of this state on the consumer, who uses this to
> authenticate
> the provider when accessing the resource.
>
> An authz protocol should encompass how to clearly describe resources,
> operations,
> and parties authorized. To do that you really need no other info than URLs
> and
> operations.
>
> There is no need to bounce this information via the consumer:
> * The consumer performs an operation on a resource, and
> * The provider checks to see whether the consumer is allowed.
>
> The manner in which the provider authenticates the consumer should be
> completely
> independent from the authorization protocol. Forcing any style of
> authentication is
> a bit draconian. (A token is tied to a secret for authentication)
>
> There are also other issues with baking this all into one protocol.
> For example, only
> the provider has to be the one issuing and consuming tokens. This
> format is opaque.
> This means I cannot issue my own authorizations -- ahead of time if I
> wants -- nor
> can I move them around providers...
>
> For some reason OAuth came out as a bit of a REST anti-pattern. Access
> to resources
> now are shrouded inside an odd mix of additional protocol flows and
> signature mechanisms.
>
> With non-easily addressable consumers (like desktop apps) you run into
> the "turtles all
> the way down" problem when introducing authentication inside an
> authorization protocol:
> you can issue secrets and tokens to an app, or try one of the n-legged
> approaches, but
> they fail as you never can be sure who or what you're ultimately
> authenticating.
>
> I'm probably rambling a bit, just some thoughts,
> Hans
>
>
> On Mon, Apr 27, 2009 at 10:42 PM, Chris Messina 
> wrote:
> > Is OAuth this hard for everyone else?
> > http://kentbrewster.com/oauth-confessions/
> > *Sniff*.
> > Chris
> >
> >
> > --
> > Chris Messina
> > Open Web Advocate
> >
> > factoryjoe.com // diso-project.org // openid.net // vidoop.com
> > This email is:   [ ] bloggable[X] ask first   [ ] private
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Josh Roesslein]

On Tue, Apr 28, 2009 at 1:12 PM, Brian Eaton  wrote:

>
> For apps that can't receive callback URLs, you need a PIN.
>

Yes we will need to manually pass the callback secrete to the application
(aka the pin).

I think the solution of signed callbacks w/ a callback secrete adequately
closes the security hole
while not drastically changing the protocol or the user experience. In fact
the user won't even be aware of any of these changes
unless the application required the transfer of the pin (the callback
secrete). Before all they had to do is notify the application.

This solution is quick to implement and can be deployed in a timely matter
to close this session fixation flaw.
We can continue working on a future spec that can change the flow some more
or add additional security, but for now we should focus on the current
security threat.
Tackle one issue at a time.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Brian Eaton]

On Tue, Apr 28, 2009 at 11:00 AM, John Kemp  wrote:
> All of these protocols are for Web-browser based SSO, and establish
> the trust between the consumer and SP (using the OAuth terminology) by
> relying on Web-browser technologies (ie. an HTTP redirect sent through
> the user's browser assures that the browser is the same one at SP as
> it was at consumer).
>
> I do not think the assumptions of OAuth are the same as for those
> protocols. At least not currently. And I would be wary of going that
> way without more thought.

Please give it the thought, then.  This is key.
https://oauth.pbworks.com/OAuth-Session-Fixation-Advisory has a
checklist that may be useful to validate your ideas.

> I think the security requirement is that you ensure that the entity
> making a request to the consumer to start the OAuth process is the
> same entity which is authenticated to the SP. Are you arguing that the
> callback URL suffices in that regard?

It's sufficient for applications that can receive callback URLs.  Both
of the proposals at
https://oauth.pbworks.com/OAuth-Session-Fixation-Advisory rely on the
callback URL.

For apps that can't receive callback URLs, you need a PIN.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Peter Keane]

On Tue, Apr 28, 2009 at 12:36 PM, Brian Eaton  wrote:
>
> On Mon, Apr 27, 2009 at 8:25 PM, pkeane  wrote:
>> I'm happy with  OAuth for the typical sorts of social networking,
>> photo-sharing, etc. use cases, and I use it for that.  But I'd very
>> much like to be able recommend it for more highly secure scenarios
>> here on campus (I work in higher ed) that might involve confidential
>> records.  For OAuth to replace or be used in conjunction with the
>> cuurent campus SSO and federated systems like Shibboleth, we would
>> really need that extra level of verifiable security.
>
> Hi Peter -
>
> SSO systems such as SAML/OpenID/others all use the equivalent of a
> callback token to bind the session at the identity provider to the
> relying party.  The fix to the OAuth protocol is to make it look just
> like the "campus SSO and federated systems" that you mention above:

Hi Brian-

It's true that a "runtime" connection is made in a SSO systems, but as
far as I know, it is *always* based on an out-of-band arrangement
(such as a public key exchange, or server-provider regstration) or (in
the case of Shib) built directly on top of system(s) that have trusted
authentication mechanisms in place which are themselves based on
out-of-band arrangements.

>
> OpenID: signature on authentication response.
> SAML POST profile: signature on authentication response.
> SAML artifact profile: random single-use artifact value.

OpenID is simply built on the trust of the identity provider's
authentication -- to the extent that is acceptible, the OpenID is
acceptable.  But that is the equivalent of two-legged OAuth in that it
is two "services" that have an agreement. That last link in OAuth
(connecting u...@consumer to u...@sp) is NOT based on out-of-band
arrangement.  It appears to be, but it is not (since the consumer-SP
agreement is site-wide *not* user-specific).

>
> All of those systems pass a value that is unpredictable to the
> attacker to a trusted location at the consumer site.  None of those
> systems force the user to do anything as obnoxious as manually type a
> pin at the consumer site.

Sure they do.  I cannot use my LiveJournal OpenID unless I have gone
through the registration process on LiveJournal's site.  Once that is
completed, I can use that OpenID with services that accept it.
Likewise, once a user has gone through the OAuth handshake and gotten
the access token for the consumer, the consumer can store it and use
it anytime it wishes (for the user -- this assumes that the consumer
has a method to authenticate the user to its own satisfaction).

>
> If you think manually typing a pin increases security, you should
> explain the attack you're trying to prevent.  Why should OAuth have
> such a requirement if SAML and OpenID don't?
>

I am not trying to thwart a specific attack -- I have no idea how one
might exploit the existing hole.  I'm simply trying to determine a way
to "verify" that u...@consumer IS u...@sp.  If that hole is closed,
the protocol is as strong as the existing protocols it rests atop of.


> So far the only concrete "explanation" I've seen is that ATMs require
> PINs, so OAuth should require a PIN.  You're confusing two-factor
> authentication with federated authentication protocols.

I have no stake in a PIN as the solution.  My mentioning banks was to
try and explain why something as simple as a 4-letter PIN can offer a
great deal of security. In fact I don't care at all what the solution
is.  Any mechanism that verifies u...@consumer == u...@sp is a-ok.

Unfortunately, three-legged OAuth is actuallly an
authentication/authorization protocol masquerading as an authorization
protocol, but it is not actually doing authentication at the consumer
which it needs to (authentication meaning proving u...@consumer ==
u...@sp).

I'm not sure this should all boil down to one opinion over another --
I'd prefer that we could agree on what the goal is and if it is being
adequately addressed.  I think we can all agree (since this is in
essence what Eran's blog post suggested) that we need to prove
u...@consumer == u...@sp.

If everyone agrees the callback_verification is proof enough, I am OK
w/ that -- that's a level of certainty that the community as a whole
might be able to accept.

--peter

 Two factor
> authentication is great, and it's fine for consumers and service
> providers to implement that.  No change to the OAuth protocol is
> necessary to support it.  Again, this is exactly analogous to the
> situation in OpenID and SAML.  It's completely reasonable for a SAML
> IdP to implement two-factor authentication for their users, and doing
> so doesn't impact the SAML protocol one whit.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, vi

[oauth] Re: Moving forward

[John Kemp]

Hi Brian,

On Apr 28, 2009, at 1:36 PM, Brian Eaton wrote:

>
> On Mon, Apr 27, 2009 at 8:25 PM, pkeane  wrote:
>> I'm happy with  OAuth for the typical sorts of social networking,
>> photo-sharing, etc. use cases, and I use it for that.  But I'd very
>> much like to be able recommend it for more highly secure scenarios
>> here on campus (I work in higher ed) that might involve confidential
>> records.  For OAuth to replace or be used in conjunction with the
>> cuurent campus SSO and federated systems like Shibboleth, we would
>> really need that extra level of verifiable security.
>
> Hi Peter -
>
> SSO systems such as SAML/OpenID/others all use the equivalent of a
> callback token to bind the session at the identity provider to the
> relying party.  The fix to the OAuth protocol is to make it look just
> like the "campus SSO and federated systems" that you mention above:
>
> OpenID: signature on authentication response.
> SAML POST profile: signature on authentication response.
> SAML artifact profile: random single-use artifact value.
>
> All of those systems pass a value that is unpredictable to the
> attacker to a trusted location at the consumer site.  None of those
> systems force the user to do anything as obnoxious as manually type a
> pin at the consumer site.

All of these protocols are for Web-browser based SSO, and establish  
the trust between the consumer and SP (using the OAuth terminology) by  
relying on Web-browser technologies (ie. an HTTP redirect sent through  
the user's browser assures that the browser is the same one at SP as  
it was at consumer).

I do not think the assumptions of OAuth are the same as for those  
protocols. At least not currently. And I would be wary of going that  
way without more thought.

> If you think manually typing a pin increases security, you should
> explain the attack you're trying to prevent.  Why should OAuth have
> such a requirement if SAML and OpenID don't?


I think the security requirement is that you ensure that the entity  
making a request to the consumer to start the OAuth process is the  
same entity which is authenticated to the SP. Are you arguing that the  
callback URL suffices in that regard?

Cheers,

- johnk


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Dossy Shiobara]

On 4/28/09 1:40 PM, Brian Eaton wrote:
> It's fine to limit the number of unsuccessful exchange attempts, but a
> limit of one is too low.  Five attempts is more reasonable.
 >
> Limiting the number of successful exchange attempts to one makes sense.

This makes sense.  Perhaps the spec should be organized in this way:



The SP MUST invalidate the request token after a successful exchange 
attempt.

The SP MUST invalidate the request token after a certain number of 
unsuccessful exchange attempts.  The number is RECOMMENDED to be between 
1 and 5, as appropriate.



I don't see why a SP should be prohibited from expiring a token after 
one unsuccessful exchange attempt.  IMHO, the number should be chosen 
based on the SP's desired security level.

-- 
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
   "He realized the fastest way to change is to laugh at your own
 folly -- then you can let go and quickly move on." (p. 70)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Brian Eaton]

On Tue, Apr 28, 2009 at 7:32 AM, Dossy Shiobara  wrote:
> And yes, making request tokens one-time only is a MUST, IMHO.

This is a terrible idea for consumers that can't receive callback
URLs.  For those consumers users are going to have to manually type in
a callback token.  There will be typos.  Under the "single use request
token" proposal, those users will then have to go back through the
entire OAuth approval process to get another callback token.

It's fine to limit the number of unsuccessful exchange attempts, but a
limit of one is too low.  Five attempts is more reasonable.

Limiting the number of successful exchange attempts to one makes sense.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Brian Eaton]

On Mon, Apr 27, 2009 at 8:25 PM, pkeane  wrote:
> I'm happy with  OAuth for the typical sorts of social networking,
> photo-sharing, etc. use cases, and I use it for that.  But I'd very
> much like to be able recommend it for more highly secure scenarios
> here on campus (I work in higher ed) that might involve confidential
> records.  For OAuth to replace or be used in conjunction with the
> cuurent campus SSO and federated systems like Shibboleth, we would
> really need that extra level of verifiable security.

Hi Peter -

SSO systems such as SAML/OpenID/others all use the equivalent of a
callback token to bind the session at the identity provider to the
relying party.  The fix to the OAuth protocol is to make it look just
like the "campus SSO and federated systems" that you mention above:

OpenID: signature on authentication response.
SAML POST profile: signature on authentication response.
SAML artifact profile: random single-use artifact value.

All of those systems pass a value that is unpredictable to the
attacker to a trusted location at the consumer site.  None of those
systems force the user to do anything as obnoxious as manually type a
pin at the consumer site.

If you think manually typing a pin increases security, you should
explain the attack you're trying to prevent.  Why should OAuth have
such a requirement if SAML and OpenID don't?

So far the only concrete "explanation" I've seen is that ATMs require
PINs, so OAuth should require a PIN.  You're confusing two-factor
authentication with federated authentication protocols.  Two factor
authentication is great, and it's fine for consumers and service
providers to implement that.  No change to the OAuth protocol is
necessary to support it.  Again, this is exactly analogous to the
situation in OpenID and SAML.  It's completely reasonable for a SAML
IdP to implement two-factor authentication for their users, and doing
so doesn't impact the SAML protocol one whit.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Apps using OAUTH and REST API in orkut environment

[suhasini]

I want to implement REST concept in my application development in
orkut environment. Is there any apps that already implemented REST and
OAUTH?


If yes, How can i do that? I already tried with PHP libraries but no
use. It's throwing some errors(fatal errors).

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Apps using OAUTH and REST API in orkut environment

[suhasini]

I want to implement REST concept in my application development in
orkut environment. Is there any apps that already implemented REST?


If yes, How can i do that? I already tried with PHP libraries but no
use. It's throwing some errors(fatal errors).

I have consumer key and consumer secret but unable to get access
token, I am getting http response as "you are being redirected to
http://www.orkut.com/";.

https://www.orkut.com/request_token?oauth_consumer_key=1007220910984
using POST, I am getting response as "you are being redirected to
http://www.orkut.com/";. Instead it should be oauth_token.

How to get opensocial data using OAuth and REST?

Kindly help me on this.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[jesse]

I agree that (3) would help a great deal.

It feels like all of the attention is being given to securing the
callback (2-3) and not the authorization redirect (1-2). Certainly
securing the callback can work, but only if we require that "Consumers
should NOT bind request tokens to accounts." I worry that putting the
burden on Consumers is not viable. Certainly, my company's consumers
to date have not been very savvy about OAuth and would be likely to
get this wrong.

I've been playing around with a version of our site that rejects the
authorization request if it doesn't happen within a short timeout or
if it has been previously used to initiate an authorization request.
This does require an extra redirect and some extra state after
receiving the authorization request to preserve refresh and back
button behavior.

Jesse

On Apr 28, 5:41 am, Hubert Le Van Gong  wrote:
> I also saw 2 additional ideas that might help
> (and are not necessarily exclusive with the 2 proposals):
>
> (3) Make Request tokens one-time only
> (4) Request that the user logs in at the Consumer before the request
> token request
>
> Are those off the table?
> I think (3), although potentially difficult to deploy, would significantly 
> help.
> Maybe (3) and (4) could be added in the spec as Best Practice or
> Recommendations?
>
> Hubert
>
> On Sun, Apr 26, 2009 at 7:48 AM, Eran Hammer-Lahav  
> wrote:
>
> > Let's see if we can take a quick break from the discussion and get a sense 
> > of where we are. Please answer the questions to follow.
>
> > ---
>
> > We have identified 2 solutions listed here:
>
> >https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory
>
> > * Signed Approval URLs
>
> > This proposal breaks the protocol into two separate flows, one for 
> > Consumers capable of launching a browser and accepting callbacks, and 
> > another for those who can't. It requires a significant rewrite of the 
> > specification because of the way the flow and signature are mixed together 
> > in the current Core 1.0 specification.
>
> > * Signed Callback URLs
>
> > This proposal makes the callback URL part of the signed request for Request 
> > Token (which does not allow an attacker to manipulate it), and adds some 
> > unpredictable value to the callback redirection that is needed to get an 
> > Access Token.
>
> > The spec changes include (see quick reference at the bottom):
>
> > - Move the oauth_callback parameter from 6.2.1 to 6.1.1
> > - Add a new parameter to 6.2.3 which is needed to make 6.3.1
>
> > ---
>
> > Open questions:
>
> > 1. Am I missing a completely different alternative? If yes, please create a 
> > new wiki page and point to it (if you don't have access ask or email it to 
> > someone who does).
>
> > 2. Given the simplicity of the Signed Callback URLs *specification change*, 
> > I would like to instead of asking people which solution they prefer, to ask 
> > people if they have a strong objection to using the Signed Callback URLs 
> > solution, and if so, to explain why?
>
> > 3. For the Signed Callback URLs solution, what to call the new parameter 
> > returned in 6.2.3? Suggestions so far included:
>
> > - pin
> > - verifier
> > - chaperon
> > - callback token
> > - callback secret
>
> > 4. And, should the new parameter be added to 6.3.1 (oauth_token + 
> > oauth_something) or replace the value of the oauth_token parameter?
>
> > The second option basically returns an authorized token which is used with 
> > the existing secret from 6.1.2. The benefit of a new parameter is it is 
> > easier to follow the protocol. The benefit of reusing oauth_token to make 
> > 6.3.1 is that is keeps the signed request consistent with all other signed 
> > requests (no new parameters).
>
> > EHL
>
> > ---
>
> > Quick Reference
>
> > 6.1.1.  Consumer Obtains a Request Token
> > 6.1.2.  Service Provider Issues an Unauthorized Request Token
> > 6.2.1.  Consumer Directs the User to the Service Provider
> > 6.2.2.  Service Provider Authenticates the User and Obtains Consent
> > 6.2.3.  Service Provider Directs the User Back to the Consumer
> > 6.3.1.  Consumer Requests an Access Token
> > 6.3.2.  Service Provider Grants an Access Token

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Andrew Badera]

Awesome! Thanks for that.

Thanks-
- Andy Badera
- and...@badera.us
- Google me: http://www.google.com/search?q=andrew+badera

Sent from Albany, NY, United States

On Tue, Apr 28, 2009 at 10:56 AM, Peter Keane  wrote:

>
> I can say I would not have gotten very far withoout Google OAuth
> playground:
>
> http://googlecodesamples.com/oauth_playground/
>
> --peter
>
> On Tue, Apr 28, 2009 at 9:39 AM, Gilles Devaux 
> wrote:
> >
> > Agree.
> > OAuth is not that complicated, reading the specs is. But honestly, if
> > you forget to sort the parameters before concatenating it means you
> > haven't read them at all (OAuth 1.0 - 9.1.1).
> >
> > One thing that really helped me to understand the flow was to create a
> > fake Service Provider.
> >
> > --Gilles
> >
> > On Tue, Apr 28, 2009 at 5:26 AM, Dossy Shiobara 
> wrote:
> >>
> >> On 4/28/09 1:42 AM, Chris Messina wrote:
> >>> Is OAuth this hard for everyone else?
> >>>
> >>> http://kentbrewster.com/oauth-confessions/
> >>>
> >>> *Sniff*.
> >>
> >> Funny enough, I ran into at least a few of the items on his list when
> >> writing my own OAuth consumer implementation from scratch.
> >>
> >> I honestly think that the OAuth _design_ isn't what makes it difficult.
> >>  It's the way the specification is written.  What really bit me in the
> >> ass the hardest was the "Parameter Encoding" requirement of the
> >> signature when using HTTP header authentication.  Deviating from the RFC
> >> just for OAuth violates POLS, guys.
> >>
> >> Honestly, after trying to decipher the spec. and not getting very far, I
> >> put it aside and went to Eran's GUI:
> >>
> >> http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html
> >>
> >> I almost wish I'd not bothered to confuse myself with the spec. and just
> >> used that one page.  It's a _fantastic_ reference implementation for
> >> anyone developing their own OAuth consumer.
> >>
> >> --
> >> Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
> >> Panoptic Computer Network   | http://panoptic.com/
> >>   "He realized the fastest way to change is to laugh at your own
> >> folly -- then you can let go and quickly move on." (p. 70)
> >>
> >> >
> >>
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[John Kemp]

On Apr 28, 2009, at 10:32 AM, Dossy Shiobara wrote:

>
> On 4/28/09 8:41 AM, Hubert Le Van Gong wrote:
>> I also saw 2 additional ideas that might help
>> (and are not necessarily exclusive with the 2 proposals):
>>
>> (3) Make Request tokens one-time only
>> (4) Request that the user logs in at the Consumer before the request
>> token request
>
> Requiring the user authenticate to the Consumer doesn't prevent the
> attack, as the attacker is a legitimate user of Consumer in the attack
> scenario.

Agreed. There are two parts - only one part is about both sides  
authenticating a user at their sites. The other part is the two  
parties (consumer and SP) agreeing that they are the same party (for  
the purposes of the protocol).

One possibility is to (as was suggested by Nat) use a Web SSO protocol  
and base that trust (shared notion of user at both sites) upon:

i) Web browser redirect-based protocols like OpenID and SAML
ii) Passing an identifier between the consumer and SP, which they can  
both agree on.

These steps are (in my opinion) neither part of standard OAuth itself,  
nor should they be, _explicitly_, unless we consider that for the  
purposes of adequate security for delegated authorization, it is  
required that both consumer and SP have a notion of identity, and can  
verify the identity of the user adequately (ie. via authentication).  
And this leaves open what would happen if the two parties don't or  
can't, a priori, agree on an identifier for the user (ie. if they  
don't support OpenID, or only support their own OpenIDs.

One possibility would be to describe the problem in the security  
considerations of the specification, and mention that both the  
consumer and the SP may want to both authenticate the user adequately,  
and (perhaps even as an extension to the protocol) share an identifier  
that they could agree on.

Making the user type a PIN (I forget who first suggested that) seems  
another plausible way, that may allow the consumer to avoid the notion  
of "identity" while maintaining adequate security.

> What I keep proposing is that the user must authenticate at the
> _Provider_ before the request token request.  This would completely
> eliminate the attack in the scenario.

As others (Peter, Nat, Hubert at least) have said (and I agree with),  
either the user must essentially authenticate in _both_ places  
(perhaps by doing Web SSO between the consumer and SP, where the  
consumer simply trusts the SP to authenticate the unknown person who  
showed up at its website because it was done with HTTP redirects, and  
authenticates the user simply via an authentication assertion from the  
SP); and those authentications must be connected in some way by the  
consumer and SP, _or_ a mechanism should be used which allows the SP  
to indicate a "secret" to both the consumer and the user, and use the  
user to connect the authentication at SP with the request token  
issuance via the PIN.

> And yes, making request tokens one-time only is a MUST, IMHO.

It is certainly a security consideration which should be adequately  
explained.

Regards,

- johnk

>
>
> -- 
> Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
> Panoptic Computer Network   | http://panoptic.com/
>   "He realized the fastest way to change is to laugh at your own
> folly -- then you can let go and quickly move on." (p. 70)
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Luca Mearelli]

On Tue, Apr 28, 2009 at 4:41 PM, Hubert Le Van Gong  wrote:
> Is the reason for *discarding* this solution the fact that it's
> an additional roundtrip in the flow (or put another way it's too big
> a change to the current protocol)?

yes and more than that the fact that adding another roundtrip could
make for a far worse user experience, possibly alienating a lot of
legitimate users pushing them towards even less safe "protocols" (e.g.
giving out their SP user & password)

Luca

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Dossy Shiobara]

On 4/28/09 10:41 AM, Hubert Le Van Gong wrote:
> Is the reason for*discarding*  this solution the fact that it's
> an additional roundtrip in the flow (or put another way it's too big
> a change to the current protocol)?

If this _is_ indeed the case, then perhaps its time to start drafting 
OAuth 2.0, which would include this significant change.

-- 
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
   "He realized the fastest way to change is to laugh at your own
 folly -- then you can let go and quickly move on." (p. 70)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Peter Keane]

I can say I would not have gotten very far withoout Google OAuth playground:

http://googlecodesamples.com/oauth_playground/

--peter

On Tue, Apr 28, 2009 at 9:39 AM, Gilles Devaux  wrote:
>
> Agree.
> OAuth is not that complicated, reading the specs is. But honestly, if
> you forget to sort the parameters before concatenating it means you
> haven't read them at all (OAuth 1.0 - 9.1.1).
>
> One thing that really helped me to understand the flow was to create a
> fake Service Provider.
>
> --Gilles
>
> On Tue, Apr 28, 2009 at 5:26 AM, Dossy Shiobara  wrote:
>>
>> On 4/28/09 1:42 AM, Chris Messina wrote:
>>> Is OAuth this hard for everyone else?
>>>
>>> http://kentbrewster.com/oauth-confessions/
>>>
>>> *Sniff*.
>>
>> Funny enough, I ran into at least a few of the items on his list when
>> writing my own OAuth consumer implementation from scratch.
>>
>> I honestly think that the OAuth _design_ isn't what makes it difficult.
>>  It's the way the specification is written.  What really bit me in the
>> ass the hardest was the "Parameter Encoding" requirement of the
>> signature when using HTTP header authentication.  Deviating from the RFC
>> just for OAuth violates POLS, guys.
>>
>> Honestly, after trying to decipher the spec. and not getting very far, I
>> put it aside and went to Eran's GUI:
>>
>>     http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html
>>
>> I almost wish I'd not bothered to confuse myself with the spec. and just
>> used that one page.  It's a _fantastic_ reference implementation for
>> anyone developing their own OAuth consumer.
>>
>> --
>> Dossy Shiobara              | do...@panoptic.com | http://dossy.org/
>> Panoptic Computer Network   | http://panoptic.com/
>>   "He realized the fastest way to change is to laugh at your own
>>     folly -- then you can let go and quickly move on." (p. 70)
>>
>> >
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Dossy Shiobara]

On 4/28/09 10:40 AM, Peter Keane wrote:
> But the consumer will still need to communicate back to the SP that it
> has some unique knowledge that it could only have been offered at the
> SP authentication point.  Most proposals do this with the
> "verification token" -- my reasoning leads me to believe that needs to
> be passed "out-of-band."  I'm not sure that moving the authentication
> before request token necessarilly guarantees that.

It doens't need to be passed out of band.  You only need to defend 
against it being intercepted by an attacker.

-- 
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
   "He realized the fastest way to change is to laugh at your own
 folly -- then you can let go and quickly move on." (p. 70)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Peter Keane]

On Tue, Apr 28, 2009 at 9:47 AM, Dossy Shiobara  wrote:
>
> On 4/28/09 9:27 AM, Peter Keane wrote:
>> As an analogy, imagine if banks allowed withdrawals w/o a user typing
>> a PIN.  The bank can guarantee that I am the one who was issued the
>> card AND it can guarantee that is the same card being used to withdraw
>> money. And you can do all kinds of things to guard against anyone but
>> the legitimate card owner to get ahold of it.  But unless you take
>> that extra step (the PIN entered at the ATM) you never create
>> sufficiant linkages to "verify" authenticity.  That's why PIN can be
>> short&  easy to remember (but should NOT be written on the card! ;-)).
>>   Since it is an out-of-band arrangement, it offers a high level of
>> assurance.
>
> Although, the banks have known for a long time that their implementation
> is without security.  Hackers today are compromising the MDS crypto
> blocks and are stealing PINs en masse.  Basically, the banks implemented
> a system that assumed that the secret would remain secret and could
> never be compromised, similar to OAuth's dependency on the secrets
> remaining secret.
>
> The banks are due for a huge overhaul of their ATM transaction platform
> or continue to lose serious money to the hackers.
>


I would actually be perfectly happy with a protocol that was as secure
as debit card + PIN.  Whether that is adequate or not is (to my mind)
out of scope and beyond the reach of OAuth.  But as it stands now, I
don't think it is at that level of assured security.

I'll add: two-legged OAuth does indeed achieve that level of assured
security (as far as I can tell) and I'll be happy to use it.  (I'll
note, re: Blaine's previous comment -- this *does* rest on the trust
relationship between SP and consumer and that is fine, since that is
all it is attempting).

--peter


> Fortunately, no one implementing OAuth has anything so valuable, yet.
> However, OAuth's inherent similar flaw will likely mean that no service
> that does have anything valuable will expose those resources using
> OAuth.  It's a very sad, built-in limiting factor for something with
> such potential.
>
> --
> Dossy Shiobara              | do...@panoptic.com | http://dossy.org/
> Panoptic Computer Network   | http://panoptic.com/
>   "He realized the fastest way to change is to laugh at your own
>     folly -- then you can let go and quickly move on." (p. 70)
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Peter Keane]

On Tue, Apr 28, 2009 at 9:42 AM, Dossy Shiobara  wrote:
>
> On 4/28/09 9:05 AM, Peter Keane wrote:
>> That's exactly right:  OAuth leverages the secrecy of the out-of-band
>> agreement between consumer and SP.   The request token is built upon
>> that assumption, so it can safely be considered secret for the
>> purposes of OAuth.
>
> If this is the founding principle of OAuth, then perhaps I'm wasting my
> time.  Perhaps I should instead formulate a specification for an open
> authorization protocol that doesn't have this assumption.
>

Dossy-

It's only part of the equation though. The *whole* protocol does not
rest on that.  Only the part that allows the consumer to
"authenticate" (as it were), with the SP -- essentially saying "yes,
SP this is indeed the consumer that pre-registered with you".  Mixing
in the user is where things get tricky

--peter

> --
> Dossy Shiobara              | do...@panoptic.com | http://dossy.org/
> Panoptic Computer Network   | http://panoptic.com/
>   "He realized the fastest way to change is to laugh at your own
>     folly -- then you can let go and quickly move on." (p. 70)
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: CANCELLED: San Francisco meetup this Tuesday 5pm

[Gilles Devaux]

Do you plan to postpone it?

I did not realize I had to respond and was going to show up.

--Gilles

On Mon, Apr 27, 2009 at 11:32 PM, Chris Messina  wrote:
> :(
> Seems like 5 people would be a good-sized group to actually get some real
> work done.
> Of course it's up to you and then folks who had signed up to attend, but I
> wouldn't be discouraged by what might appear to be a relatively small sized
> number of attendees.
> Chris
>
> On Mon, Apr 27, 2009 at 2:04 PM, Leah Culver  wrote:
>>
>> Since less than 5 people have responded, I'm cancelling this meeting.
>>
>> Sorry about the short notice,
>> Leah
>>
>> On Fri, Apr 24, 2009 at 2:42 PM, Leah Culver 
>> wrote:
>>>
>>> Hi all,
>>>
>>> My eyes hurt from trying to read long email threads. There's quite a
>>> few good ideas for helping protect against the current security issue
>>> and it will be helpful to get together to discuss. Here's the details:
>>>
>>> OAuth Meetup
>>> Tuesday, Apr 28th at 5pm
>>> Six Apart
>>> 548 4th Street
>>>
>>> I'll try to get the conference call stuff working too - more about
>>> this later.
>>>
>>> Sorry for the short notice! I'll try to summarize the meeting and get
>>> the notes back in the mailing list or wiki.
>>>
>>> Leah
>>
>>
>
>
>
> --
> Chris Messina
> Open Web Advocate
>
> factoryjoe.com // diso-project.org // openid.net // vidoop.com
> This email is:   [ ] bloggable    [X] ask first   [ ] private
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Dossy Shiobara]

On 4/28/09 9:27 AM, Peter Keane wrote:
> As an analogy, imagine if banks allowed withdrawals w/o a user typing
> a PIN.  The bank can guarantee that I am the one who was issued the
> card AND it can guarantee that is the same card being used to withdraw
> money. And you can do all kinds of things to guard against anyone but
> the legitimate card owner to get ahold of it.  But unless you take
> that extra step (the PIN entered at the ATM) you never create
> sufficiant linkages to "verify" authenticity.  That's why PIN can be
> short&  easy to remember (but should NOT be written on the card! ;-)).
>   Since it is an out-of-band arrangement, it offers a high level of
> assurance.

Although, the banks have known for a long time that their implementation 
is without security.  Hackers today are compromising the MDS crypto 
blocks and are stealing PINs en masse.  Basically, the banks implemented 
a system that assumed that the secret would remain secret and could 
never be compromised, similar to OAuth's dependency on the secrets 
remaining secret.

The banks are due for a huge overhaul of their ATM transaction platform 
or continue to lose serious money to the hackers.

Fortunately, no one implementing OAuth has anything so valuable, yet. 
However, OAuth's inherent similar flaw will likely mean that no service 
that does have anything valuable will expose those resources using 
OAuth.  It's a very sad, built-in limiting factor for something with 
such potential.

-- 
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
   "He realized the fastest way to change is to laugh at your own
 folly -- then you can let go and quickly move on." (p. 70)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Dossy Shiobara]

On 4/28/09 9:05 AM, Peter Keane wrote:
> That's exactly right:  OAuth leverages the secrecy of the out-of-band
> agreement between consumer and SP.   The request token is built upon
> that assumption, so it can safely be considered secret for the
> purposes of OAuth.

If this is the founding principle of OAuth, then perhaps I'm wasting my 
time.  Perhaps I should instead formulate a specification for an open 
authorization protocol that doesn't have this assumption.

-- 
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
   "He realized the fastest way to change is to laugh at your own
 folly -- then you can let go and quickly move on." (p. 70)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Hubert Le Van Gong]

On Tue, Apr 28, 2009 at 4:32 PM, Dossy Shiobara  wrote:
>
> On 4/28/09 8:41 AM, Hubert Le Van Gong wrote:
>> I also saw 2 additional ideas that might help
>> (and are not necessarily exclusive with the 2 proposals):
>>
>> (3) Make Request tokens one-time only
>> (4) Request that the user logs in at the Consumer before the request
>> token request
>
> Requiring the user authenticate to the Consumer doesn't prevent the
> attack, as the attacker is a legitimate user of Consumer in the attack
> scenario.
>
> What I keep proposing is that the user must authenticate at the
> _Provider_ before the request token request.  This would completely
> eliminate the attack in the scenario.
>
> And yes, making request tokens one-time only is a MUST, IMHO.
>

Ah yes, that's what I meant: the user authenticates at the Provider
before the token request is issued - sorry, getting old :)
Sounds like a valid option to me.
Is the reason for *discarding* this solution the fact that it's
an additional roundtrip in the flow (or put another way it's too big
a change to the current protocol)?

Cheers,
Hubert

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Peter Keane]

On Tue, Apr 28, 2009 at 9:32 AM, Dossy Shiobara  wrote:
>
> On 4/28/09 8:41 AM, Hubert Le Van Gong wrote:
>> I also saw 2 additional ideas that might help
>> (and are not necessarily exclusive with the 2 proposals):
>>
>> (3) Make Request tokens one-time only
>> (4) Request that the user logs in at the Consumer before the request
>> token request
>
> Requiring the user authenticate to the Consumer doesn't prevent the
> attack, as the attacker is a legitimate user of Consumer in the attack
> scenario.
>
> What I keep proposing is that the user must authenticate at the
> _Provider_ before the request token request.  This would completely
> eliminate the attack in the scenario.
>

Hi Dossy-

But the consumer will still need to communicate back to the SP that it
has some unique knowledge that it could only have been offered at the
SP authentication point.  Most proposals do this with the
"verification token" -- my reasoning leads me to believe that needs to
be passed "out-of-band."  I'm not sure that moving the authentication
before request token necessarilly guarantees that.

--peter

> And yes, making request tokens one-time only is a MUST, IMHO.
>
> --
> Dossy Shiobara              | do...@panoptic.com | http://dossy.org/
> Panoptic Computer Network   | http://panoptic.com/
>   "He realized the fastest way to change is to laugh at your own
>     folly -- then you can let go and quickly move on." (p. 70)
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Gilles Devaux]

Agree.
OAuth is not that complicated, reading the specs is. But honestly, if
you forget to sort the parameters before concatenating it means you
haven't read them at all (OAuth 1.0 - 9.1.1).

One thing that really helped me to understand the flow was to create a
fake Service Provider.

--Gilles

On Tue, Apr 28, 2009 at 5:26 AM, Dossy Shiobara  wrote:
>
> On 4/28/09 1:42 AM, Chris Messina wrote:
>> Is OAuth this hard for everyone else?
>>
>> http://kentbrewster.com/oauth-confessions/
>>
>> *Sniff*.
>
> Funny enough, I ran into at least a few of the items on his list when
> writing my own OAuth consumer implementation from scratch.
>
> I honestly think that the OAuth _design_ isn't what makes it difficult.
>  It's the way the specification is written.  What really bit me in the
> ass the hardest was the "Parameter Encoding" requirement of the
> signature when using HTTP header authentication.  Deviating from the RFC
> just for OAuth violates POLS, guys.
>
> Honestly, after trying to decipher the spec. and not getting very far, I
> put it aside and went to Eran's GUI:
>
>     http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html
>
> I almost wish I'd not bothered to confuse myself with the spec. and just
> used that one page.  It's a _fantastic_ reference implementation for
> anyone developing their own OAuth consumer.
>
> --
> Dossy Shiobara              | do...@panoptic.com | http://dossy.org/
> Panoptic Computer Network   | http://panoptic.com/
>   "He realized the fastest way to change is to laugh at your own
>     folly -- then you can let go and quickly move on." (p. 70)
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Dossy Shiobara]

On 4/28/09 8:41 AM, Hubert Le Van Gong wrote:
> I also saw 2 additional ideas that might help
> (and are not necessarily exclusive with the 2 proposals):
>
> (3) Make Request tokens one-time only
> (4) Request that the user logs in at the Consumer before the request
> token request

Requiring the user authenticate to the Consumer doesn't prevent the 
attack, as the attacker is a legitimate user of Consumer in the attack 
scenario.

What I keep proposing is that the user must authenticate at the 
_Provider_ before the request token request.  This would completely 
eliminate the attack in the scenario.

And yes, making request tokens one-time only is a MUST, IMHO.

-- 
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
   "He realized the fastest way to change is to laugh at your own
 folly -- then you can let go and quickly move on." (p. 70)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Peter Keane]

On Tue, Apr 28, 2009 at 8:46 AM, Blaine Cook  wrote:
>
> On Tue, Apr 28, 2009 at 2:27 PM, Peter Keane  wrote:
>> Yes, that's right.  What it does (for the sake of the SP) is assert
>> "this user on the consumer is indeed the same user that authenticated
>> at the SP."  Authorization always requires authentication (system
>> needs to know "who" it is authorizing).
>
> For OAuth, this relationship is simple. The SP authenticates the user,
> but authorizes the consumer-plus-request-token pair. The SP *does not*
> authorize an authenticated user at the consumer end. That relationship
> is up to the consumer to decide.
>
> Put another way, if TweetCash had been given authorization by many
> users to access Twitter accounts, they (TweetCash) could impersonate
> any one of those accounts in any way they choose. However, it's a
> trust relationship. If TweetCash were to abuse that trust, then
> Twitter has the ability to disable their access wholesale (via the
> consumer key) or the users have the ability to revoke access on a
> case-by-case bases. At no point can Twitter *guarantee* that TweetCash
> isn't abusing the trust, but it's probably impossible to do so without
> creating an unusable technology, particularly for the sorts of
> problems we're trying to solve.
>

That is an interesting & useful way to look at it.  The SP "trusts"
its own authentication mechanism and the consumer signing up for OAuth
services.  I had though, though, that this was about the SP offering a
trustworthy service to its *users*.  In other words, saying -- "we
offer OAuth w/ these consumers because we trust all of the pieces to
work."  The exploit is a danger to the SP only inasmuch as it is a
danger to the user.

As a convenience mechanism, OAuth is just fine.  But I was imagining
3-legged OAuth as potentially useful for more highly *risky*
operations, like access to confidential personal or health records.
That may not be a safe assumption on my part, tough (?).


> The exploit that we're dealing with is that the consumer has no way to
> ensure that the SP has authorized access to the intended party. The
> verification token *does* ensure this, since it guarantees that the
> person that clicks "Authorize {consumer}" is the same one that is
> interacting with the consumer, and that's all we're trying to solve.
> OAuth does not, and should not, attempt to authenticate identity
> across sites.

I would definitely agree that if the verification token does
"guarantee that the person that clicks 'Authorize {consumer}' is the
same one that is interacting with the consumer" that's everything we
need.  But that *is* "authentication" -- to actually verify that
(given the statelessness of HTTP) is tricky.  Essentially, the
verification token is attempting to establish "state."

-peter

>
> b.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Blaine Cook]

On Tue, Apr 28, 2009 at 2:27 PM, Peter Keane  wrote:
> Yes, that's right.  What it does (for the sake of the SP) is assert
> "this user on the consumer is indeed the same user that authenticated
> at the SP."  Authorization always requires authentication (system
> needs to know "who" it is authorizing).

For OAuth, this relationship is simple. The SP authenticates the user,
but authorizes the consumer-plus-request-token pair. The SP *does not*
authorize an authenticated user at the consumer end. That relationship
is up to the consumer to decide.

Put another way, if TweetCash had been given authorization by many
users to access Twitter accounts, they (TweetCash) could impersonate
any one of those accounts in any way they choose. However, it's a
trust relationship. If TweetCash were to abuse that trust, then
Twitter has the ability to disable their access wholesale (via the
consumer key) or the users have the ability to revoke access on a
case-by-case bases. At no point can Twitter *guarantee* that TweetCash
isn't abusing the trust, but it's probably impossible to do so without
creating an unusable technology, particularly for the sorts of
problems we're trying to solve.

The exploit that we're dealing with is that the consumer has no way to
ensure that the SP has authorized access to the intended party. The
verification token *does* ensure this, since it guarantees that the
person that clicks "Authorize {consumer}" is the same one that is
interacting with the consumer, and that's all we're trying to solve.
OAuth does not, and should not, attempt to authenticate identity
across sites.

b.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Peter Keane]

On Tue, Apr 28, 2009 at 8:14 AM, Hubert Le Van Gong  wrote:
>
> On Tue, Apr 28, 2009 at 2:57 PM, Peter Keane  wrote:
>>
>> On Tue, Apr 28, 2009 at 7:41 AM, Hubert Le Van Gong  
>> wrote:
>>>
>>> I also saw 2 additional ideas that might help
>>> (and are not necessarily exclusive with the 2 proposals):
>>>
>>> (3) Make Request tokens one-time only
>>> (4) Request that the user logs in at the Consumer before the request
>>> token request
>>
>> Actually, there is no requirement that the Consumer have any notion of
>> identity, in which case the consumer has no mechanism to sign user in.
>>  The idea here is that you can leverage the the SP's authentication
>> service as long as you can verify that the u...@sp == u...@consumer.
>> And the only way to do that is w/ an out-of-band agreement, such as a
>> PIN that the user gets upon sign-in at the SP and must type in at the
>> consumer.
>
> So if I understand your use case, in addition to delegated authorization
> of Consumer to access a resource at SP, OAuth also provides for
> delegated authentication of the user at the Consumer by the SP?


Yes, that's right.  What it does (for the sake of the SP) is assert
"this user on the consumer is indeed the same user that authenticated
at the SP."  Authorization always requires authentication (system
needs to know "who" it is authorizing).

As an analogy, imagine if banks allowed withdrawals w/o a user typing
a PIN.  The bank can guarantee that I am the one who was issued the
card AND it can guarantee that is the same card being used to withdraw
money. And you can do all kinds of things to guard against anyone but
the legitimate card owner to get ahold of it.  But unless you take
that extra step (the PIN entered at the ATM) you never create
sufficiant linkages to "verify" authenticity.  That's why PIN can be
short & easy to remember (but should NOT be written on the card! ;-)).
 Since it is an out-of-band arrangement, it offers a high level of
assurance.

--peter

>
> Just trying to get my head around that case...
>
> Hubert
>
>
>
>>
>> --peter
>>
>>>
>>> Are those off the table?
>>> I think (3), although potentially difficult to deploy, would significantly 
>>> help.
>>> Maybe (3) and (4) could be added in the spec as Best Practice or
>>> Recommendations?
>>>
>>> Hubert
>>>
>>>
>>>
>>> On Sun, Apr 26, 2009 at 7:48 AM, Eran Hammer-Lahav  
>>> wrote:

 Let's see if we can take a quick break from the discussion and get a sense 
 of where we are. Please answer the questions to follow.

 ---

 We have identified 2 solutions listed here:

 https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory


 * Signed Approval URLs

 This proposal breaks the protocol into two separate flows, one for 
 Consumers capable of launching a browser and accepting callbacks, and 
 another for those who can't. It requires a significant rewrite of the 
 specification because of the way the flow and signature are mixed together 
 in the current Core 1.0 specification.


 * Signed Callback URLs

 This proposal makes the callback URL part of the signed request for 
 Request Token (which does not allow an attacker to manipulate it), and 
 adds some unpredictable value to the callback redirection that is needed 
 to get an Access Token.

 The spec changes include (see quick reference at the bottom):

 - Move the oauth_callback parameter from 6.2.1 to 6.1.1
 - Add a new parameter to 6.2.3 which is needed to make 6.3.1

 ---

 Open questions:

 1. Am I missing a completely different alternative? If yes, please create 
 a new wiki page and point to it (if you don't have access ask or email it 
 to someone who does).

 2. Given the simplicity of the Signed Callback URLs *specification 
 change*, I would like to instead of asking people which solution they 
 prefer, to ask people if they have a strong objection to using the Signed 
 Callback URLs solution, and if so, to explain why?

 3. For the Signed Callback URLs solution, what to call the new parameter 
 returned in 6.2.3? Suggestions so far included:

 - pin
 - verifier
 - chaperon
 - callback token
 - callback secret

 4. And, should the new parameter be added to 6.3.1 (oauth_token + 
 oauth_something) or replace the value of the oauth_token parameter?

 The second option basically returns an authorized token which is used with 
 the existing secret from 6.1.2. The benefit of a new parameter is it is 
 easier to follow the protocol. The benefit of reusing oauth_token to make 
 6.3.1 is that is keeps the signed request consistent with all other signed 
 requests (no new parameters).

 EHL

 ---

 Quick Reference

 6.1.1.  Consumer Obtains a Request Token
 6.1.2.  Service Provider Issues an Unauthorized Request Token
 

[oauth] Re: Moving forward

[Peter Keane]

On Mon, Apr 27, 2009 at 11:33 PM, Josh Roesslein  wrote:
> Peter,
>
> Couldn't we verify the user on the consumer-side during the callback URL
> redirect (user returning from SP after authorization)?
> This callback URL has two pieces of data:
>    - Callback secrete: generated by SP after user authorizes consumer
>    - Request token: publicly known, so could be forged by attacker
> Plus we can do this callback with https to prevent man in the middle attacks
> on the wire. We are using https to exchanges passwords with the SP, so
> if https was vulnerable in some way, we have already lost the fight since
> the attacker now has our SP password.
>
> As long as the consumer links this authorization with the user during this
> callback phase, the attack can not do a session fixation.
> When consumer goes to fetch access token, it can only do so with the request
> token and the callback secrete.
> Since only the authorizing user can know this callback secrete, an attacker
> can not complete this callback phase.
>
> Consumers should NOT bind request tokens to accounts. This should only be
> done during callback.
> This way even if the attacker generated the request token URL using their
> consumer account, it is not bound to any account yet.
> This only occurs during the callback phase which only the user can do.
>
> I think this provider a verifiable means to link the user's consumer account
> with their SP account with out having to do any pin exchanges.
> We could do a manual exchange of the callback secrete (so its like a pin)
> that the user manually enters into the consumer. This way there is no way
> a man in the middle can see this value. Consumer will know this is the right
> user when it fetches the access token (which will fail with invalid value)
> and the SP
> will know its valid since the incoming value from the consumer matches what
> it gave to the user. A social attack could be used to make user
> share this value. With proper education we can help minimize this, but not
> totally prevent it. This is why I don't like the pin approach, it leaves it
> opens us up for another
> social attack. By invisibly passing this value via a https callback, a
> social attack is blocked.
>

Hi Josh-

All of the strong/secure parts of the OAuth spec are built on previous
arrangements (out-of-band):  the consumer-SP registration, and the SP
user authentication mechanism.  Both of those are vulnerable to social
attacks, but those are out of scope for OAuth (and should be). You are
correct that a manual exchange of callback secrete provides the
"verifibility" that we need.  I don't think a social attack is likely,
either, since that secret is only created upon user authentication at
the SP (i.e., too late in the game for the attacker to get at it).  Of
course, it should be a once-and-only-once validity and for a limited
time period, but it does ensure verifiable identity.

--peter


> On Mon, Apr 27, 2009 at 10:25 PM, pkeane  wrote:
>>
>>
>>
>> On Apr 27, 10:11 am, Brian Eaton  wrote:
>> > On Sun, Apr 26, 2009 at 6:29 PM, Peter Keane  wrote:
>> > >> b) that's what the unpredictable callback token is for.
>> >
>> > > Does that demonstrate it is the same user?  I believe it makes it
>> > > highly likely, but not "verifyable" (in standard authentication terms.
>> > > Nothing is 100% verifyable).
>> >
>> > The request token provides linkage from the consumer to the service
>> > provider.  The callback token provides linkage in the opposite
>> > direction.  If the consumer proves possession of a  matching request
>> > token and callback token, that's excellent evidence that no session
>> > fixation attack is occurring.
>>
>> Hi Brian-
>>
>> Certainly, it is excellent evidence.  But I worry about not having a
>> verifiable linkage.  The linkages that OAuth leverage are as follows:
>>
>> 1.  The consumer and the SP have a shared "out-of-band" secret
>> (consumer pre-registration).  That allows the consumer to tell the SP
>> "hey it's verifiably me"  (by way of the request token).
>> 2. The user and the SP also have a shared "out-of-band" arrangement
>> -- SP authentication -- that verifies the user is verifiably who they
>> say they are.
>>
>> Note that those are both based on "out-of-band" arrangements.  There
>> is actually no link  to tie the user to the consumer, except for
>> tokens, parameters, etc., but those are all "in-band" and so are *not*
>> verifiable.  That last missing link is necessary for verifiable
>> identification of the u...@consumer.  A simple PIN or somesuch would
>> do it.
>>
>> I'm happy with  OAuth for the typical sorts of social networking,
>> photo-sharing, etc. use cases, and I use it for that.  But I'd very
>> much like to be able recommend it for more highly secure scenarios
>> here on campus (I work in higher ed) that might involve confidential
>> records.  For OAuth to replace or be used in conjunction with the
>> cuurent campus SSO and federated systems like Shibboleth, we would
>> real

[oauth] Re: Moving forward

[Hubert Le Van Gong]

On Tue, Apr 28, 2009 at 2:57 PM, Peter Keane  wrote:
>
> On Tue, Apr 28, 2009 at 7:41 AM, Hubert Le Van Gong  
> wrote:
>>
>> I also saw 2 additional ideas that might help
>> (and are not necessarily exclusive with the 2 proposals):
>>
>> (3) Make Request tokens one-time only
>> (4) Request that the user logs in at the Consumer before the request
>> token request
>
> Actually, there is no requirement that the Consumer have any notion of
> identity, in which case the consumer has no mechanism to sign user in.
>  The idea here is that you can leverage the the SP's authentication
> service as long as you can verify that the u...@sp == u...@consumer.
> And the only way to do that is w/ an out-of-band agreement, such as a
> PIN that the user gets upon sign-in at the SP and must type in at the
> consumer.

So if I understand your use case, in addition to delegated authorization
of Consumer to access a resource at SP, OAuth also provides for
delegated authentication of the user at the Consumer by the SP?

Just trying to get my head around that case...

Hubert



>
> --peter
>
>>
>> Are those off the table?
>> I think (3), although potentially difficult to deploy, would significantly 
>> help.
>> Maybe (3) and (4) could be added in the spec as Best Practice or
>> Recommendations?
>>
>> Hubert
>>
>>
>>
>> On Sun, Apr 26, 2009 at 7:48 AM, Eran Hammer-Lahav  
>> wrote:
>>>
>>> Let's see if we can take a quick break from the discussion and get a sense 
>>> of where we are. Please answer the questions to follow.
>>>
>>> ---
>>>
>>> We have identified 2 solutions listed here:
>>>
>>> https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory
>>>
>>>
>>> * Signed Approval URLs
>>>
>>> This proposal breaks the protocol into two separate flows, one for 
>>> Consumers capable of launching a browser and accepting callbacks, and 
>>> another for those who can't. It requires a significant rewrite of the 
>>> specification because of the way the flow and signature are mixed together 
>>> in the current Core 1.0 specification.
>>>
>>>
>>> * Signed Callback URLs
>>>
>>> This proposal makes the callback URL part of the signed request for Request 
>>> Token (which does not allow an attacker to manipulate it), and adds some 
>>> unpredictable value to the callback redirection that is needed to get an 
>>> Access Token.
>>>
>>> The spec changes include (see quick reference at the bottom):
>>>
>>> - Move the oauth_callback parameter from 6.2.1 to 6.1.1
>>> - Add a new parameter to 6.2.3 which is needed to make 6.3.1
>>>
>>> ---
>>>
>>> Open questions:
>>>
>>> 1. Am I missing a completely different alternative? If yes, please create a 
>>> new wiki page and point to it (if you don't have access ask or email it to 
>>> someone who does).
>>>
>>> 2. Given the simplicity of the Signed Callback URLs *specification change*, 
>>> I would like to instead of asking people which solution they prefer, to ask 
>>> people if they have a strong objection to using the Signed Callback URLs 
>>> solution, and if so, to explain why?
>>>
>>> 3. For the Signed Callback URLs solution, what to call the new parameter 
>>> returned in 6.2.3? Suggestions so far included:
>>>
>>> - pin
>>> - verifier
>>> - chaperon
>>> - callback token
>>> - callback secret
>>>
>>> 4. And, should the new parameter be added to 6.3.1 (oauth_token + 
>>> oauth_something) or replace the value of the oauth_token parameter?
>>>
>>> The second option basically returns an authorized token which is used with 
>>> the existing secret from 6.1.2. The benefit of a new parameter is it is 
>>> easier to follow the protocol. The benefit of reusing oauth_token to make 
>>> 6.3.1 is that is keeps the signed request consistent with all other signed 
>>> requests (no new parameters).
>>>
>>> EHL
>>>
>>> ---
>>>
>>> Quick Reference
>>>
>>> 6.1.1.  Consumer Obtains a Request Token
>>> 6.1.2.  Service Provider Issues an Unauthorized Request Token
>>> 6.2.1.  Consumer Directs the User to the Service Provider
>>> 6.2.2.  Service Provider Authenticates the User and Obtains Consent
>>> 6.2.3.  Service Provider Directs the User Back to the Consumer
>>> 6.3.1.  Consumer Requests an Access Token
>>> 6.3.2.  Service Provider Grants an Access Token
>>>
>>>
>>> >
>>>
>>
>> >
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Peter Keane]

On Tue, Apr 28, 2009 at 7:37 AM, Blaine Cook  wrote:
>
> On Tue, Apr 28, 2009 at 1:18 PM, Dossy Shiobara  wrote:
>>
>> If and only if the callback URL is protected from tampering.  Since we
>> cannot guarantee the consumer secret and request token secret to be ...
>> well, secret ... there's no way to guarantee in ALL cases that the
>> callback URL will be protected from tampering.
>
> If you can't guarantee the request token secret to be secret, then all
> bets are off everywhere. OAuth has been designed such that the request
> token secret *is* secret, and in the case of non-redistributed
> consumers (e.g., web sites or open source software with a requirement
> to obtain a new consumer key/secret), the consumer secret *is* also
> secret.

That's exactly right:  OAuth leverages the secrecy of the out-of-band
agreement between consumer and SP.   The request token is built upon
that assumption, so it can safely be considered secret for the
purposes of OAuth.

>
> For the callback URL signing case, it is absolutely possible to
> guarantee that the request token secret remains private, and therefore
> absolutely possible to ensure that the callback URL (and thus, the
> verification token) is genuine.
>

While it is possible to tweak things to make sure the callback URL is
genuine, that does not directly address the need to verify that the
u...@consumer == u...@sp.  Of course, it makes it highly probable and
also makes an attack less likely (actually makes the attack in
question impossible), but you are still relying on stateless HTTP
transactions to establish "state" between SP & consumer & user.  The
only way I can see to accomplish that is to create out-of-band "state"
on the user (e.g., a PIN or somesuch) that they carry from SP to
consumer.

--peter

> My reading of Eran's proposal doesn't incorporate this level of
> signing. That is, I *don't* see a proposal to actually include a
> callback signature parameter in the callback URL, as in:
>
> http://example.com/callbackEndpoint?oauth_token=x&oauth_verifier=y&oauth_signature=HMAC-SHA1(oauth_token_secret,
> Normalized("http://example.com/callbackEndpoint?oauth_token=x&oauth_verifier=y";))
>
> It might be worthwhile, though, to do that? On the other hand, it
> would significantly complicate things, and might not provide a
> significant benefit, especially if both the callback URL and the
> authorization endpoint were handled over SSL.
>
> b.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Peter Keane]

On Tue, Apr 28, 2009 at 7:41 AM, Hubert Le Van Gong  wrote:
>
> I also saw 2 additional ideas that might help
> (and are not necessarily exclusive with the 2 proposals):
>
> (3) Make Request tokens one-time only
> (4) Request that the user logs in at the Consumer before the request
> token request

Actually, there is no requirement that the Consumer have any notion of
identity, in which case the consumer has no mechanism to sign user in.
 The idea here is that you can leverage the the SP's authentication
service as long as you can verify that the u...@sp == u...@consumer.
And the only way to do that is w/ an out-of-band agreement, such as a
PIN that the user gets upon sign-in at the SP and must type in at the
consumer.

--peter

>
> Are those off the table?
> I think (3), although potentially difficult to deploy, would significantly 
> help.
> Maybe (3) and (4) could be added in the spec as Best Practice or
> Recommendations?
>
> Hubert
>
>
>
> On Sun, Apr 26, 2009 at 7:48 AM, Eran Hammer-Lahav  
> wrote:
>>
>> Let's see if we can take a quick break from the discussion and get a sense 
>> of where we are. Please answer the questions to follow.
>>
>> ---
>>
>> We have identified 2 solutions listed here:
>>
>> https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory
>>
>>
>> * Signed Approval URLs
>>
>> This proposal breaks the protocol into two separate flows, one for Consumers 
>> capable of launching a browser and accepting callbacks, and another for 
>> those who can't. It requires a significant rewrite of the specification 
>> because of the way the flow and signature are mixed together in the current 
>> Core 1.0 specification.
>>
>>
>> * Signed Callback URLs
>>
>> This proposal makes the callback URL part of the signed request for Request 
>> Token (which does not allow an attacker to manipulate it), and adds some 
>> unpredictable value to the callback redirection that is needed to get an 
>> Access Token.
>>
>> The spec changes include (see quick reference at the bottom):
>>
>> - Move the oauth_callback parameter from 6.2.1 to 6.1.1
>> - Add a new parameter to 6.2.3 which is needed to make 6.3.1
>>
>> ---
>>
>> Open questions:
>>
>> 1. Am I missing a completely different alternative? If yes, please create a 
>> new wiki page and point to it (if you don't have access ask or email it to 
>> someone who does).
>>
>> 2. Given the simplicity of the Signed Callback URLs *specification change*, 
>> I would like to instead of asking people which solution they prefer, to ask 
>> people if they have a strong objection to using the Signed Callback URLs 
>> solution, and if so, to explain why?
>>
>> 3. For the Signed Callback URLs solution, what to call the new parameter 
>> returned in 6.2.3? Suggestions so far included:
>>
>> - pin
>> - verifier
>> - chaperon
>> - callback token
>> - callback secret
>>
>> 4. And, should the new parameter be added to 6.3.1 (oauth_token + 
>> oauth_something) or replace the value of the oauth_token parameter?
>>
>> The second option basically returns an authorized token which is used with 
>> the existing secret from 6.1.2. The benefit of a new parameter is it is 
>> easier to follow the protocol. The benefit of reusing oauth_token to make 
>> 6.3.1 is that is keeps the signed request consistent with all other signed 
>> requests (no new parameters).
>>
>> EHL
>>
>> ---
>>
>> Quick Reference
>>
>> 6.1.1.  Consumer Obtains a Request Token
>> 6.1.2.  Service Provider Issues an Unauthorized Request Token
>> 6.2.1.  Consumer Directs the User to the Service Provider
>> 6.2.2.  Service Provider Authenticates the User and Obtains Consent
>> 6.2.3.  Service Provider Directs the User Back to the Consumer
>> 6.3.1.  Consumer Requests an Access Token
>> 6.3.2.  Service Provider Grants an Access Token
>>
>>
>> >
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Hubert Le Van Gong]

I also saw 2 additional ideas that might help
(and are not necessarily exclusive with the 2 proposals):

(3) Make Request tokens one-time only
(4) Request that the user logs in at the Consumer before the request
token request

Are those off the table?
I think (3), although potentially difficult to deploy, would significantly help.
Maybe (3) and (4) could be added in the spec as Best Practice or
Recommendations?

Hubert



On Sun, Apr 26, 2009 at 7:48 AM, Eran Hammer-Lahav  wrote:
>
> Let's see if we can take a quick break from the discussion and get a sense of 
> where we are. Please answer the questions to follow.
>
> ---
>
> We have identified 2 solutions listed here:
>
> https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory
>
>
> * Signed Approval URLs
>
> This proposal breaks the protocol into two separate flows, one for Consumers 
> capable of launching a browser and accepting callbacks, and another for those 
> who can't. It requires a significant rewrite of the specification because of 
> the way the flow and signature are mixed together in the current Core 1.0 
> specification.
>
>
> * Signed Callback URLs
>
> This proposal makes the callback URL part of the signed request for Request 
> Token (which does not allow an attacker to manipulate it), and adds some 
> unpredictable value to the callback redirection that is needed to get an 
> Access Token.
>
> The spec changes include (see quick reference at the bottom):
>
> - Move the oauth_callback parameter from 6.2.1 to 6.1.1
> - Add a new parameter to 6.2.3 which is needed to make 6.3.1
>
> ---
>
> Open questions:
>
> 1. Am I missing a completely different alternative? If yes, please create a 
> new wiki page and point to it (if you don't have access ask or email it to 
> someone who does).
>
> 2. Given the simplicity of the Signed Callback URLs *specification change*, I 
> would like to instead of asking people which solution they prefer, to ask 
> people if they have a strong objection to using the Signed Callback URLs 
> solution, and if so, to explain why?
>
> 3. For the Signed Callback URLs solution, what to call the new parameter 
> returned in 6.2.3? Suggestions so far included:
>
> - pin
> - verifier
> - chaperon
> - callback token
> - callback secret
>
> 4. And, should the new parameter be added to 6.3.1 (oauth_token + 
> oauth_something) or replace the value of the oauth_token parameter?
>
> The second option basically returns an authorized token which is used with 
> the existing secret from 6.1.2. The benefit of a new parameter is it is 
> easier to follow the protocol. The benefit of reusing oauth_token to make 
> 6.3.1 is that is keeps the signed request consistent with all other signed 
> requests (no new parameters).
>
> EHL
>
> ---
>
> Quick Reference
>
> 6.1.1.  Consumer Obtains a Request Token
> 6.1.2.  Service Provider Issues an Unauthorized Request Token
> 6.2.1.  Consumer Directs the User to the Service Provider
> 6.2.2.  Service Provider Authenticates the User and Obtains Consent
> 6.2.3.  Service Provider Directs the User Back to the Consumer
> 6.3.1.  Consumer Requests an Access Token
> 6.3.2.  Service Provider Grants an Access Token
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Dossy Shiobara]

On 4/28/09 1:42 AM, Chris Messina wrote:
> Is OAuth this hard for everyone else?
>
> http://kentbrewster.com/oauth-confessions/
>
> *Sniff*.

Funny enough, I ran into at least a few of the items on his list when 
writing my own OAuth consumer implementation from scratch.

I honestly think that the OAuth _design_ isn't what makes it difficult. 
  It's the way the specification is written.  What really bit me in the 
ass the hardest was the "Parameter Encoding" requirement of the 
signature when using HTTP header authentication.  Deviating from the RFC 
just for OAuth violates POLS, guys.

Honestly, after trying to decipher the spec. and not getting very far, I 
put it aside and went to Eran's GUI:

 http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html

I almost wish I'd not bothered to confuse myself with the spec. and just 
used that one page.  It's a _fantastic_ reference implementation for 
anyone developing their own OAuth consumer.

-- 
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
   "He realized the fastest way to change is to laugh at your own
 folly -- then you can let go and quickly move on." (p. 70)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Blaine Cook]

On Tue, Apr 28, 2009 at 1:18 PM, Dossy Shiobara  wrote:
>
> If and only if the callback URL is protected from tampering.  Since we
> cannot guarantee the consumer secret and request token secret to be ...
> well, secret ... there's no way to guarantee in ALL cases that the
> callback URL will be protected from tampering.

If you can't guarantee the request token secret to be secret, then all
bets are off everywhere. OAuth has been designed such that the request
token secret *is* secret, and in the case of non-redistributed
consumers (e.g., web sites or open source software with a requirement
to obtain a new consumer key/secret), the consumer secret *is* also
secret.

For the callback URL signing case, it is absolutely possible to
guarantee that the request token secret remains private, and therefore
absolutely possible to ensure that the callback URL (and thus, the
verification token) is genuine.

My reading of Eran's proposal doesn't incorporate this level of
signing. That is, I *don't* see a proposal to actually include a
callback signature parameter in the callback URL, as in:

http://example.com/callbackEndpoint?oauth_token=x&oauth_verifier=y&oauth_signature=HMAC-SHA1(oauth_token_secret,
Normalized("http://example.com/callbackEndpoint?oauth_token=x&oauth_verifier=y";))

It might be worthwhile, though, to do that? On the other hand, it
would significantly complicate things, and might not provide a
significant benefit, especially if both the callback URL and the
authorization endpoint were handled over SSL.

b.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: Moving forward

[Dossy Shiobara]

On 4/28/09 12:33 AM, Josh Roesslein wrote:
>
> Couldn't we verify the user on the consumer-side during the callback URL
> redirect (user returning from SP after authorization)?
> This callback URL has two pieces of data:
> - Callback secrete: generated by SP after user authorizes consumer
> - Request token: publicly known, so could be forged by attacker

If and only if the callback URL is protected from tampering.  Since we 
cannot guarantee the consumer secret and request token secret to be ... 
well, secret ... there's no way to guarantee in ALL cases that the 
callback URL will be protected from tampering.

-- 
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
   "He realized the fastest way to change is to laugh at your own
 folly -- then you can let go and quickly move on." (p. 70)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: How should I distinguish between approved or denied authorization?

[J. Adam Moore]

I think you send a 401 error...
http://lmgtfy.com/?q=Error+401

On Apr 27, 11:42 pm, mdub  wrote:
> Section 6.2.3 of the spec says:
>
>   If the User denies access, the Consumer MAY be notified that the
> Request Token
>   has been revoked.
>
> How does one typically indicate, in the authorization callback,
> whether the Request Token was approved or denied?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Paul Lindner]

It wasn't quite that bad..  However I did have a terrible time moving  
OAuth code to production that stumped me for a month.  It turned out  
that the SSL and Host were getting set to the local cluster host  
instead of the load balance external endpoint.

On my second attempt I had OAuth problem reporting working and that  
helped a lot, I was able to see that the URL being used for signature  
calculation was not being set correctly.



On Apr 27, 2009, at 10:42 PM, Chris Messina wrote:

> Is OAuth this hard for everyone else?
>
> http://kentbrewster.com/oauth-confessions/
>
> *Sniff*.
>
> Chris
>
>
> -- 
> Chris Messina
> Open Web Advocate
>
> factoryjoe.com // diso-project.org // openid.net // vidoop.com
> This email is:   [ ] bloggable[X] ask first   [ ] private
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Marc Worrell]

Hi Chris,

Luca's list is good.  Maybe you can add a section how someone could  
start implementing OAuth in his software.  And start the section with  
a small list like Luca's.

Maybe you can add a warning about the problems with url encoding in  
different programming languages.  And supply correct versions.

I like to add that whenever you implement a protocol you have to read  
the spec first, or at least a good summary of the spec. The moment you  
understand the protocol (and also the spec) you can start implementing  
it.  Whilst implementing it you add test cases so that you can  
validate your implementation. That is before you start using the  
protocol to talk to an external party.

 From Kent Brewster's comments I think he didn't read the spec before  
he started trying to implement OAuth.  He also clearly didn't try out  
the published test cases.  My impression is that he didn't have a full  
understanding of the OAuth protocol before implementing it.

Programming any protocol, especially security related protocols, is  
careful work. You need to know what you are doing.  You need to grow  
your software by testing.  You need to understand the protocol  
thoroughly.  That is why programmers use libraries for most protocols.

As protocols go, OAuth is not that hard to implement.  Testing it in a  
live situation is hard though, mostly due to the omission of sensible  
error messages.

What could help OAuth is a better standardization of the error message  
returned. Errors like nonce reuse can then be easily caught and  
reported.

- Marc


On 28 apr 2009, at 09:20, Chris Messina wrote:

> Thanks Luca,
>
> Let me ask this: what else could we be doing to make the "walk up"  
> experience of OAuth easier/better?
>
> I think that the website needs an overhaul (as do most of the Open/ 
> Social Stack sites!!). I'd like to know what we could do to make  
> these sites better — meeting a wider community of practice's needs.
>
> Chris
>
> On Tue, Apr 28, 2009 at 12:13 AM, Luca Mearelli  > wrote:
>
> On Tue, Apr 28, 2009 at 7:42 AM, Chris Messina  > wrote:
> > Is OAuth this hard for everyone else?
> > http://kentbrewster.com/oauth-confessions/
>
> I think that we agree that OAuth *is* complex, and has a few hard
> points (specially about the signing process e.g. the signature base
> string composition) but if we think at what it's trying to do (passing
> authorization around in a three subjects dance across untrusted
> channels) that's understandable.
> These are the things that have helped me (might be banal, might be  
> not...):
>
> - read the spec, try to understand the steps,
> - look at the examples and walkthroughs (specially those at  
> hueniverse.com )
> - look at the examples from the library of your choice (the ruby one  
> in my case)
> - try out with the test providers
> - read the mailing list
>
> Luca
>
>
>
>
>
> -- 
> Chris Messina
> Open Web Advocate
>
> factoryjoe.com // diso-project.org // openid.net // vidoop.com
> This email is:   [ ] bloggable[X] ask first   [ ] private
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Luca Mearelli]

On Tue, Apr 28, 2009 at 9:20 AM, Chris Messina  wrote:
> Thanks Luca,
> Let me ask this: what else could we be doing to make the "walk up"
> experience of OAuth easier/better?

I'd start from the action points here:
http://josephsmarr.com/2009/02/17/implementing-oauth-is-still-too-hard-but-it-doesnt-have-to-be/
And It'd be great to see (on OAuth.net) an "illustrated OAuth" spec (I
found this http://bit.ly/2j5qT very helpful in understanding the OAuth
attack)

Luca

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Chris Messina]

Thanks Luca,
Let me ask this: what else could we be doing to make the "walk up"
experience of OAuth easier/better?

I think that the website needs an overhaul (as do most of the Open/Social
Stack sites!!). I'd like to know what we could do to make these sites better
— meeting a wider community of practice's needs.

Chris

On Tue, Apr 28, 2009 at 12:13 AM, Luca Mearelli wrote:

>
> On Tue, Apr 28, 2009 at 7:42 AM, Chris Messina 
> wrote:
> > Is OAuth this hard for everyone else?
> > http://kentbrewster.com/oauth-confessions/
>
> I think that we agree that OAuth *is* complex, and has a few hard
> points (specially about the signing process e.g. the signature base
> string composition) but if we think at what it's trying to do (passing
> authorization around in a three subjects dance across untrusted
> channels) that's understandable.
> These are the things that have helped me (might be banal, might be not...):
>
> - read the spec, try to understand the steps,
> - look at the examples and walkthroughs (specially those at hueniverse.com)
> - look at the examples from the library of your choice (the ruby one in my
> case)
> - try out with the test providers
> - read the mailing list
>
> Luca
>
> >
>


-- 
Chris Messina
Open Web Advocate

factoryjoe.com // diso-project.org // openid.net // vidoop.com
This email is:   [ ] bloggable[X] ask first   [ ] private

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Luca Mearelli]

On Tue, Apr 28, 2009 at 7:42 AM, Chris Messina  wrote:
> Is OAuth this hard for everyone else?
> http://kentbrewster.com/oauth-confessions/

I think that we agree that OAuth *is* complex, and has a few hard
points (specially about the signing process e.g. the signature base
string composition) but if we think at what it's trying to do (passing
authorization around in a three subjects dance across untrusted
channels) that's understandable.
These are the things that have helped me (might be banal, might be not...):

- read the spec, try to understand the steps,
- look at the examples and walkthroughs (specially those at hueniverse.com )
- look at the examples from the library of your choice (the ruby one in my case)
- try out with the test providers
- read the mailing list

Luca

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---