O7Vt%26oauth_token
> %3DYOttwT0ok7CNm8yMYLXA
>
> client.get('/path', access_token)
>
> Oscar
>
> [1] http://gist.github.com/204165
>
> On Oct 7, 5:52 pm, Josh Roesslein wrote:
>> I use the library in my twitter python library. You can view the code
>> for my
x27;s actually working. Do you
> have any code to share or do you know where I can find an example? I
> know about the example in the library itself, but it's not working for
> me.
>
> On Oct 7, 5:54 am, Josh Roesslein wrote:
>> Hi Oscar,
>>
>> The pytho
Hi Oscar,
The python library in the OAuth SVN is 1.0a compliant. I have
successfully used it on Twitter (which uses 1.0a)
without issues. Has your SP implementation been tested with other
OAuth libraries? Perhaps there is a bug in your
SP server code.
Best of luck,
Josh
On Tue, Oct 6, 2009 at
ory at some point since I think it's quite
> useful.
>
> Thanks again,
> Leah
>
>
>
>
>
> On Wed, Aug 12, 2009 at 8:44 PM, Josh Roesslein wrote:
>
>> Hello,
>>
>> I have been working on porting the python-oauth library to python 3.
>> You may vie
An issue has been submitted for this port here -->
http://code.google.com/p/oauth/issues/detail?id=114
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"OAuth" group.
To post to this group, send email to oauth@googlegr
rsion.
If anyone spots any bugs please let me know.
Josh Roesslein
--~--~-~--~~~---~--~~
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 f
On Tue, Jun 23, 2009 at 10:48 AM, ngw wrote:
>
> Hi *, I'm trying to figure out how to implement OAuth for my own site,
> and something is still not completely clear.
> For example, I need to authenticate a certain class of users (site
> administrators) for a management interface. These users can
h or fork this version for updates.
>
> Sorry for the inconvenience!
> Leah
>
>
> On Wed, Jun 3, 2009 at 2:58 PM, Leah Culver wrote:
>
>> Arg! I keep forgetting to update that. I might actually re-import it from
>> SVN soon because it's only a subdirectory.
>
Will these changes be pushed to your github mirror? I've got a forked copy
of the library I'd like to pull these
updates. Otherwise I'll just use the google svn for updates.
On Wed, Jun 3, 2009 at 4:06 PM, Leah Culver wrote:
> I've applied your patch now. Thanks for your help!
>
> http://code.go
Brian,
What I meant is if we leave the request token request unmodified (which is
what he is suggesting), we would have to change the version for the SP to
detect our flow.
Otherwise how will the SP know if it needs to send a verifier on the
callback? To the SP request token requests look the same
t; Good point. This alternate solution is less backward compatible.
>
> On May 5, 2009 7:15 PM, "Josh Roesslein" wrote:
>
> One issue that arises is now the SP has no way to tell if we are using 1.0
> old flow or the new flow.The SP will not know which one is being used un
One issue that arises is now the SP has no way to tell if we are using 1.0
old flow or the new flow.The SP will not know which one is being used until
the consumer asks for the access token. So how will we know if the callback
should use the old flow's format or the new flow w/ verifier?
We would
A simple way to block this attack would be to force the user to login each
time before displaying the approval page (even if there is a SP session
cookie). This way the attacker
can not load the approval page in a frame. They would need the password to
do so. This does impact the user experience a
> super strongly about this, but I know for a fact it will make the libraries
> more complex and inconsistent if this one use case takes an extra param that
> none of the other (otherwise identical) invocations need...
>
> Thanks, js
> On Sat, May 2, 2009 at 10:32 AM, Josh Roessl
No, 3 legged consumers can't use the old spec safely, but 2 legged consumers
are not affected so they don't need to upgrade for changes that they don't
even use. This is what we mean by backward compatiblity. We still want to
support 2 legged consumers who are using the same code. If we incremented
1.) Yes this is a small window for an attacker to pull off a session
fixation, but I think it should still be closed. It just takes one
successful attack to make oauth look insecure.
It might be possible for this parameter to be optional for the SP
(banks might want to use this, but less sens
Not to get off topic here, but it might actually be a good idea to
devalidate any access tokens when the SP changes to the new spec.
The reason for this is the make sure attackers that might have used the
session fixation attack prior to the fix no longer have a valid token.
Sure the user will have
I agree that we should all get to voice our ideas, but using a voting system
wouldn't work. I agree with a "moderated" approach where core members do
oversee the final decision, but they should also listen to the community.
Otherwise they will just push them away and the protocol will die off. Like
Well let's just name the spec something else from the protocol version and
focus on what's important here which is finalizing the draft so
we can begin applying the updating to libraries.
On Fri, May 1, 2009 at 3:44 PM, Jonathan Sergent wrote:
> Let me additionally say that this discussion is da
Here's a quick count of the votes:
Option 1: 8
Option 3: 12
Eran has made some good points in another thread. In this revision we can
auto detect which from we are using, but in the future this might not be
true.
So do we create different versions?
Wire version - only incremented if we can't aut
First I believe the version number should increment when ever the spec
changes. To me this clearly provides the SP with the version of the spec
this consumer is running.
Now the SP can properly determine if the requests from this consumer should
work.
Now how do we determine backward compatibility
Option 3 - spec is changing and 1.0 needs to die. RIP
--~--~-~--~~~---~--~~
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 ema
Actually I kind of like "none", but that might just be the python talking in
me. "none" might make it more clear the parameter isn't used, but I would be
fine with "oob".
On Thu, Apr 30, 2009 at 11:49 PM, Brian Slesinsky wrote:
>
> For what it's worth, this draft looks good to me.
>
> Agreed that
How will calling this 1.1 slow down the upgrade process? All libraries need
to change to cover the new spec, so it doesn't matter what we call it.
SP's can still support older clients by running 1.0 and 1.1 specs. This
allows for older clients to perform upgrades to 1.1 before cutting them off.
SP
I hope we decide to name the new spec 1.1. I'm not a fan of these sub-minor
letter versions.
This is a decent sized change and 1.0 is over 1 year old. I think it's time
we moved the minor version.
On Thu, Apr 30, 2009 at 8:26 PM, David Parry wrote:
>
> seriously, I don't understand the reluctanc
Yeah I don't think that is a good way for a developer to find they need to
upgrade.
They should be watching the SP's API mailing list, blog, etc for the change
alert and update before the switch happens.
It should be optionally if the SP wants to report error messages in their
400's this is somethi
The consumer's developer will quickly find out they need to upgrade when
their users starting complaining its not working.
It's probably also a good idea for SPs to give their consumers a heads up
that they are closing support for the old 1.0 spec.
On Thu, Apr 30, 2009 at 7:59 PM, David Parry wro
Dirk,
I see now what you are getting at. Yes I guess the SP could use a signature
to generate the verifier, so it would not need to persist it.
As long as the signature secrete changes ever so often, I don't think an
attacker could compromise this method. But to me the wording of that section
stil
To me this wording makes sense.
Basically it's saying the verification code the consumer submits to exchange
for an access token must match the verifier the SP generated for the
callback.
This verifies the user returning to the consumer is the same user who
authorized the consumer on the SP.
The
pplication that the step
>> is complete there's no way of the application knowing which request token
>> was authorised and must have a link between the user and request token prior
>> to sending the user to the authorisation url?
>>
>> or am I missing something.
nformation. Only reason to
implement your own
would be for an unsupported database.
Example:
oauth.client.set_datastore(oauth.client.MysqlDatastore(user='oauth_user',
pass='password', database='oauth'))
On Thu, Apr 30, 2009 at 3:25 PM, Mike Malone wrote:
> On Th
I'm glad this would annoy them, maybe they would do it properly. I don't see
how they can put their own request token. They would have to manually
construct the
request token and authorization requests which is a lot of extra work and
they are by passing the library and doing their own implementati
Maybe the spec should have a section on "Implementation Guidelines" and
sub-sections for both SPs and consumers.
On Thu, Apr 30, 2009 at 2:00 PM, Luca Mearelli wrote:
>
> On Thu, Apr 30, 2009 at 7:55 PM, Blaine Cook wrote:
> > In cases where callbacks are not supported, there should never be the
sse Myers wrote:
>
>>
>> Doesn't the consumer still need to store the secret for the request
>> token to sign the access token exchange? I didn't think the request
>> token secret was in the callback.
>>
>> On Thu, Apr 30, 2009 at 11:37 AM, Josh Roesslein
secret for the request
> token to sign the access token exchange? I didn't think the request
> token secret was in the callback.
>
> On Thu, Apr 30, 2009 at 11:37 AM, Josh Roesslein
> wrote:
> > The consumer should not be persisting the request token anyways. With the
&
The consumer should not be persisting the request token anyways. With the
new spec the request token will be returned in the callback along with the
oauth_verifier.
Now the client call call the library to fetch the access token (ex.
get_access_token(oauth_token, oauth_verifier)) and it returns back
SP's could run both version at the same time to allow consumer time to
upgrade to the new spec.
The version being used can be detected with the oauth_version parameter.
On Thu, Apr 30, 2009 at 1:22 PM, Blaine Cook wrote:
>
> On Thu, Apr 30, 2009 at 7:08 PM, Mike Malone wrote:
> > I don't know,
A good library should hide the request token from the developer. They should
simply call a function to generate the authorization URL (ex.
get_auth_url()) and
display that to the user. This way they never get the token and can't really
bind it (library should also state this in its docs).
I agree
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
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
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
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 for
with anyone except the consumer (probably a device / desktop application in
this case). To add extra security the callback could use https
to prevent man in the middle attacks and to verify the identity of the
consumer.
On Sun, Apr 26, 2009 at 2:30 PM, pkeane wrote:
>
>
>
> On Apr 26, 2
Peter, no it does not verify it is the same user who requested the request
token. But it does verify the user did authenticate with the SP.
The consumer can only exchange it's request token for an access token if it
receives the callback secrete from the user. The only way
this value can be known i
1. I don't have really any other alternatives to suggest.
2. I am for the signed callback URL solution.
3. First to decide if it's a token or a secrete. This value should not be
shared so I'm leaning toward secrete.
The name of the secrete should symbolize its purpose. We are using the
secrete
at 9:20 PM, John Kristian wrote:
>
> Some desktop consumers can receive a callback, and want to use it to
> improve the user's experience.
>
> On Apr 25, 6:03 pm, Josh Roesslein wrote:
> > I'm guessing you are referring to desktop-based consumers. Yes it is
> >
Re: OAuth Security Advisory
>
>
>
> How would attackers be able to inject a callback w/o having access to
> the consumer secret?
>
>
> On Apr 25, 3:46 pm, Josh Roesslein wrote:
> > Zack, very good points. We have been probably over thinking this a bit
> and
> &g
o
> the consumer secret?
>
>
> On Apr 25, 3:46 pm, Josh Roesslein wrote:
> > Zack, very good points. We have been probably over thinking this a bit
> and
> > have gotten off topic.
> >
> > Our focus should be:
> >
> > + Secure the callback in
t; > > > I can just Google my mother's maiden name to reset my password when
> > > > that fails. If a system is designed to work only by relying upon
> > > > people to not be stupid it will fail. You can't outwit a fool; only
> > > > fools try.
awed, but why change
> > OAuth when it works just fine? Remember, the problem we are facing is
> > still theoretical and the solution I proposed doesn't break anyones
> > current or past work or understanding.
> >
> > On Apr 25, 1:33 pm, Josh Roesslein wrote:
> >
&
o a minor tweak to the
> existing spec, rather than define an entirely new flow, even if the new
> RequestToken-less flow is essentially the same as what many proprietary
> auths have been doing for years.
>
> Allen
>
>
> Josh Roesslein wrote:
>
> Yes it eliminates th
that can't run a web browser. Sorry if I confused
> the case we were talking about.
>
> On Sat, Apr 25, 2009 at 1:43 PM, Josh Roesslein
> wrote:
> > How can the attacker use that flow? He can't set a callback in that URL
> > since it can't be signed by him u
here is
no default callback, the provider just displays the token for the user to
manually enter.
On Sat, Apr 25, 2009 at 3:39 PM, Jonathan Sergent wrote:
>
> On Sat, Apr 25, 2009 at 1:38 PM, Josh Roesslein
> wrote:
> > As for the timing to apply this change, I think it would be worth
k URL signing and
limiting request token swapping to one try should be enough to stop the
session fixation.
On Sat, Apr 25, 2009 at 3:35 PM, Josh Roesslein wrote:
> Well this callback is short lived since it is swapped by the consumer
> almost right away. So you don't have much time f
The only place that a phishing attack would occur in the signed
authorization proposal is the authorization URL.
An attacker could lure an user to click on a link that directs the user to a
clone of the provider and steal the users credentials
when logging in. The best way to prevent this is users
nd no longer useful.
On Sat, Apr 25, 2009 at 3:30 PM, Brian Eaton wrote:
>
> On Sat, Apr 25, 2009 at 1:04 PM, Brian Eaton wrote:
> > On Sat, Apr 25, 2009 at 12:26 PM, Josh Roesslein
> wrote:
> >> Thanks for posting that Brian.
> >>
> >> I'm leaning to
:26 PM, Josh Roesslein
> wrote:
> > Thanks for posting that Brian.
> >
> > I'm leaning towards signed approval URLs. Seems the best way to go IMO.
> > Seems to solve the issues and also helps simplify the OAuth flow.
>
> The major pain point of signed appro
.
>
> On Apr 25, 1:01 pm, Josh Roesslein wrote:
> > I am not suggesting changing the entire spec, just dropping the request
> > token part.
> >
> > This is what I'm getting at -->
> https://oauth.pbwiki.com/Signed-Approval-URLs
> >
> > On Sat, Apr
gt; are trying to associate with. This also leaves sites able to craft
> > > their redirect urls to contain either unique paths or unique tokens or
> > > both without breaking the protocol or damaging the current information
> > > exchange model. I still favor a solution
Thanks for posting that Brian.
I'm leaning towards signed approval URLs. Seems the best way to go IMO.
Seems to solve the issues and also helps simplify the OAuth flow.
On Sat, Apr 25, 2009 at 2:09 PM, Brian Eaton wrote:
>
> On Sat, Apr 25, 2009 at 10:46 AM, Chris Messina
> wrote:
> > I'd like
gt; like man in the middle or DNS or url tampering and allows secure token
> generation based on session authentication, which, when employed
> properly, cannot be spoofed from either end or the middle.
>
> On Apr 25, 11:21 am, Josh Roesslein wrote:
> > I don't really see the need f
I don't really see the need for the double trip to the service provider to
perform the login and authorization.
This can be done in one single step like I have outlined in my proposal.
User logs into provider, grants access, and returns back with the token.
The less work we do in our flow the less
I still don't think passing session information through oauth for the
callback is a good thing. You could simply set a cookie in the browser if
you are a site
to hold any information you will need on the callback. Example: storing the
URL of the page the user was last on. Maybe we could add a param
I guess you could say the flow I proposed is a one token exchange. There is
only the access token that is returned back to the consumer
from the authorization callback.
As for the whole callback parameter, I don't like it at all. I see it as bad
practice of dynamically setting this URL.
It should
So just to clear it up, our token flow would be:
Get request token and direct user to service provider --> Authorize consumer
and generate authorization token --> Consumer swaps authorization token for
an access token
On Fri, Apr 24, 2009 at 11:31 PM, Josh Roesslein wrote:
> I believe
I believe this has been presented in a previous message.
Instead of calling this "special value" a callback nonce it would probably
better to call it a "authorization token".
This way we don't get it mixed up with the oauth_nonce used to prevent
replay.
This would prevent session fixation and by
Yes it eliminates the request token and basically skips to step D. I don't
really see the need for request tokens.
We can just direct the user to the service provider's URL for the consumer,
authenticate, and return the access token in the callback.
in the callback that is given when the consumer w
67 matches
Mail list logo
