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 f
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 correlati
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
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 Co
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 withou
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
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 Provid
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
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 w
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 pra
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/o
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
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
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
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 t
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
orde
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 g
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 require
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
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 develop
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 t
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 exchan
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 tha
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 cal
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, whi
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 secu
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 t
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
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
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
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.
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
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).
--~--~-~--~~
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 un
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 worr
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
> playgroun
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 t
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 c
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
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
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 be
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 bein
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 sec
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 h
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
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 princ
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 a
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 a
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
O
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
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 require
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 authori
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 proposa
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 au
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 t
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 wa
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
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
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
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 p
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
>
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
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
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 corr
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-does
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 p
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
67 matches
Mail list logo
