[oauth] Re: Client example in python using oauth 1.0a

[Josh Roesslein]

>From the code at line 37, I believe you should be using self.authority
instead of self.host.
You must include the port unless it is 80 or 443 (section 9.1.2).
If the server is using a different base string then that would cause
the signature not matching.
Make sure the URLs are the same both for the client and server.

If I notice anything else I'll let you know.

Josh

On Wed, Oct 7, 2009 at 11:14 AM, Oscar Del Ben  wrote:
>
> I'll try your code tomorrow.
>
> Anyways, this is what I use [1]. The problem seems to be when I get or
> post to the server with the access token because the server can't
> validate the request. In particular it doesn't match the signature.
>
> What I would do is this:
>
> access_token = web.cookies().get('access_token') // oauth_token_secret
> %3D2Df6x2SrJMgKYFtgTCT2d8As8GvGvIM8kZZAO7Vt%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 oauth handler here [1].
>> The code is pretty simple. The apply_auth method is where I build the
>> headers for the resource
>> request. Let me know if you have any questions.
>>
>> If you could post a link to your client code using the library I could
>> offer to look at it.
>>
>> Josh
>>
>> [1]http://github.com/joshthecoder/tweepy/blob/master/tweepy/auth.py
>>
>> On Wed, Oct 7, 2009 at 2:10 AM, Oscar Del Ben  wrote:
>>
>>
>>
>>
>>
>>
>>
>> > Hi Josh and thanks for your reply. Our SP is currently used by another
>> > client application written in ruby and it'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 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 8:04 AM, Oscar Del Ben  
>> >> wrote:
>>
>> >> > Hi, I'm using the module oauth which can be found at
>> >> >http://oauth.googlecode.com/svn/code/python/oauth/tobuild a simple
>> >> > client we built. The problem is that I'm not sure if that library
>> >> > support oauth 1.0a
>>
>> >> > I used the example 
>> >> > athttp://apiwiki.justin.tv/mediawiki/index.php/Justin.tv_Python_Client_...
>> >> > to develop a first version of my client and I am able to get an access
>> >> > token back from the provider, however when I try to access private
>> >> > data my request does not pass the signature control.
>>
>> >> > Since I am in control of the provider server (which is not built in
>> >> > python) I have tried to figure out what was happening but without any
>> >> > result and I would like to know if someone knows of a simple oauth
>> >> > client 1.0a that I can use in my python application.
>>
>> >> > Many thanks,
>>
>> >> > Oscar
>>
>> --
>> Josh
> >
>

--~--~-~--~~~---~--~~
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: Client example in python using oauth 1.0a

[Josh Roesslein]

I use the library in my twitter python library. You can view the code
for my oauth handler here [1].
The code is pretty simple. The apply_auth method is where I build the
headers for the resource
request. Let me know if you have any questions.

If you could post a link to your client code using the library I could
offer to look at it.

Josh

[1] http://github.com/joshthecoder/tweepy/blob/master/tweepy/auth.py

On Wed, Oct 7, 2009 at 2:10 AM, Oscar Del Ben  wrote:
>
> Hi Josh and thanks for your reply. Our SP is currently used by another
> client application written in ruby and it'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 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 8:04 AM, Oscar Del Ben  wrote:
>>
>>
>>
>>
>>
>> > Hi, I'm using the module oauth which can be found at
>> >http://oauth.googlecode.com/svn/code/python/oauth/to build a simple
>> > client we built. The problem is that I'm not sure if that library
>> > support oauth 1.0a
>>
>> > I used the example 
>> > athttp://apiwiki.justin.tv/mediawiki/index.php/Justin.tv_Python_Client_...
>> > to develop a first version of my client and I am able to get an access
>> > token back from the provider, however when I try to access private
>> > data my request does not pass the signature control.
>>
>> > Since I am in control of the provider server (which is not built in
>> > python) I have tried to figure out what was happening but without any
>> > result and I would like to know if someone knows of a simple oauth
>> > client 1.0a that I can use in my python application.
>>
>> > Many thanks,
>>
>> > Oscar
> >
>



-- 
Josh

--~--~-~--~~~---~--~~
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: Client example in python using oauth 1.0a

[Josh Roesslein]

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 8:04 AM, Oscar Del Ben  wrote:
>
> Hi, I'm using the module oauth which can be found at
> http://oauth.googlecode.com/svn/code/python/oauth/ to build a simple
> client we built. The problem is that I'm not sure if that library
> support oauth 1.0a
>
> I used the example at 
> http://apiwiki.justin.tv/mediawiki/index.php/Justin.tv_Python_Client_Library
> to develop a first version of my client and I am able to get an access
> token back from the provider, however when I try to access private
> data my request does not pass the signature control.
>
> Since I am in control of the provider server (which is not built in
> python) I have tried to figure out what was happening but without any
> result and I would like to know if someone knows of a simple oauth
> client 1.0a that I can use in my python application.
>
> Many thanks,
>
> Oscar
>
> >
>

--~--~-~--~~~---~--~~
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: Python 3 port of python-oauth library ready for review.

[Josh Roesslein]

>From what I have seen is that most libraries fork off the python 3 port into
its own branch.
They then push updates from their python 2 branch into python 3 performing
any
porting needed to make it python 3 compatible. If anyone else is doing this
a different way I'm
open to suggestions.

On Thu, Aug 13, 2009 at 2:03 PM, Leah Culver  wrote:

> Hey Josh,
>
> Thanks so much!!
>
> I see that the changes for Python 3.x are fairly superficial. However, it's
> also unlikely that someone would want the library to work for both 2.x and
> 3.x so I'm unsure where the 3.x version should go.
>
> What are other python libraries doing?
>
> I'm pretty indifferent where we put the "python3k" library so I'm up for
> doing what everyone else is doing. However, we should get this in the
> official Google Code repository 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 view the code at
>> http://github.com/joshthecoder/python-oauth/tree/py3k
>> Here is also a diff between the latest version of the 2.x library and the
>> 3.x port: http://pastebin.com/f617e7304
>>
>> Since these two branches may never merge I'm guessing this version will
>> get its own
>> directory in /code/python. Perhaps we'd have /code/python/oauth and
>> /code/python/oauthpy3k
>> I am willing to help maintain this port and merge any changes from the 2.x
>> version into this one
>> if Leah wants to just focus on the 2.x version.
>>
>> If anyone spots any bugs please let me know.
>>
>> Josh Roesslein
>>
>>
>>
>
> >
>


-- 
Josh

--~--~-~--~~~---~--~~
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: Python 3 port of python-oauth library ready for review.

[Josh Roesslein]

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@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] Python 3 port of python-oauth library ready for review.

[Josh Roesslein]

Hello,

I have been working on porting the python-oauth library to python 3.
You may view the code at
http://github.com/joshthecoder/python-oauth/tree/py3k
Here is also a diff between the latest version of the 2.x library and the
3.x port: http://pastebin.com/f617e7304

Since these two branches may never merge I'm guessing this version will get
its own
directory in /code/python. Perhaps we'd have /code/python/oauth and
/code/python/oauthpy3k
I am willing to help maintain this port and merge any changes from the 2.x
version into this one
if Leah wants to just focus on the 2.x version.

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 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: Oauth for 2 legged services

[Josh Roesslein]

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 see every
> kind of data and have read/write permissions on basically everything.
> Obviously, authentication and authorization is critical.
> This interface should basically authenticate against the main site
> with username and password and check for a given flag.
>
> If I understood OAuth correctly the workflow is
> 1) The user points to foo.bar.com
> 2) foo.bar.com contacts bar.com and asks the user to login in case the
> user isn't
> 3) in case the credentials are right bar.com asks the user if the
> application foo.bar.com can use his data, in case the credentials are
> wrong the user is redirected to a bar.com page
> 4) foo.bar.com queries the account of the user and checks if he is an
> administrator
>

What you describe here is a three legged flow. The two legged flow does not
perform an user
authentication with the SP. Instead we are just authenticating the consumer
with the SP. This consumer can represent
a single user or many, but to the SP its just one user. The consumer
authenticates with the SP by signing each
request with its shared secrete. The SP detects a two legged request by the
missing access token. It must then
verify the signature and identify the "user" by the consumer token. Two
legged is a good approach to use for instances where you don't care who the
user is or if the consumer is just a single user (ex. desktop app).


> Another question I have is what happens when the user connects after
> some time, is he already authenticated or it's just a matter to set
> some kind of expiration time for the token ?


With two legged the session would remain open until the SP disables the
consumer's secrete.
With three legged its up to the SP when to expire the access token.

I hope this helps clear things up for you. Good luck.

Josh

--~--~-~--~~~---~--~~
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: oauth.py: escape arguments before sorting

[Josh Roesslein]

Awesome. Thanks Leah for getting that updated.

On Thu, Jun 4, 2009 at 1:38 PM, Leah Culver  wrote:

> Since the python-oauth library on GitHub was taken from svn at the wrong
> directory level, I've renamed that repo python-oauth-old and created a new
> python-oauth. Please watch 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.
>>
>> Leah
>>
>>
>> On Wed, Jun 3, 2009 at 2:55 PM, Josh Roesslein wrote:
>>
>>> 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.google.com/p/oauth/source/detail?r=1041
>>>>
>>>> Leah
>>>>
>>>>
>>>> On Tue, Jun 2, 2009 at 3:54 PM, Leah Culver wrote:
>>>>
>>>>> Hi Arjan,
>>>>>
>>>>> Thanks for the patch. I'll try to get to it soon!
>>>>>
>>>>> Leah
>>>>>
>>>>>
>>>>> On Wed, May 27, 2009 at 3:34 AM, Arjan Scherpenisse <
>>>>> ar...@scherpenisse.net> wrote:
>>>>>
>>>>>> -BEGIN PGP SIGNED MESSAGE-
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> About a month ago I came across an issue in the python implementation
>>>>>> of
>>>>>> OAuth: while calculating the signature base string, the request
>>>>>> parameters need to be escaped before they are sorted.
>>>>>>
>>>>>> This only happens when using "exotic" argument names containing
>>>>>> characters that need escaping.
>>>>>>
>>>>>> I wrote a patch for it, maybe one of you can have a look at it.
>>>>>>
>>>>>> Thanks
>>>>>> Arjan Scherpenisse
>>>>>> - --
>>>>>> Mediamatic Lab  -  Vijzelstraat 72 - 1017 HL Amsterdam - Netherlands
>>>>>> t+31 (0)20 638 9901 - f+31 (0)20 638 7969 - http://www.mediamatic.nl
>>>>>> -BEGIN PGP SIGNATURE-
>>>>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>>>>>
>>>>>> iEYEARECAAYFAkodFykACgkQigE4AbflYeqPUACcC1DwKIRWfk3faf1qT5umAQrY
>>>>>> g3gAn1ovFBaMRopPsDSux60HFO2eVlEx
>>>>>> =1blH
>>>>>> -END PGP SIGNATURE-
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: oauth.py: escape arguments before sorting

[Josh Roesslein]

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.google.com/p/oauth/source/detail?r=1041
>
> Leah
>
>
> On Tue, Jun 2, 2009 at 3:54 PM, Leah Culver  wrote:
>
>> Hi Arjan,
>>
>> Thanks for the patch. I'll try to get to it soon!
>>
>> Leah
>>
>>
>> On Wed, May 27, 2009 at 3:34 AM, Arjan Scherpenisse <
>> ar...@scherpenisse.net> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Hi,
>>>
>>> About a month ago I came across an issue in the python implementation of
>>> OAuth: while calculating the signature base string, the request
>>> parameters need to be escaped before they are sorted.
>>>
>>> This only happens when using "exotic" argument names containing
>>> characters that need escaping.
>>>
>>> I wrote a patch for it, maybe one of you can have a look at it.
>>>
>>> Thanks
>>> Arjan Scherpenisse
>>> - --
>>> Mediamatic Lab  -  Vijzelstraat 72 - 1017 HL Amsterdam - Netherlands
>>> t+31 (0)20 638 9901 - f+31 (0)20 638 7969 - http://www.mediamatic.nl
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>>
>>> iEYEARECAAYFAkodFykACgkQigE4AbflYeqPUACcC1DwKIRWfk3faf1qT5umAQrY
>>> g3gAn1ovFBaMRopPsDSux60HFO2eVlEx
>>> =1blH
>>> -END PGP SIGNATURE-
>>>
>>>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: Confirm callback when getting access token

[Josh Roesslein]

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 for both 1.0 and
1.0A if they are left untouched.
I was just pointing out we need a way to still tell the SP during the
request token step which flow we will use.

On Tue, May 5, 2009 at 11:34 PM, Manger, James H <
james.h.man...@team.telstra.com> wrote:

> [Breno said]
> > The request token can be stored in a cookie or some other parameter
> > that provides XSRF protection vis-a-vis the callback URL. This allows
> > the consumer to remain stateless by doing the right thing.
>
> > James, you made the best argument (in my view) of why we should stick
> with
> > the existing proposal, namely that the easiest way to preserve
> > statelessness is to implement a measure that results in XSRF protection
> > side effects.
>
>
> This is a curious side-effect -- but not a great basis for protocol design.
> Only consumer apps that take the effort to be stateless get CSRF protection.
> It requires clients to support cookies. It assumes other CSRF defences
> cannot be sufficient (eg using Referer or Origin HTTP headers).
>
>
> I would prefer to fix OAuth security issue 2009-1 without unnecessarily
> preventing state-management options that previously worked, and without
> requiring cookies where they were not previously necessary.
>
>
> Separately, we should write advice for all OAuth consumers about
> implementing CSRF defences. I assume the issue is "Login CSRF" -- where a
> victim is "logged in" to the consumer as the attacker [in OAuth, a victim is
> using a consumer that is accessing a service provider on behalf of an
> attacker].
>
>
> >> My guess is that it would require very substantial changes to
> >> a Consumer App’s architecture if it had to switch from a stateless to a
> >> statefull mode to support a security fix.
>
> > There is no need for such radical changes as described above.
>
> Are you sure that the alternative ways to implement statelessness (other
> than encoding state into the callback) are viable in all situations, and
> will remain so in the future?
> Even if that was true, do we have to force consumers to switch how they
> implement statelessness?
>
>
> --
> CSRF = XSRF = cross-site request forgery
>
> >
>

--~--~-~--~~~---~--~~
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: Confirm callback when getting access token

[Josh Roesslein]

One way around the issue of incrementing oauth_version is for the SP to see
it as a "minimum required version for this endpoint" rather than enforcing
one version requirement across all endpoints. By allowing for different
minimum required versions for each endpoints, we can maintain backward
compatibility while
still being able to increment the oauth_version. The SP can decide which
oauth version to support for each endpoint.
For the session fixation fix SPs can continue allowing 1.0 versions on
resource requests since we are not chaging this part of the spec. Two legged
consumers would not be broken and the SP can tell which flow is being used
when it might not be obvious.

I was going suggest this in a seperate thread, but since this idea is
blocked on this issue, I thought it would be relevent to suggest here.

On Tue, May 5, 2009 at 9:29 PM, Breno de Medeiros  wrote:

> 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 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 either have to increment the wire version OR the SP would have to
> use different end points for the two flows.
>
> example: http://www.test.com/oauth/1.0a OR 1.0/request
>
>  On Tue, May 5, 2009 at 9:06 PM, Manger, James H <
> james.h.man...@team.telstra.com> wrote: > > [I sa...
>
>
> >
>

--~--~-~--~~~---~--~~
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: Confirm callback when getting access token

[Josh Roesslein]

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 either have to increment the wire version OR the SP would have to
use different end points for the two flows.

example: http://www.test.com/oauth/1.0a OR 1.0/request

On Tue, May 5, 2009 at 9:06 PM, Manger, James H <
james.h.man...@team.telstra.com> wrote:

> [I said]
> >> An advantage of this approach for the Service Provider is that there is
> >> no extra state that has to be maintained between the Request Token and
> >> Authorization steps so the SP’s Request Token format should not need to
> >> change to maintain stateless operation.
>
> [Breno replied]
> > This does not have to change. The SP can encode the callback URL in
> > the request token itself.
>
> This is a change to the SPs tokens. It can be done, but it is an extra
> change and it might raise some awkward issues. I assume current tokens
> encode consumer ids, scopes, times etc that are shortish, fixed length, and
> chosen by the SP.
> Encoding a whole callback URI feels a bit different. The consumer chooses
> the callback. It might be long. The whole URI needs to be encoded as the
> whole URI is needed during the authorization step so the user can be
> redirected there.
>
> [The authorization URI shouldn't be much longer: the callback URI just
> moves from an oauth_callback parameter into the oauth_token parameter
> (assuming efficient encoding by the SP)]
>
>
> The whole callback URI does not need to be encoded to remember it between
> the authorization and access token steps. It is sufficient to remember a
> fixed-length hash of the callback URI. Consequently, an SP can use a fixed
> length "verifier" to encode the state they need to check the callback URI in
> the access token step.
>
>
>
> James Manger
> james.h.man...@team.telstra.com
> Identity and security team — Chief Technology Office — Telstra
>
> >
>

--~--~-~--~~~---~--~~
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: Clickjacking & OAuth

[Josh Roesslein]

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 bit, but does solve the issue
100% unless I over looked something.

On Mon, May 4, 2009 at 7:43 PM, Stephen Sclafani wrote:

>
> Allen,
>
> You are correct about the security attribute being able to disable
> frame busting scripts in IE. IE8 supports a X-Frame-Options HTTP
> response header which can be used by a developer to deny their
> approval page from rendering in a frame. However IE8 is not currently
> widely used. Even requiring that javascript be enabled is not a
> perfect solution. In my conversation with Google's security team they
> informed me that they were going to add frame busting javascript
> (which they have done) and possibly add the X-Frame-Options header. I
> think that this is the best a service provider can hope to do at this
> point. There really is no 100% solution.
>
> Stephen Sclafani
>
> On May 4, 4:15 pm, Allen Tom  wrote:
> > Hi Stephen,
> >
> > Thanks for pointing this out. It might not be sufficient to deploy only
> > Framebusting JS on the approval screens, as the attacker can disable JS
> > for the iframe in IE by setting the security attribute to "restricted"
> >
> > http://msdn.microsoft.com/en-us/library/ms534622(VS.85).aspx
> >
> > SPs may need to deploy Framebusting JS AND require that JS is enabled
> > for users to approve the Access Token, otherwise the attacker could
> > embed the approval screen in an iframe with JS disabled.
> >
> > Allen
> >
> > Stephen Sclafani wrote:
> > > There has been much discussion over the session fixation vulnerability
> > > since it was announced publicly. There is another issue that is not
> > > unique to OAuth but one that I believe poses an equal if not more
> > > serious threat to service providers. That issue is clickjacking.
> >
> > > For those unfamiliar with clickjacking, it is when a visitor to a web
> > > page is tricked into clicking on an element that they believe to be
> > > harmless when in reality they are clicking on an element on a
> > > different website that exposes protected data or grants an attacker
> > > access. A malicious consumer developer can use a clickjacking attack
> > > against a vulnerable service provider's approval page to trick users
> > > into granting their application access.
> >
> > > Current service providers have been notified. Google, Yahoo and
> > > Twitter have already deployed protection. I have written a blog post
> > > that goes into greater detail on the threat which can be read here:
> >
> > >http://stephensclafani.com/2009/05/04/clickjacking-oauth/
> >
> > > Stephen Sclafani
> >
>

--~--~-~--~~~---~--~~
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: OAuth Core 1.0 Rev A, Draft 1

[Josh Roesslein]

1.) Well we should really not use a three legged approach for these devices.
Reason: these consumers are not going to have multiple users. I suggest
  a two legged approach instead.

2.) I don't see it as a hack. We are telling the SP "hey, we don't want to
use a callback". This parameter is required, so we must still include it.

3.) The SP still needs to break them up to look up the record in the DB. We
can't use the combined value as the key. If we use this combined value as
the key, we can not
 block brute force attacks for guessing the verifier. We need to limit
the number of times a request token can be swapped. If the consumer gives us
a bad token+verifier,
 we don't have a valid key. We would have to split the token and
verifier and use the token as the key.

 Sure we can still make this idea of token+verifier work, but it just
seems like a hack to save some time. To me this seems like a hours work at
most to add another
 parameter to the access token request.

On Sat, May 2, 2009 at 3:27 PM, Joseph Smarr  wrote:

> For 1), the community needs to make a concious decision to turn our backs
> on a set of use cases for devices that can't take direct input. These
> include "smart picture frames" that come with a pre-generated request token
> on a piece of paper and instructions to go activate them (e.g. so you can
> give your parents a picture frame that shows your private picasa photos) and
> smart medical bracelets that connect to Google Health or similar services.
> This also includes things like the Roku box or other set-top boxes that
> don't have keyboard input. These are all real and useful cases that OAuth
> 1.0 supports, and I don't think we should break them capriciously. If the
> authorization page makes the user type in a manual token, it can provide
> extra warning messages like "Make sure you got this directly from the device
> you're authorizing", which I think is above threshold for a secure and
> workable model. Can others chime in who feel strongly one way or the other
> here?
>
> For 2) the only way to tell 1.0 from 1.0A-with-no-callback is to use the
> special oob/none value. If we can't do better than this, so be it, but
> special values feel like a hack at best, so I'm hoping we can come up with
> some creative alternative that would allow the callback param to be motted
> entirely and still be able to tell 1.0 from 1.0a without explicit version
> numbers.
>
> For 3) the only requirement is for the SP to reconstruct the signature, so
> appending two tokens is no harder than appending an extra name/value pair
> when computing the signature. After the SP generates the verifier, it could
> store the token+verifier as the key to look up when granting an access
> token, and thus it wouldn't need to break them back up later. I don't feel
> 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 Roesslein wrote:
>
>> 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 sensitive data sites might not need
>> this extra security).
>> 2.) We can tell during the request token request if this is a 1.0 A or 1.0
>> consumer. If no callback parameter is present, its 1.0. 1.0 A consumers must
>> still set this
>>   parameter even if they are not setting a callback (oob, none, etc).
>> 3.) I don't really like this combining of the tokens. We'll have to
>> disjoin them on the SP to verify. I don't think it will be much of a deal
>> changing the signature code to make
>>  this work.
>>
>>
>> On Sat, May 2, 2009 at 12:01 PM, Joseph Smarr  wrote:
>>
>>> Erna-just getting to a detailed review of the diff now. Generally it
>>> looks good but here are a couple of things I think we should change:
>>>
>>> 1) If no oauth_token is provided on the authorization URL in 6.2.1 (e.g.
>>> the mobile/device case where the Consumer is unable to open a web browser
>>> directly), then I don't think the Provider should return an oauth_verifier
>>> to be enterered into the Consumer. Basically I'm suggesting we stick to
>>> OAuth 1.0 here, and the reasons are: a) the attack we're patching is much
>>> harder to pull off if 

[oauth] Re: POLL: Can an SP safely allow any Consumer to use the current 1.0 securely?

[Josh Roesslein]

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
the version, they
would have to update the code just to change a version number for what?
There is no gain in doing an increment of the wire version.

On Sat, May 2, 2009 at 2:28 PM, Dossy Shiobara  wrote:

>
> On 5/2/09 2:30 PM, John Kemp wrote:
> > But for 2009.1, I think it's right to stay with oauth_version=1.0, and
> > move on to fix the actual security issue.
>
> Fine, it really doesn't matter what the oauth_version is, anyway.
>
> Can I see a show of hands - Can an SP safely allow any Consumer to use
> the current OAuth 1.0 (not referring to the revised 2009.1 draft)
> securely?  [Yes or no?]
>
> In other words: If an SP allows an arbitrary Consumer to use the OAuth
> 1.0 flow as-is, then the security threat continues for that SP?
>
> If this is "yes" then all SP's that switch to 2009.1 _cannot_ allow the
> currently known insecure OAuth 1.0 flow, so "backwards compatibility" is
> a non-issue.
>
> --
> 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: OAuth Core 1.0 Rev A, Draft 1

[Josh Roesslein]

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 sensitive data sites might not need
this extra security).
2.) We can tell during the request token request if this is a 1.0 A or 1.0
consumer. If no callback parameter is present, its 1.0. 1.0 A consumers must
still set this
  parameter even if they are not setting a callback (oob, none, etc).
3.) I don't really like this combining of the tokens. We'll have to disjoin
them on the SP to verify. I don't think it will be much of a deal changing
the signature code to make
 this work.

On Sat, May 2, 2009 at 12:01 PM, Joseph Smarr  wrote:

> Erna-just getting to a detailed review of the diff now. Generally it looks
> good but here are a couple of things I think we should change:
>
> 1) If no oauth_token is provided on the authorization URL in 6.2.1 (e.g.
> the mobile/device case where the Consumer is unable to open a web browser
> directly), then I don't think the Provider should return an oauth_verifier
> to be enterered into the Consumer. Basically I'm suggesting we stick to
> OAuth 1.0 here, and the reasons are: a) the attack we're patching is much
> harder to pull off if you have to get the victim to go to a URL and then
> manually enter a request token, and b) many devices won't provide a way to
> enter text into them, so requiring the verifier be manually entered will
> exclude those valuable use cases.
>
> 2) I agree with commenters below that providing oob for oauth_callback
> feels dirty and ideally there would be a better way to distinguish 1.0A and
> 1.0 Consumers. I really don't want to change version numbers to accomplish
> this, but maybe if we think a bit harder, we can come up with a good
> situation. For instane, if the Consumer sends oauth_callback on the
> authorization page, but not in the request token call, you know it's 1.0. I
> guess the hard part is if they don't send oauth_callback in either place,
> and you still respond with the verifier, how do you know when to expect it
> back or not. Hmm...
>
> Which brings me to the discussion we had last week (but which I believe has
> NOT made it to the list) about how Providers can support both 1.0A and 1.0
> simultaneously for a while (which many will have to do). I would suggest
> adding this as an appendix (much as OpenID has a section on supporting both
> 1.1 and 2.0):
>
> - When granting a request token, Provider stores oauth_callback along with
> its token info (if provided).
> - On authorization page, Provider checks if they got a signed
> oauth_callback with the request token. If not, display extra warning
> messages.
> - Provider should be able to always send back an oauth_verifier, even
> though 1.0 clients will ignore it. It can store this with the request token
> info as well.
> - When exchanging for an access token, Provider looks up if it got a signed
> oauth_callback, and only then does it check for oauth_verifier and ensure it
> matches the stored version.
>
> Similarly, a consumer that wants to support 1.0A and 1.0 should be able to
> do the following:
> - always send oauth_callback both on the request token call and on the
> authorization page
> - look for oauth_verifier in the authorization response, and add it to the
> access_token call if present
>
> 3) Another suggestion we made last week was that rather than adding a *new*
> parameter to the Access Token request call (for oauth_verifier), which has
> the downside that it no longer matches the normal "oauth-signed URL call"
> signature of (token+secret+url) like request token and access token and
> protected resource access used to all share, instead you just append the
> oauth_verifier to the request token and send that up as before. This is more
> backwards-compatible in my mind and will make for a smoother transition of
> libraries and implementations. And it does not reduce the security at all.
> Anyone think this is a bad idea, and if so, why?
>
> Thanks! js
>
>
> On Thu, Apr 30, 2009 at 12:25 AM, Eran Hammer-Lahav 
> wrote:
>
>>
>> Please review:
>>
>>
>> http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/1/oauth-core-1_0a.html
>>
>> I did my best to keep the changes to a bare minimum and to avoid any
>> editorial changes to make comparison trivial:
>>
>>
>> http://code.google.com/p/oauth/source/diff?spec=svn992&old=991&r=992&format=unidiff&path=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml
>>
>> Some notes:
>>
>> 1. This is not ready for code! Please wait for a second draft before you
>> start making changes to libraries or your implementations. Given the small
>> scope of this change, I think it will be stable in the next draft.
>>
>> 2. Since this change is small, I would like to give it a short review
>> period before another draft. Please submit all your comments

[oauth] Re: Version Preference

[Josh Roesslein]

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 to do a quick oauth re-authorization, but the
security benefit is worth it. This is up to the SP to decide, but just a
good tip.

On Sat, May 2, 2009 at 1:56 AM, Luca Mearelli wrote:

>
> On Fri, May 1, 2009 at 10:15 PM, Luca Mearelli 
> wrote:
> > On Fri, May 1, 2009 at 10:25 AM, Blaine Cook  wrote:
> >> 1. "1.0 Rev A" with no version string change (i.e., oauth_version=1.0)
> >
> > +1 for this
>
> Let me put a few words behind this: I see no reason for changing the
> value of the parameter transmitted over the wire ( oauth_version )
> since changing it doesn't do any good to the task here that is fixing
> the spec security but instead it will rather do harm to the already
> deployed (and working) code. Let's not forget that the currently
> issued and authorized access tokens would stop to work for no reason
> and require reissue if that value is changed.
>
> Some of the discussion around the version are related to the possible
> confusion of having a different version in the spec "name" and in the
> wire parameter, to this extent any change to the name that makes it
> easy to communicate that we are referring to a revised protocol would
> be good and minimizes the possible confusion, hence the preference for
> calling it "1.0 Rev A".
>
> Moreover I'd see as a good thing to clarify that the role of the
> oauth_version parameter as NOT being the spec version but the protocol
> signature version (I mean the way to indicate how to build the
> signature base string & co)
>
> 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: Version Preference

[Josh Roesslein]

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
Eran has said none
of the authors have used the meritocracy hammer, but eventually someone
needs to make the final choice. Hopefully we can come to a common ground in
our discussions and the core authors won't need to take action.

On Fri, May 1, 2009 at 4:24 PM, Krishna Sankar (ksankar)
wrote:

>
> Eran,
>While you might be technically right, wielding the meritocracy
> badge forcefully is not the right thing to do, imho.
>
>While the folks who have contributed to the specs, obviously,
> have the knowledge and so their voices have more force per se (and
> should be respected - no doubt),  the community that uses the spec has a
> voice too. And one doesn't have to be a permanent contributor to be
> heard and considered. There is a reason for this, if you care to think
> ... am leaving out philosophy, for now ...
>
>Also as we move to IETF, this will be more clear - I see that
> there are couple of e-mail on this, already in the IETF list, alluding
> to this fact. Even there, for now, it is OK, as the spec is not with
> IETF yet.
> Cheers
> 
>
> |-Original Message-
> |From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> |Of Eran Hammer-Lahav
> |Sent: Friday, May 01, 2009 2:07 PM
> |To: oauth@googlegroups.com
> |Subject: [oauth] Re: Version Preference
> |
> |
> |On voting: this is not a democracy. Specs written by committee are
> |almost always a piece of shit. Our process is to build consensus as
> much
> |as possible, trying to get people to agree and when we don't try to
> |focus the conversation using actual technical arguments. At the end, if
> |there isn't a clear consensus, at least in this community, meritocracy
> |wins. This means that people who have contributed more and have
> "earned"
> |their seat at the table get to lead the way. But this is an extreme
> case
> |and I don't think we ever had to use it.
> |
> |The vote is just to get a sense where people are. It is not a way to
> |make decisions. At some point, Blaine or someone else will try to
> figure
> |out where people are, and write a short consensus proposal. Then we
> will
> |go through this again and see where we are. This sounds complicated but
> |it works pretty well. There are no hard rules for building consensus,
> |but we have been successful accomplishing it.
> |
> |---
> |
> |As for your argument, I agree with you on the version of the
> |specification. I don't agree with you on the wire version. I don't
> think
> |they are the same at all.
> |
> |EHL
> |
> |
> |
> |> -Original Message-
> |> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On
> Behalf
> |> Of Matt Sanford
> |> Sent: Friday, May 01, 2009 1:57 PM
> |> To: oauth@googlegroups.com
> |> Subject: [oauth] Re: Version Preference
> |>
> |>
> |> Well ...
> |>
> |>  The argument from me was that there is a material change and
> that
> |> is the place of minor revisions. If this is an optional extension to
> |> the existing protocol we should not change the revision at all. If it
> |> is a minor change that requires a change to the base protocol rather
> |> than an extension document, I call that a revision. This seem logical
> |> enough to me but apparently I am in the minority, 1.0a it is then.
> |>  As far as voting and discussion ... I was under the impression
> |that
> |> the 'Open' moniker sort of encouraged this. Must have been my
> |> confusion, I missed the early on discussions. I'll read back in the
> |> group some for more history.
> |>
> |> - Matt
> |>
> |> On May 1, 2009, at 1:44 PM, Jonathan Sergent wrote:
> |>
> |> > Let me additionally say that this discussion is dangerous and
> voting
> |> > is no way to design a protocol.  What are the arguments in favor of
> |> > changing the version number, and what are the arguments against
> |> > changing it?  I haven't personally seen any arguments in favor of
> |> > changing it that explained the rationale other than "of course you
> |> > should change it because you changed the version number on the
> |spec".
> |> >
> |> > >
> |>
> |>
> |>
> |
> |
>
> >
>

--~--~-~--~~~---~--~~
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: Version Preference

[Josh Roesslein]

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 dangerous and voting is no
> way to design a protocol.  What are the arguments in favor of changing the
> version number, and what are the arguments against changing it?  I haven't
> personally seen any arguments in favor of changing it that explained the
> rationale other than "of course you should change it because you changed the
> version number on the spec".
>
>
> >
>

--~--~-~--~~~---~--~~
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: Version Preference

[Josh Roesslein]

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 auto detect the changes in the
updated spec (example: signature changes)
Document version - incremented with each revision to the document.  (example
1.0 Rev A, 2009.1, etc)

To me this adds some complexity and might confuse people we use two
different versions. This is why I am leaning towards making them the same
and incrementing the version. SP's can still support 1.0 wire versions just
fine so we won't be breaking anything. I would just like a consistent
increment
pattern for this version. When we can auto detect we just ignore this
version. If we can't auto detect we look at this value.

Well that's my two cents on this topic.

On Fri, May 1, 2009 at 1:23 PM, J. Trent Adams wrote:

>
> +1 for Option 3. "Version 1.1"
>
>
> Blaine Cook wrote:
> > We need to build some consensus around the version preference. As I
> > see it, there are several options:
> >
> > 1. "1.0 Rev A" with no version string change (i.e., oauth_version=1.0)
> > 2. "1.0a" (with oauth_version=1.0a)
> > 3. "1.1"
> >
> > Please indicate your support for one of these options, and try to
> > refrain from arguing your case here. The other thread remains open for
> > that purpose. I would especially like to hear from library
> > implementers here, and others who have not voiced their opinions in
> > the other threads.
> >
> > b.
> >
> > >
> >
>
> --
> J. Trent Adams
> =jtrentadams
>
> Profile: http://www.mediaslate.org/jtrentadams/
> LinkedIN: http://www.linkedin.com/in/jtrentadams
> Twitter: http://twitter.com/jtrentadams
>
>
> >
>

--~--~-~--~~~---~--~~
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: This whole version business

[Josh Roesslein]

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 for 1.0 consumers?
I propose that any changes made to a new spec should be clearly marked (ex.
New: ). This should also state if these changes
are optional and thus providing backward compatibility for 1.0 consumers (so
SP's should not block oauth_version 's with 1.0).
If these changes are mandatory (ex. the oauth_verifier for callbacks) then
SP's should block older oauth_versions.

We should not simply just block all older version for all endpoints. We must
be selective in this and only block when a mandatory change is required and
the consumer
should be using a newer version. I think it is important we have a way to
deal with backward compatibility.

On Fri, May 1, 2009 at 1:29 PM, Eran Hammer-Lahav wrote:

>
> There is a difference between what you name the specification and the
> string value you put on the wire. My point is that there is no reason to
> change what is transmitted on the wire. I also made the point that not
> changing the wire string but changing the document version will be more
> confusing. Changing both just because it helps with communication with
> *people* makes no sense. Protocols are for *machines* and those do not need
> a new version number.
>
> EHL
>
> > -Original Message-
> > From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> > Of Matt Sanford
> > Sent: Friday, May 01, 2009 10:53 AM
> > To: oauth@googlegroups.com
> > Subject: [oauth] Re: This whole version business
> >
> >
> > Hi Eran,
> >
> >  If it requires a two-page email to explain what a version number
> > is perhaps the concept is over complicated. My understanding from
> > years of working with software is that major versions are radical
> > departures from the previous interface, whereas minor versions are
> > enhancements and changes which are material but also backward
> > compatible. I would say this change we've discussed is material
> > (otherwise we would not be changing) but also backward compatible
> > (otherwise the revision discussion would have died).
> >  I would have just read the mail and continued on my way where it
> > not for the statement "'Confusing' is not a technical argument and
> > this is an technical document.". That statement makes me want to take
> > up the banner of 1.1. To ignore the ease of development in your
> > protocol, design or documentation is to doom yourself to failure. I am
> > not sure your description has shown to me any *real* reason this is
> > not a backward compatible change, as I think a minor version number
> > would indicate. I voted for 1.1 because of my understanding of major/
> > minor version numbers, redefinition of the term not withstanding. Take
> > it or leave it.
> >
> > Thanks;
> >- Matt Sanford
> >
> > On May 1, 2009, at 10:39 AM, Eran Hammer-Lahav wrote:
> >
> > >
> > > I think the discussion around the version number is completely
> > > misguided because we don't have a basic agreement on what the hell
> > > the version is even for. This means that based on your personal
> > > interpretation of what it means, you come to a different conclusion.
> > > Just because we change the specification, doesn't mean we should
> > > change the version - we need to first agree what it is for. For
> > > those new here, at the OAuth Summit last year we had a wide
> > > consensus not to change the oauth_version value, even with proposals
> > > to add new parameters, error codes, etc. This is not much different.
> > >
> > > ---
> > >
> > > There are 4 elements of the protocol with a version associated with
> > > them:
> > >
> > > * The specification document - this tells readers that there is a
> > > new document.
> > > * The authorization flow used to obtain an Access Token - this is
> > > what we are changing (getting an Access Token).
> > > * The authentication method - the way in which signed OAuth requests
> > > are made and transmitted (using an Access Token).
> > > * The signature method - the way in which the signature value is
> > > calculated.
> > >
> > > The versioning of each of these must be addressed separately or we
> > > will be breaking stuff for no reason (like 2-legged clients).
> > >
> > > * The specification document - give it a new title (without
> > > overlapping with any other version indicator). I have moved away
> > > from using version numbers for specifications I write, and am now
> > > advocating using dates or revisions instead.
> > >
> > > * The authorization flow used to obtain an Access Token - we don't
> > > have a way to indicate which flow is being used, and the
> > > oauth_version parameter was not put in the specification for this (I
> > > know because I put it there). There are two obvious ways to a

[oauth] Re: Version Preference

[Josh Roesslein]

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 email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: OAuth Core 1.0 Rev A, Draft 1

[Josh Roesslein]

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 "oob" is a bit obscure. The first hit for a google search
> on "oob" lists a page with a dozen possibilities (including the right
> one), and the other hits on the first page are red herrings. Some
> suggestions:
>
> oauth_callback="none"
> oauth_callback="noturl"
>
> But documenting what "oob" stands for is fine too.
>
> - Brian
>
> >
>

--~--~-~--~~~---~--~~
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: OAuth Core 1.0 Rev A, Draft 1

[Josh Roesslein]

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 checks the oauth_version string in the request token request and then
uses the correct library version to complete the flow.

On Thu, Apr 30, 2009 at 8:55 PM, Breno de Medeiros  wrote:

>
> Since there is no discovery supported in OAuth, even if the version is
> incremented, there is no way to know if an SP or consumer has upgraded
> without actually running the flow.
>
> If you increment the version number, you will have to make a lot more
> code changes in each library to configure behavior, and will slow down
> adoption of the fix and complicate a transitional period where folks
> might want to support the older flow with some mitigation
> features/stronger warnings until it is safe to break compatibility.
>
> If we want better security, we go with the option that moves us
> forward fastest. The easiest way to abandon 1.0 flow is to get
> everybody upgraded to 1.0A. And developers are complaining that
> incrementing the version number will slow things down.
>
> On Thu, Apr 30, 2009 at 6:26 PM, David Parry  wrote:
> > seriously, I don't understand the reluctance to increment
> > oauth_version. The new implementation is going to require work from
> > both SPs and consumers, and neither is really going to know if other
> > has upgraded without actually running the flow. At least, by
> > incrementing the version, both the SP and the Consumer definitively
> > know the required flow.
> >
>
>
>
> --
> --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: OAuth Core 1.0 Rev A, Draft 1

[Josh Roesslein]

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 reluctance to increment
> oauth_version. The new implementation is going to require work from
> both SPs and consumers, and neither is really going to know if other
> has upgraded without actually running the flow. At least, by
> incrementing the version, both the SP and the Consumer definitively
> know the required flow.
>
> The current approach seems more like a M$ product trying to maximise
> interoperability not a security protocol, that wants to be taken
> seriously.
>
> On May 1, 11:06 am, Breno de Medeiros  wrote:
> > Yes, it does.
> >
> > If a server receives a request token request from a client that does
> > not include a callback_url, the server can respond with a 400 (Bad
> > Request) and, if you want to be more helpful say something in the body
> > like: "Incompatible OAuth flow. This server only supports 1.0a, see
> > "
> >
> > On Thu, Apr 30, 2009 at 5:59 PM, David Parry  wrote:
> > > I don't have a problem with that, it makes perfect sense.
> >
> > > But the proposed spec doesn't provide any method by which to deprecate
> > > the old broken 1.0 functionality and convey that to the consumer that
> > > is making the request.
> >
> > --
> > --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: OAuth Core 1.0 Rev A, Draft 1

[Josh Roesslein]

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 something the spec should not force.

On Thu, Apr 30, 2009 at 8:06 PM, Breno de Medeiros  wrote:

>
> Yes, it does.
>
> If a server receives a request token request from a client that does
> not include a callback_url, the server can respond with a 400 (Bad
> Request) and, if you want to be more helpful say something in the body
> like: "Incompatible OAuth flow. This server only supports 1.0a, see
> "
>
> On Thu, Apr 30, 2009 at 5:59 PM, David Parry  wrote:
> > I don't have a problem with that, it makes perfect sense.
> >
> > But the proposed spec doesn't provide any method by which to deprecate
> > the old broken 1.0 functionality and convey that to the consumer that
> > is making the request.
>
>
>
> --
> --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: OAuth Core 1.0 Rev A, Draft 1

[Josh Roesslein]

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  wrote:

>
> I don't have a problem with that, it makes perfect sense.
>
> But the proposed spec doesn't provide any method by which to deprecate
> the old broken 1.0 functionality and convey that to the consumer that
> is making the request.
>
>
> On May 1, 10:54 am, Jonathan Sergent  wrote:
> > Incrementing oauth_version is a mistake unless you want to ensure that no
> > compatibility occurs - if a server gets a request that is newer than what
> it
> > supports, it probably needs to reject the request.
> >
> > On Thu, Apr 30, 2009 at 5:43 PM, David Parry  wrote:
> >
> > > Not incrementing the oauth_version for the new spec is a mistake imho.
> >
> > > It seems kinda flaky to me to switch between the specs 1.0/1.0a purely
> > > based on whether the oauth_callback is sent when a consumer obtains a
> > > request 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: OAuth Core 1.0 Rev A, Draft 1

[Josh Roesslein]

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
still
doesn't state how the SP can verify the verifier. Using the signature
approach still does the same thing, makes sure the verifier matches.

It might be a good idea to suggest this signature approach in the spec as an
implementation tip.

--~--~-~--~~~---~--~~
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: OAuth Core 1.0 Rev A, Draft 1

[Josh Roesslein]

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 SP can't forget this value since they must verify it. Each request token
will have a verification value bound to it.
So the SP's access token verification process is:

1. Validate signature of access token request (make sure this is the
consumer)
2. Is this request token bound to this consumer?
3. Does the verifier match the one we have on record for this request token?
4. Generate access token and send back to consumer

Hope that clears up your question.

On Thu, Apr 30, 2009 at 6:18 PM, Dirk Balfanz wrote:

> Section 6.3.2: "The verification code received from the Consumer is
> identical to the verification code provided to the User via the redirection
> or manually."
>
> I'm not sure this is the right way to describe what the SP needs to do.
> When they redirect the User back to the Consumer in step 6.2.3, they
> presumably
>
> - remember that the request toke is bound to the User
> - associate the verifier with the request token (which implicitly
> associates it with the Consumer)
>
> Then, in step 6.3.2, they get a request token and a verifier from the
> Consumer. What does it mean, at this point, to verify that the "verification
> code is identical" to the one handed out to "the User"?
>
> Shouldn't this rather say something like "The verification code received
> from the Consumer is identical to the verification code associated with the
> request token in step 6.2.3". Or even better: "The verification code
> received from the consumer matches the request token" - because an SP can
> implement this in a way where it's ok to "forget" what verifier they handed
> out to the User. For example, the verifier could be a signature on the
> request token. If it's implemented that way, the SP doesn't need to remember
> what verifier they handed out to which user, so language requiring an
> equality check doesn't make sense.
>
> Dirk.
>
>
>
> On Thu, Apr 30, 2009 at 12:25 AM, Eran Hammer-Lahav 
> wrote:
>
>>
>> Please review:
>>
>>
>> http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/1/oauth-core-1_0a.html
>>
>> I did my best to keep the changes to a bare minimum and to avoid any
>> editorial changes to make comparison trivial:
>>
>>
>> http://code.google.com/p/oauth/source/diff?spec=svn992&old=991&r=992&format=unidiff&path=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml
>>
>> Some notes:
>>
>> 1. This is not ready for code! Please wait for a second draft before you
>> start making changes to libraries or your implementations. Given the small
>> scope of this change, I think it will be stable in the next draft.
>>
>> 2. Since this change is small, I would like to give it a short review
>> period before another draft. Please submit all your comments by May 8th.
>>
>> 3. This draft is missing a few new Security Consideration sections. It
>> will be added in the next draft but might be shared earlier on the list.
>>
>> 4. This revision does not change the value of the oauth_version parameter
>> which remains '1.0'. The reason for that is that the version has nothing to
>> do with the authorization workflow. It is specific to the signature methods
>> and parameter delivery methods. Telling the difference between the two
>> revisions is very simple: look for an oauth_callback parameter in the
>> Request Token step.
>>
>> 5. The reason why the oauth_callback parameter is now required with a
>> 'oob' value for manual entry is because the presence of the oauth_callback
>> parameter in the first step is the only indication which flow is being used.
>> Since some platforms have problem with empty parameters (they are dropped or
>> not sent on the wire), I decided to try and define a non-URL value (also
>> made the URL absolute).
>>
>> NOTE: Do no suggest ANY editorial changes that are not specific to the
>> changed sections. This is NOT an opportunity to improve the specification.
>> If you want to improve the specification in general, please provider
>> feedback to the Editor's Cut version.
>>
>> Tomorrow, I will post an updated Editor's Cut version as well as an update
>> to the IETF draft to include these changes.
>>
>> EHL
>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: An OAuth attack on Consumer implementations

[Josh Roesslein]

Agree this security issue does not apply to desktop clients.

On Thu, Apr 30, 2009 at 4:05 PM, Mike Malone  wrote:

> For a desktop app you're typically binding the app to an account vs.
> binding a user of the app to an account. In this case you just need to make
> sure that the user who authorized the request token is the same user who is
> clicking "continue." This is what the oauth_verification "PIN" accomplishes.
>
> The situation is slightly different for web apps because a typical web app
> has more than one user, and can bind the access token to a different user
> than the one who returns after the authorization step. "Early binding" means
> the app is binding the request token to a particular user account before
> redirecting to the SP, then disregarding the user who returns after the
> authorization step and simply exchanging the request token for an access
> token bound to the same user account.
>
> Mike
>
>
> On Thu, Apr 30, 2009 at 1:48 PM, Owen Evans  wrote:
>
>> So can I ask, how do you not do early binding with desktop clients that
>> don't receive the call-back?
>> i.e. the only way of doing late binding is to identify via
>> the call-back url which request token was authorised or denied so that that
>> can be linked to the current user. If the application doesn't receive
>> the call-back and relies on the user to tell the application 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.
>>
>> Owen
>>
>> 2009/5/1 Mike Malone 
>>
>> On Thu, Apr 30, 2009 at 11:59 AM, Josh Roesslein wrote:
>>>
>>>> Here is some pseudo python code of what I have in mind for a more higher
>>>> level library: http://pastie.org/464241
>>>>
>>>> This is not a final design, there are other details I have left out, but
>>>> it demonstrates the flow for the consumer of authenticating with oauth.
>>>
>>>
>>> Yea, that's pretty much what I had envisioned. And I counter:
>>> http://dpaste.com/39773/
>>>
>>> As long as the consumer is tasked with persisting the request token
>>> you're not going to be able to do much to prevent early binding. And I still
>>> don't think there's much risk here anyways. In all the time I've been
>>> talking to people about OAuth I've never heard of anyone trying to do this
>>> (has anyone else?). There's just no reason to do it, and (I'll reiterate)
>>> it's harder than doing the right thing.
>>>
>>> Also, your DataStore code is very similar to the way the Python OAuth
>>> library manages tokens for SPs, and that code is the most confusing / least
>>> understood bit of the library (just had a conversation with Leah about just
>>> that). So I'm wary of requiring consumer developers (who have less at stake
>>> and are often less experienced) to do something that's already confusing
>>> developers on the SP side.
>>>
>>>
>>> Mike
>>>
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: An OAuth attack on Consumer implementations

[Josh Roesslein]

I don't see what's so hard about implementing this datastore. There is just
two methods to implement. The library could probably even offer prebuilt
datastores for
the most common databases (mysql, postgre, etc) for the developer so they
just need to plugin the connection and database information. 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 Thu, Apr 30, 2009 at 11:59 AM, Josh Roesslein wrote:
>
>> Here is some pseudo python code of what I have in mind for a more higher
>> level library: http://pastie.org/464241
>>
>> This is not a final design, there are other details I have left out, but
>> it demonstrates the flow for the consumer of authenticating with oauth.
>
>
> Yea, that's pretty much what I had envisioned. And I counter:
> http://dpaste.com/39773/
>
> As long as the consumer is tasked with persisting the request token you're
> not going to be able to do much to prevent early binding. And I still don't
> think there's much risk here anyways. In all the time I've been talking to
> people about OAuth I've never heard of anyone trying to do this (has anyone
> else?). There's just no reason to do it, and (I'll reiterate) it's harder
> than doing the right thing.
>
> Also, your DataStore code is very similar to the way the Python OAuth
> library manages tokens for SPs, and that code is the most confusing / least
> understood bit of the library (just had a conversation with Leah about just
> that). So I'm wary of requiring consumer developers (who have less at stake
> and are often less experienced) to do something that's already confusing
> developers on the SP side.
>
>
> Mike
>
> >
>

--~--~-~--~~~---~--~~
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: An OAuth attack on Consumer implementations

[Josh Roesslein]

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 implementation. We can
not totally stop
bad coding practices, but our libraries can help avoid them and provide
clear examples on how to apply oauth.

On Thu, Apr 30, 2009 at 2:28 PM, Eran Hammer-Lahav wrote:

>  Not giving access to the request token will not prevent early binding,
> just annoy the bad developers really set on doing it. They can still add
> their own “request token” to the callback and bind based on that.
>
> EHL
>
>
>
> On 4/30/09 10:29 AM, "Mike Malone"  wrote:
>
> On Thu, Apr 30, 2009 at 10:12 AM, Jesse Myers 
> wrote:
>
>
> I can't say that I agree.
>
>
> What do you disagree with? Eran said early binding would be addressed in
> the security considerations section.
>
> The fact of the matter is that a lot of developers are going to
> encounter OAuth for the first time when they first need to integrate
> with an SP. Most developers will immediately download an OAuth library
> from somewhere and start to work with it. They probably won't read the
> OAuth spec and internalize it. If they do read the spec, they may just
> gloss over whatever disclaimer warns them off of early binding or not
> have any idea what early binding is.
>
>
> Early binding is also harder. Why would you try to maintain state
> (user/request token binding) between requests when you don't have to? The
> path of least resistance is the right one in this case, which should be
> enough to keep most "bad developers" from screwing things up.
>
> I can't think of any way you'd be able to enforce this constraint in the
> OAuth libraries short of not providing access to the request token. And
> that's not really an option since the consumer app needs to persist the
> request token somewhere, and the library has no way of knowing where that
> somewhere is.
>
> Mike
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
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: OAuth Core 1.0 Rev A, Draft 1

[Josh Roesslein]

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
> > option to flip back and forth. Either the application supports
> > callbacks, or it doesn't, end of story.
>
> agreed, this is the most secure way.
> Do you think this is something that belongs to the spec (as in: be the
> required behavior) ?
>
> 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: An OAuth attack on Consumer implementations

[Josh Roesslein]

Here is some pseudo python code of what I have in mind for a more higher
level library: http://pastie.org/464241

This is not a final design, there are other details I have left out, but it
demonstrates the flow for the consumer of authenticating with oauth.

On Thu, Apr 30, 2009 at 1:47 PM, Josh Roesslein wrote:

> Sorry I forgot about the signing :). Maybe the library could provide a
> datastore interface which the consumer implements with their database.
> This way the library handles all the persisting of the tokens and secretes
> for the programmer. This makes it harder for the programmer to be tempted
> to prebind the token.
>
> We can either try to hide the request token from the developer the best we
> can or make sure they are properly educated on how they should persist it
> (and not prebind).
>
>
> On Thu, Apr 30, 2009 at 1:40 PM, Jesse 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 
>> wrote:
>> > 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 the
>> > access token.
>> >
>> > On Thu, Apr 30, 2009 at 1:23 PM, Mike Malone 
>> wrote:
>> >>
>> >>> I hadn't thought of late binding as the path of least resistance, so
>> >>> perhaps I'm making a bigger deal of this than I need to, although it
>> >>> occurs to me that some developers will be tempted to store the request
>> >>> token in the current session, which is really easy in most
>> >>> environments, and doesn't require any extra token-user binding
>> >>> implementation.
>> >>
>> >> Storing the request token in the session is unlikely to cause any
>> >> problems. The worst possible outcome is that in an attack scenario the
>> >> victim would be redirected to the consumer and the consumer wouldn't be
>> able
>> >> to find the request token since it's not in the victim's session. In
>> this
>> >> case the request token isn't really "bound" (at least not in a bad way)
>> to
>> >> the attacker. It's just persisted in a place that is only visible to
>> one
>> >> user. I'm not saying this is a good idea (I can think of some minor
>> security
>> >> implications), but it's not a huge deal either.
>> >>
>> >> The "bad" sort of binding would occur if the consumer associated a
>> request
>> >> token with a user pre-authorization, and completely ignored the user
>> who
>> >> returns to the site post-authorization.  This requires additional
>> effort
>> >> since, instead of simply persisting the request token, you have to
>> persist
>> >> the request token along with some relation to a specific user of your
>> >> system.
>> >>
>> >>> I actually think there's a lot that good library implementations can
>> >>> do to help, but the simplest thing is to define a clean
>> >>> callback/interface for request token storage that does not reference
>> >>> users or sessions. Developers would have to go out of their way to use
>> >>> early binding, which as you say is not the path of least resistance.
>> >>> A good library could also define a callback/interface for access token
>> >>> storage that does reference users or sessions, but that's certainly
>> >>> more complicated because it gets into application logic.
>> >>
>> >> I don't see how it would prevent the consumer from associating a user
>> with
>> >> the request token. In the end, the consumer application has to be
>> >> responsible for persisting the request token somewhere, and retrieving
>> it
>> >> later. As long as that's true there's nothing stopping the consumer
>> from
>> >> associating the request token with a particular user of the system
>> (aside
>> >> from the fact that it's harder to do and wrong).
>> >>
>> >> Mike
>> >>
>> >>
>> >
>> >
>> > >
>> >
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: An OAuth attack on Consumer implementations

[Josh Roesslein]

Sorry I forgot about the signing :). Maybe the library could provide a
datastore interface which the consumer implements with their database.
This way the library handles all the persisting of the tokens and secretes
for the programmer. This makes it harder for the programmer to be tempted
to prebind the token.

We can either try to hide the request token from the developer the best we
can or make sure they are properly educated on how they should persist it
(and not prebind).

On Thu, Apr 30, 2009 at 1:40 PM, Jesse 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 
> wrote:
> > 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 the
> > access token.
> >
> > On Thu, Apr 30, 2009 at 1:23 PM, Mike Malone  wrote:
> >>
> >>> I hadn't thought of late binding as the path of least resistance, so
> >>> perhaps I'm making a bigger deal of this than I need to, although it
> >>> occurs to me that some developers will be tempted to store the request
> >>> token in the current session, which is really easy in most
> >>> environments, and doesn't require any extra token-user binding
> >>> implementation.
> >>
> >> Storing the request token in the session is unlikely to cause any
> >> problems. The worst possible outcome is that in an attack scenario the
> >> victim would be redirected to the consumer and the consumer wouldn't be
> able
> >> to find the request token since it's not in the victim's session. In
> this
> >> case the request token isn't really "bound" (at least not in a bad way)
> to
> >> the attacker. It's just persisted in a place that is only visible to one
> >> user. I'm not saying this is a good idea (I can think of some minor
> security
> >> implications), but it's not a huge deal either.
> >>
> >> The "bad" sort of binding would occur if the consumer associated a
> request
> >> token with a user pre-authorization, and completely ignored the user who
> >> returns to the site post-authorization.  This requires additional effort
> >> since, instead of simply persisting the request token, you have to
> persist
> >> the request token along with some relation to a specific user of your
> >> system.
> >>
> >>> I actually think there's a lot that good library implementations can
> >>> do to help, but the simplest thing is to define a clean
> >>> callback/interface for request token storage that does not reference
> >>> users or sessions. Developers would have to go out of their way to use
> >>> early binding, which as you say is not the path of least resistance.
> >>> A good library could also define a callback/interface for access token
> >>> storage that does reference users or sessions, but that's certainly
> >>> more complicated because it gets into application logic.
> >>
> >> I don't see how it would prevent the consumer from associating a user
> with
> >> the request token. In the end, the consumer application has to be
> >> responsible for persisting the request token somewhere, and retrieving
> it
> >> later. As long as that's true there's nothing stopping the consumer from
> >> associating the request token with a particular user of the system
> (aside
> >> from the fact that it's harder to do and wrong).
> >>
> >> Mike
> >>
> >>
> >
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: An OAuth attack on Consumer implementations

[Josh Roesslein]

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 the
access token.

On Thu, Apr 30, 2009 at 1:23 PM, Mike Malone  wrote:

>
> I hadn't thought of late binding as the path of least resistance, so
>> perhaps I'm making a bigger deal of this than I need to, although it
>> occurs to me that some developers will be tempted to store the request
>> token in the current session, which is really easy in most
>> environments, and doesn't require any extra token-user binding
>> implementation.
>>
>
> Storing the request token in the session is unlikely to cause any problems.
> The worst possible outcome is that in an attack scenario the victim would be
> redirected to the consumer and the consumer wouldn't be able to find the
> request token since it's not in the victim's session. In this case the
> request token isn't really "bound" (at least not in a bad way) to the
> attacker. It's just persisted in a place that is only visible to one user.
> I'm not saying this is a good idea (I can think of some minor security
> implications), but it's not a huge deal either.
>
> The "bad" sort of binding would occur if the consumer associated a request
> token with a user pre-authorization, and completely ignored the user who
> returns to the site post-authorization.  This requires additional effort
> since, instead of simply persisting the request token, you have to persist
> the request token along with some relation to a specific user of your
> system.
>
> I actually think there's a lot that good library implementations can
>> do to help, but the simplest thing is to define a clean
>> callback/interface for request token storage that does not reference
>> users or sessions. Developers would have to go out of their way to use
>> early binding, which as you say is not the path of least resistance.
>> A good library could also define a callback/interface for access token
>> storage that does reference users or sessions, but that's certainly
>> more complicated because it gets into application logic.
>>
>
> I don't see how it would prevent the consumer from associating a user with
> the request token. In the end, the consumer application has to be
> responsible for persisting the request token somewhere, and retrieving it
> later. As long as that's true there's nothing stopping the consumer from
> associating the request token with a particular user of the system (aside
> from the fact that it's harder to do and wrong).
>
>
> Mike
>
> >
>

--~--~-~--~~~---~--~~
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: OAuth Core 1.0 Rev A, Draft 1

[Josh Roesslein]

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, is it? I was under the impression that the rev was designed
> to
> > preserve backwards compatibility and leave the decision up to SPs.
>
> Right; (I think) the 1.0 consumers will only break if an SP has
> upgraded to 1.0a/1.1 or whatever we call the new version.
>
> 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: An OAuth attack on Consumer implementations

[Josh Roesslein]

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 this is a consumer implementation problem. This should be fixed in
the libraries and not the protocol its self. It's up to library implementers
to properly document their libraries and educate its users. The process of
implementing a consumer should be trivial to the developer.

On Thu, Apr 30, 2009 at 12:29 PM, Mike Malone  wrote:

> On Thu, Apr 30, 2009 at 10:12 AM, Jesse Myers wrote:
>
>>
>> I can't say that I agree.
>
>
> What do you disagree with? Eran said early binding would be addressed in
> the security considerations section.
>
> The fact of the matter is that a lot of developers are going to
>> encounter OAuth for the first time when they first need to integrate
>> with an SP. Most developers will immediately download an OAuth library
>> from somewhere and start to work with it. They probably won't read the
>> OAuth spec and internalize it. If they do read the spec, they may just
>> gloss over whatever disclaimer warns them off of early binding or not
>> have any idea what early binding is.
>>
>
> Early binding is also harder. Why would you try to maintain state
> (user/request token binding) between requests when you don't have to? The
> path of least resistance is the right one in this case, which should be
> enough to keep most "bad developers" from screwing things up.
>
> I can't think of any way you'd be able to enforce this constraint in the
> OAuth libraries short of not providing access to the request token. And
> that's not really an option since the consumer app needs to persist the
> request token somewhere, and the library has no way of knowing where that
> somewhere is.
>
> Mike
>
>
> >
>

--~--~-~--~~~---~--~~
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?

[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] 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

[Josh Roesslein]

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.

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
> really need that extra level of verifiable security.
>
> --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: Moving forward

[Josh Roesslein]

When the SP gets ready to direct the user back to the consumer after
authorization, this secrete will be generated and stored in the callback
URL.
If the redirect is completely automated, the user will never see it. If the
user has to manually enter it, then they must be careful not to share it
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:04 pm, Josh Roesslein  wrote:
> > 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.
>
> But how did that user get that secret and how does the consumer
> receive it?  If the user had to personally remember it OR it was
> stored somewhere that the user authenticated with (again, requring
> authentication on the consumer) it is secure. Any other means allows
> for (admittedly not easy) an attack.
>
> > The only way
> > this value can be known is by authenticating with the SP.
>
> True, but the user can inadvertently pass it to the attacker.
>
> Sorry -- I don't mean to be difficult. just poking at ideas to see if
> they fit my previous stated metric of verifyably matching the
> u...@consumer to u...@sp.
>
> --peter
>
> >
> > On Sun, Apr 26, 2009 at 1:42 PM, pkeane  wrote:
> >
> > > On Apr 26, 12: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?
> >
> > > I would just mention that this proposal (essentially making the
> > > callback url immutable) limits the likelihood that the user who
> > > authenticated w/ the SP is NOT user who requests an access token, it
> > > does not actually verify that it is the same user.  The only way I can
> > > think of to do that is to store "state" in the user himself/herself
> > > (as is always the case w/ passwords, biometrics, etc.).
> >
> > > In those cases that there is no callback, and the user has to actually
> > > type in a pin/verifier (which was displayed to them when they
> > > authenticated w/ SP)  to request an access token, actual verification
> > > IS taking place (state was stored on user) and our security hole is
> > > fixed.
> >
> > > --peter
> >
> > > > 3. For the Signed Callback URLs solution, what to call the new
> parameter
> > > returned in 6.2.3? Suggestions so far i

[oauth] Re: Moving forward

[Josh Roesslein]

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 is by authenticating with the SP.

On Sun, Apr 26, 2009 at 1:42 PM, pkeane  wrote:

>
>
>
> On Apr 26, 12: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?
>
>
> I would just mention that this proposal (essentially making the
> callback url immutable) limits the likelihood that the user who
> authenticated w/ the SP is NOT user who requests an access token, it
> does not actually verify that it is the same user.  The only way I can
> think of to do that is to store "state" in the user himself/herself
> (as is always the case w/ passwords, biometrics, etc.).
>
> In those cases that there is no callback, and the user has to actually
> type in a pin/verifier (which was displayed to them when they
> authenticated w/ SP)  to request an access token, actual verification
> IS taking place (state was stored on user) and our security hole is
> fixed.
>
> --peter
>
>
>
> >
> > 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

[Josh Roesslein]

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 to verify this is the same user
who authorized the consumer, or put another way we are trying to
establish ownership of the request token.
So I suggest the name "request secrete" which is used to establish
ownership of the authorized request token.
4. I think it is best to send back both request token and the request
secrete. This way the consumer can link the authorization with the initial
request.
This would also help block brute force attacks trying to guess the
request secrete. If we receive a callback with a request secrete that
results in a failed exchange with the
provider, we can now invalidate the request token and alert the admins
of an attack.

On Sun, Apr 26, 2009 at 12: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: OAuth Security Advisory

[Josh Roesslein]

How would a desktop client receive a callback? First it would need to be
running a webserver to process the incoming http request and
also the provider would need its IP address. Would a provider be registering
each IP as a separate consumer? If this is the case than best option
would to be generating each IP its own secrete so they can sign their
callback.

I don't really see it practical for desktop clients to use callbacks. In
this case we need to sacrifice a bit of user friendliness for security.
After all is it that much work to copy and paste a string??? :\

On Sat, Apr 25, 2009 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
> > impossible to keep a secrete concealed in that situation.
> > In that case the consumer would not being using callbacks anyways and
> they
> > should disable it with the proposed flag when registering with the
> provider.
> > With this flag set, providers will ignore the callback parameter.
>
> >
>

--~--~-~--~~~---~--~~
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: OAuth Security Advisory

[Josh Roesslein]

Well for server-based consumers they should be secrete.
I'm guessing you are referring to desktop-based consumers. Yes it is
impossible to keep a secrete concealed in that situation.
In that case the consumer would not being using callbacks anyways and they
should disable it with the proposed flag when registering with the provider.
With this flag set, providers will ignore the callback parameter.

On Sat, Apr 25, 2009 at 7:53 PM, Dossy Shiobara  wrote:

> In some cases, the consumer "secret" is not very secret.
>
> The response "too bad" is not acceptable.  There is no reason why an
> authorization spec. can't be designed to work in such a case.
>
> --
> Dossy Shiobara
> do...@panoptic.com
>
> -Original Message-
> From: Josh Fraser 
>
> Date: Sat, 25 Apr 2009 17:05:17
> To: OAuth
> Subject: [oauth] 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
> > have gotten off topic.
> >
> > Our focus should be:
> >
> > + Secure the callback in the authorization URL from tampering
> > + Make sure the user that authorized the request token is the same user
> that
> > requested it
> >
> > The first issue can be solved by signing the callback URL if it is
> included
> > in the authorization URL. Since devices / apps wont' use a callback, the
> > consumer
> > should set a flag during provider registration saying it will not use
> > callbacks. This will prevent attackers from injecting a callback.
> > This still allows for clean authorization URLs that are easy to type
> > manually.
> >
> > We can solve the second issue by requiring a "confirmation token" be
> > included with the callback.
> > If there is no callback, the user must manually enter is confirmation
> back
> > into the consumer.
> > The token should be type able, but long enough to make brute attacks
> > unlikely.
> >
> > These changes are easy to implement and don't really affect the current
> > oauth flow.
> >
> > On Sat, Apr 25, 2009 at 4:31 PM, Zachary Voase <
> disturb...@googlemail.com>wrote:
> >
> >
> >
> > > I completely agree. The whole point of this thread (I thought) was to
> > > develop a solution to a very specific security hole; this has already
> > > been done with three things: once-only exchanging, signed/pre-
> > > specified callbacks, and the concept of a callback nonce (a.k.a.
> > > authorization token, and a host of other names) (have a look at a
> > > previous post by Mike Malone for the details). These things require
> > > absolutely *no* change in user experience, they keep all of the burden
> > > of verification/authentication on the service provider (where it
> > > should be), and they need only minimal changes to the specification.
> > > We can't trust consumers to verify things, because that means the
> > > service provider is trusting a third-party with the security of its
> > > users' data.
> >
> > > I suppose what I'm saying is that if you think you've got a totally
> > > better authorization protocol/strategy worked out, great, but let's
> > > try and keep the focus on patching this security hole rather than
> > > completely rewriting the spec.
> >
> > > You might also be interested in reading the OAuth design goals for an
> > > explanation of why things are the way they are:
> > >http://oauth.net/about/design-goals
> >
> > > Regards,
> > > Zack
> >
> > > On Apr 25, 10:56 pm, "J. Adam Moore"  wrote:
> > > > Yeah, I have that at my bank and it sucks all kinds of hell. Thank
> god
> > > > 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. I really need to finish my post on this. It has pictures
> > > > and everything. Should clear up some confusion people might have.
> >
> > > > I am not saying that your method is forever flawed, 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
> > > > cur

[oauth] Re: OAuth Security Advisory

[Josh Roesslein]

Josh, current we don't sign the authorization URL so an attacker can do what
ever they want. Once we start signing the callbacks, this won't be possible.

On Sat, Apr 25, 2009 at 7:05 PM, Josh Fraser  wrote:

>
> 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
> > have gotten off topic.
> >
> > Our focus should be:
> >
> > + Secure the callback in the authorization URL from tampering
> > + Make sure the user that authorized the request token is the same user
> that
> > requested it
> >
> > The first issue can be solved by signing the callback URL if it is
> included
> > in the authorization URL. Since devices / apps wont' use a callback, the
> > consumer
> > should set a flag during provider registration saying it will not use
> > callbacks. This will prevent attackers from injecting a callback.
> > This still allows for clean authorization URLs that are easy to type
> > manually.
> >
> > We can solve the second issue by requiring a "confirmation token" be
> > included with the callback.
> > If there is no callback, the user must manually enter is confirmation
> back
> > into the consumer.
> > The token should be type able, but long enough to make brute attacks
> > unlikely.
> >
> > These changes are easy to implement and don't really affect the current
> > oauth flow.
> >
> > On Sat, Apr 25, 2009 at 4:31 PM, Zachary Voase <
> disturb...@googlemail.com>wrote:
> >
> >
> >
> > > I completely agree. The whole point of this thread (I thought) was to
> > > develop a solution to a very specific security hole; this has already
> > > been done with three things: once-only exchanging, signed/pre-
> > > specified callbacks, and the concept of a callback nonce (a.k.a.
> > > authorization token, and a host of other names) (have a look at a
> > > previous post by Mike Malone for the details). These things require
> > > absolutely *no* change in user experience, they keep all of the burden
> > > of verification/authentication on the service provider (where it
> > > should be), and they need only minimal changes to the specification.
> > > We can't trust consumers to verify things, because that means the
> > > service provider is trusting a third-party with the security of its
> > > users' data.
> >
> > > I suppose what I'm saying is that if you think you've got a totally
> > > better authorization protocol/strategy worked out, great, but let's
> > > try and keep the focus on patching this security hole rather than
> > > completely rewriting the spec.
> >
> > > You might also be interested in reading the OAuth design goals for an
> > > explanation of why things are the way they are:
> > >http://oauth.net/about/design-goals
> >
> > > Regards,
> > > Zack
> >
> > > On Apr 25, 10:56 pm, "J. Adam Moore"  wrote:
> > > > Yeah, I have that at my bank and it sucks all kinds of hell. Thank
> god
> > > > 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. I really need to finish my post on this. It has pictures
> > > > and everything. Should clear up some confusion people might have.
> >
> > > > I am not saying that your method is forever flawed, 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:
> >
> > > > > 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 being
> careful to
> > > > > check the address bar and making sure the site they are at
> > > > > is indeed the provider's 

[oauth] Re: OAuth Security Advisory

[Josh Roesslein]

Well I think some meet Friday. I've seen leah culver on the list, not sure
who else is an author and if they are watching.
Yeah I have used many words for this "token", but I like the "callback
token" term. Seems fitting since it is the token being returned on the
callback.
Maybe we can just call it the "whateveryouwanttocallit token".

On Sat, Apr 25, 2009 at 5:13 PM, Zachary Voase wrote:

>
> Exactly! Although yet again, you're using a different name to the ones
> I've heard on here :) So that makes 'callback nonce', 'authorization
> token', 'confirmation token' ... has anyone got any more? Let's get
> back to discussing the color of the bike shed already!
>
> OK, but on a more serious note, what's actually happening with this
> spec now? What are the opinions of the OAuth authors (if, indeed, they
> have actually been *following* this conversation)?
>
> On Apr 25, 11: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 the authorization URL from tampering
> > + Make sure the user that authorized the request token is the same user
> that
> > requested it
> >
> > The first issue can be solved by signing the callback URL if it is
> included
> > in the authorization URL. Since devices / apps wont' use a callback, the
> > consumer
> > should set a flag during provider registration saying it will not use
> > callbacks. This will prevent attackers from injecting a callback.
> > This still allows for clean authorization URLs that are easy to type
> > manually.
> >
> > We can solve the second issue by requiring a "confirmation token" be
> > included with the callback.
> > If there is no callback, the user must manually enter is confirmation
> back
> > into the consumer.
> > The token should be type able, but long enough to make brute attacks
> > unlikely.
> >
> > These changes are easy to implement and don't really affect the current
> > oauth flow.
> >
> > On Sat, Apr 25, 2009 at 4:31 PM, Zachary Voase <
> disturb...@googlemail.com>wrote:
> >
> >
> >
> >
> >
> > > I completely agree. The whole point of this thread (I thought) was to
> > > develop a solution to a very specific security hole; this has already
> > > been done with three things: once-only exchanging, signed/pre-
> > > specified callbacks, and the concept of a callback nonce (a.k.a.
> > > authorization token, and a host of other names) (have a look at a
> > > previous post by Mike Malone for the details). These things require
> > > absolutely *no* change in user experience, they keep all of the burden
> > > of verification/authentication on the service provider (where it
> > > should be), and they need only minimal changes to the specification.
> > > We can't trust consumers to verify things, because that means the
> > > service provider is trusting a third-party with the security of its
> > > users' data.
> >
> > > I suppose what I'm saying is that if you think you've got a totally
> > > better authorization protocol/strategy worked out, great, but let's
> > > try and keep the focus on patching this security hole rather than
> > > completely rewriting the spec.
> >
> > > You might also be interested in reading the OAuth design goals for an
> > > explanation of why things are the way they are:
> > >http://oauth.net/about/design-goals
> >
> > > Regards,
> > > Zack
> >
> > > On Apr 25, 10:56 pm, "J. Adam Moore"  wrote:
> > > > Yeah, I have that at my bank and it sucks all kinds of hell. Thank
> god
> > > > 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. I really need to finish my post on this. It has pictures
> > > > and everything. Should clear up some confusion people might have.
> >
> > > > I am not saying that your method is forever flawed, 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.
> >
> > &

[oauth] Re: OAuth Security Advisory

[Josh Roesslein]

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 the authorization URL from tampering
+ Make sure the user that authorized the request token is the same user that
requested it

The first issue can be solved by signing the callback URL if it is included
in the authorization URL. Since devices / apps wont' use a callback, the
consumer
should set a flag during provider registration saying it will not use
callbacks. This will prevent attackers from injecting a callback.
This still allows for clean authorization URLs that are easy to type
manually.

We can solve the second issue by requiring a "confirmation token" be
included with the callback.
If there is no callback, the user must manually enter is confirmation back
into the consumer.
The token should be type able, but long enough to make brute attacks
unlikely.

These changes are easy to implement and don't really affect the current
oauth flow.

On Sat, Apr 25, 2009 at 4:31 PM, Zachary Voase wrote:

>
> I completely agree. The whole point of this thread (I thought) was to
> develop a solution to a very specific security hole; this has already
> been done with three things: once-only exchanging, signed/pre-
> specified callbacks, and the concept of a callback nonce (a.k.a.
> authorization token, and a host of other names) (have a look at a
> previous post by Mike Malone for the details). These things require
> absolutely *no* change in user experience, they keep all of the burden
> of verification/authentication on the service provider (where it
> should be), and they need only minimal changes to the specification.
> We can't trust consumers to verify things, because that means the
> service provider is trusting a third-party with the security of its
> users' data.
>
> I suppose what I'm saying is that if you think you've got a totally
> better authorization protocol/strategy worked out, great, but let's
> try and keep the focus on patching this security hole rather than
> completely rewriting the spec.
>
> You might also be interested in reading the OAuth design goals for an
> explanation of why things are the way they are:
> http://oauth.net/about/design-goals
>
> Regards,
> Zack
>
> On Apr 25, 10:56 pm, "J. Adam Moore"  wrote:
> > Yeah, I have that at my bank and it sucks all kinds of hell. Thank god
> > 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. I really need to finish my post on this. It has pictures
> > and everything. Should clear up some confusion people might have.
> >
> > I am not saying that your method is forever flawed, 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:
> >
> >
> >
> > > 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 being careful to
> > > check the address bar and making sure the site they are at
> > > is indeed the provider's site. Another layer that can help prevent this
> is
> > > by using images that are displayed on the provider's site during login.
> Some
> > > banks use this during login. You first give your username and hit
> enter.
> > > Next the bank shows an image you set when you signed up. You verifty
> this is
> > > the right image and provide your password.
> > > This isn't really something oauth should mandate. It is up to the
> provider
> > > to add this layer of security on their own.
> >
> > > On Sat, Apr 25, 2009 at 3:24 PM, Brian Eaton 
> wrote:
> >
> > > > On Sat, Apr 25, 2009 at 1:11 PM, J. Adam Moore  >
> > > > wrote:
> > > > > The problem itself is REALLY
> > > > > specific: Phishing. Like fish in a barrel phishing. The solution is
> to
> > > > > take away their bullets, and is not to try and harden the barrels
> or
> > > > > educate the fish to dodge bullets.
> >
> > > > The problem is very similar to phishing, in that it requ

[oauth] Re: OAuth Security Advisory

[Josh Roesslein]

I guess we could still support the current 1.0 spec for these sort of
devices that need the request-token flow. When a consumer registers they can
specify if they require
1.0 support. Consumer websites should not leave this enabled to prevent
session fixation attacks.

On Sat, Apr 25, 2009 at 4:14 PM, Allen Tom  wrote:

>  Proprietary auths like Yahoo's BBAuth and Google's AuthSub do not have the
> concept of a request token, and instead just have the Consumer redirect the
> browser to the SP's auth endpoint. After the user grants permission, the
> user's browser is redirected back to the consumer with a  token that is then
> exchanged for the credentials. Neither BBAuth nor AuthSub are vulnerable to
> the session fixation attack.
>
> Implementing the Request Token on the SP side of things is pretty tricky,
> especially if the SP is globally distributed, as that requires  the Request
> Token to be replicated everywhere the user's browser and the consumer could
> be located (which could distant from each other). The RT may also be tricky
> for the Consumer, because improperly implemented consumers may implement
> "early binding" and bind the Access Token with the Request Token, instead of
> binding the Access Token with the callback token.
>
> On the flip side, eliminating the Request Token will exclude Consumers that
> aren't able to redirect the browser from the OAuth flow. It might make sense
> to just define an alternate flow for internet refrigerators and chumbys,
> while optimizing for the 99% case, in which the consumer is either a website
> or an installable client, on a system with a browser.
>
> That being said, it's probably easier and faster to do 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 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 was registered. Could also
> support dynamically setting callback by including
> it in the authorization URL and signing it.
>
> The flow would be:
> User visits consumer --> Consumer directs user to authorization URL -->
> User authenticates with service provider --> Grant access to consumer -->
> Directed back to consumer with access token
>
> By not having request tokens, an attacker can't really get into the flow.
> There are two issues:
>
> 1. Service providers and Users must watch out for bad consumers that
> register with the service provider. This can be avoided by
> proper screening by the service provider (make sure the consumer is
> legit) and the User knowing the consumer they are granting access.
>
> Example:
>
> - Attacker sends user this link:
> http://www.serviceprovider.com/oauth/authorize?consumer=badconsumer.com
> - User authenticates and grants access
> - Directed to bad consumer site with access key
> - Bad consumer steals private data with access key
>
>To fix attack:
> - Delete consumer account on service provider
> - Invalidate all access tokens generated by this consumer account
>
> 2. The token can be stolen by a man in the middle attack during the
> callback. This can be avoided by using https.
>
> On Fri, Apr 24, 2009 at 4:59 PM, pkeane  wrote:
>
>>
>>
>>
>> On Apr 24, 3:23 pm, joshthecoder  wrote:
>> > Actually after some more thought I have come up with this new
>> > revision:
>> >
>> > 1. User visits authorization URL that directs them to the service
>> > provider's site.
>> >This link can be provided by the consumer.
>> >Example:
>> http://www.pictureland.com/oauth/authenticate?consumer=printit.com
>> > 2. User authenticates with service provider.
>> > 3. User authorizes access to the consumer. Optionally this page can
>> > also be used
>> >for setting other restrictions (ex. lifetime of token, resource
>> > access rights, etc)
>>
>>  Am I correct in characterizing #2 & #3 as collapsing the OAuth A & B
>> steps into one interaction.  Or perhaps more accurately, eliminating
>> step A (getting a request token that will need to be authorized) and
>> going right to B & C?
>>
>> --peter
>>
>> > 4. Service provider generates access token (only usable by t

[oauth] Re: meeting notes from Friday

[Josh Roesslein]

There is no signature url. In a way I guess the flow I am talking about is
different than the signature auth flow.

1. User visits provider site:
https://www.provider.com/oauth/authorize/testconsumer
2. User is presented with login page.
3. User grants access to the consumer.
4. Provider generates callback token that is easy for user to type into
consumer device.
5. Consumer device swaps callback for access token like normal.

On Sat, Apr 25, 2009 at 3:47 PM, Jonathan Sergent wrote:

>
> You can't expect the user to type a URL with a signature in it, in the
> case of a device 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 unless he has the consumer secrete.
> > If there is no signiture, the provider ignores any parameters. It can
> lookup
> > to see if a default callback has been registered and use that. If there
> 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 it
> >> > taking
> >> > the extra time to get it right. Most providers I think have already
> >> > found
> >> > quick fixes
> >> > to block this session fixation attack.
> >>
> >> Really?  The only "quick fix" I have seen is a scary warning message
> >> on the approval page telling users not to use OAuth.
> >>
> >> > So I don't think we are in immediate
> >> > danger, but I could be wrong. Just by adding callback 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 for a brute force
> attack
> >> >> to
> >> >> guess the callback URL.
> >> >> Plus we can require that you only get once try to swap the callback
> for
> >> >> an
> >> >> access token. After that it is invalidated and 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 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 approval URLs is that we would lose
> >> >>> > support for devices that either
> >> >>> > a) can't open a web browser (because the signed approval URL is
> >> >>> > really
> >> >>> > long)
> >> >>> >   or
> >> >>> > b) can't receive a callback URL (because the callback token is
> >> >>> > really
> >> >>> > long).
> >> >>> >
> >> >>>
> >> >>> Err, I should have pointed out that the other objection I've heard
> to
> >> >>> signed approval URLs is that they are a major departure from the
> >> >>> current protocol, and thus will slow down deployment of fixes.  I'm
> >> >>> not sure that's true, but it seems plausible.
> >> >>>
> >> >>>
> >> >>
> >> >
> >> >
> >> > >
> >> >
> >>
> >>
> >
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: meeting notes from Friday

[Josh Roesslein]

How can the attacker use that flow? He can't set a callback in that URL
since it can't be signed by him unless he has the consumer secrete.
If there is no signiture, the provider ignores any parameters. It can lookup
to see if a default callback has been registered and use that. If there 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 it
> taking
> > the extra time to get it right. Most providers I think have already found
> > quick fixes
> > to block this session fixation attack.
>
> Really?  The only "quick fix" I have seen is a scary warning message
> on the approval page telling users not to use OAuth.
>
> > So I don't think we are in immediate
> > danger, but I could be wrong. Just by adding callback 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 for a brute force attack
> to
> >> guess the callback URL.
> >> Plus we can require that you only get once try to swap the callback for
> an
> >> access token. After that it is invalidated and 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 <
> jroessl...@gmail.com>
> >>> > 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 approval URLs is that we would lose
> >>> > support for devices that either
> >>> > a) can't open a web browser (because the signed approval URL is
> really
> >>> > long)
> >>> >   or
> >>> > b) can't receive a callback URL (because the callback token is really
> >>> > long).
> >>> >
> >>>
> >>> Err, I should have pointed out that the other objection I've heard to
> >>> signed approval URLs is that they are a major departure from the
> >>> current protocol, and thus will slow down deployment of fixes.  I'm
> >>> not sure that's true, but it seems plausible.
> >>>
> >>>
> >>
> >
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: meeting notes from Friday

[Josh Roesslein]

As for the timing to apply this change, I think it would be worth it taking
the extra time to get it right. Most providers I think have already found
quick fixes
to block this session fixation attack. So I don't think we are in immediate
danger, but I could be wrong. Just by adding callback 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 for a brute force attack to
> guess the callback URL.
> Plus we can require that you only get once try to swap the callback for an
> access token. After that it is invalidated and 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 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 approval URLs is that we would lose
>> > support for devices that either
>> > a) can't open a web browser (because the signed approval URL is really
>> long)
>> >   or
>> > b) can't receive a callback URL (because the callback token is really
>> long).
>> >
>>
>> Err, I should have pointed out that the other objection I've heard to
>> signed approval URLs is that they are a major departure from the
>> current protocol, and thus will slow down deployment of fixes.  I'm
>> not sure that's true, but it seems plausible.
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: OAuth Security Advisory

[Josh Roesslein]

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 being careful to
check the address bar and making sure the site they are at
is indeed the provider's site. Another layer that can help prevent this is
by using images that are displayed on the provider's site during login. Some
banks use this during login. You first give your username and hit enter.
Next the bank shows an image you set when you signed up. You verifty this is
the right image and provide your password.
This isn't really something oauth should mandate. It is up to the provider
to add this layer of security on their own.

On Sat, Apr 25, 2009 at 3:24 PM, Brian Eaton  wrote:

>
> On Sat, Apr 25, 2009 at 1:11 PM, J. Adam Moore 
> wrote:
> > The problem itself is REALLY
> > specific: Phishing. Like fish in a barrel phishing. The solution is to
> > take away their bullets, and is not to try and harden the barrels or
> > educate the fish to dodge bullets.
>
> The problem is very similar to phishing, in that it requires some
> element of social engineering to exploit.  However, the current
> protocol allows a phishing attack where everything the user sees is
> completely in context and true.  The session fixation vulnerability
> allows perfect phishing.
>
> I just reread the protocol you proposed above, and I'm pretty sure it
> doesn't actually fix the session fixation attack.  You need some kind
> of a callback token passed through the user's browser back to the
> consumer.  (If you were including that, sorry, I missed it.)
>
> >
>

--~--~-~--~~~---~--~~
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: meeting notes from Friday

[Josh Roesslein]

Well this callback is short lived since it is swapped by the consumer almost
right away. So you don't have much time for a brute force attack to guess
the callback URL.
Plus we can require that you only get once try to swap the callback for an
access token. After that it is invalidated and 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 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 approval URLs is that we would lose
> > support for devices that either
> > a) can't open a web browser (because the signed approval URL is really
> long)
> >   or
> > b) can't receive a callback URL (because the callback token is really
> long).
> >
>
> Err, I should have pointed out that the other objection I've heard to
> signed approval URLs is that they are a major departure from the
> current protocol, and thus will slow down deployment of fixes.  I'm
> not sure that's true, but it seems plausible.
>
> >
>

--~--~-~--~~~---~--~~
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: meeting notes from Friday

[Josh Roesslein]

Yes we would need a way to still allow for manually providing these device
the callback token.

The user can directly visit an authorization URL since their will be no
callback.
Example: http://service.example.com/authorize/testconsumer

This URL can be provided by the consumer device.

Once the user visits this URL they are prompted to log in to the provider
and approve access.
Next the provider gives the user the callback token which they then manually
enter into the device.

Does that sound right?

On Sat, Apr 25, 2009 at 3: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 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 approval URLs is that we would lose
> support for devices that either
> a) can't open a web browser (because the signed approval URL is really
> long)
>   or
> b) can't receive a callback URL (because the callback token is really
> long).
>
> Signed callback URLs would let us keep request tokens and callback
> tokens short enough to type or copy and paste.
>
> >
>

--~--~-~--~~~---~--~~
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: OAuth Security Advisory

[Josh Roesslein]

How would you phish that? Provide a step by step example.

On Sat, Apr 25, 2009 at 3:11 PM, J. Adam Moore  wrote:

>
> I could Phish the hell out of that. Pop up windows and timed out
> requests sound like a user nightmare. Not to mention all the extra
> checking and processing of info. It seems rather hackish. I really
> think you are over complicating this. The problem itself is REALLY
> specific: Phishing. Like fish in a barrel phishing. The solution is to
> take away their bullets, and is not to try and harden the barrels or
> educate the fish to dodge bullets.
>
> 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 25, 2009 at 2:58 PM, J. Adam Moore 
> wrote:
> >
> >
> >
> > > EDIT LAST POST: The second "consumer" I meant to say provider.
> >
> > > On Apr 25, 12:55 pm, "J. Adam Moore"  wrote:
> > > > What I should have added was that using my solution, the consumer is
> > > > completely capable of being stupid and giving the consumer a redirect
> > > > that doesn't require a login on the consumer side, but they can also
> > > > take a gun and blow their brains out. You can't stop people from
> being
> > > > stupid and it's not the Providers job to even care if the redirect
> > > > they were given is secure.
> >
> > > > I'll say it again. I AM NOT CHANGING THE OAUTH MODEL. Everything
> works
> > > > exactly as before EXCEPT the request token HAPPENS AFTER
> > > > AUTHENTICATION ON THE PROVIDER SIDE. That is all. That fixes
> > > > everything. Triggering the authentication flow AS IT IS NOW from
> > > > behind a login ON THE PROVIDER SIDE. An attacker cannot generate a
> > > > reusable token or spoof/calculate an access token. Totally secure
> > > > would be the scenario I explained where both sites redirect behind a
> > > > login. It's simple. It's easy. Lets do it.
> >
> > > > On Apr 25, 12:41 pm, "J. Adam Moore"  wrote:
> >
> > > > > Logically I find that the only way to guarantee that two different
> > > > > users at two different sites are really the same person is to make
> > > > > them self authenticate BEFORE establishing a secure communication.
> By
> > > > > having both the Provider and Consumer redirect to a spot behind a
> > > > > login on both sites it fulfills this requirement without breaking
> the
> > > > > current model or people's brains. Making something simpler for the
> > > > > sake of simplicity is simply not a compelling argument against
> > > > > requiring habeas corpus at each end. I think too many people are
> > > > > trying to adjust the model instead of the implementation. The model
> is
> > > > > fine once you can prove (on each end) that it is the same user. Not
> > > > > caring what your login is on the consumer? What does that even
> mean?
> > > > > Either the redirect url is publicly accessible or it requires a
> login.
> > > > > I don't need to know WHO you are or care if you are logged in or
> not,
> > > > > but nothing is going to happen until you prove that you are who you
> > > > > 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 that doesn't add or take
> away
> > > > > anything from the current model. Basically a protocol that reorders
> > > > > passing information to occur after user authentication and tightens
> > > > > rules on where redirects point.
> >
> > > > > On Apr 25, 12:12 pm, Josh Roesslein  wrote:
> >
> > > > > > We don't really need the user to be logged into the consumer to
> > > generate our
> > > > > > token. The service provider should not care what our login is on
> the
> > > > > > consumer.
> > > > > > All it cares about is authorizing a consumer access to our data.
> We
> > > log into
> > > > > > the provider and authorize the creation of an access to

[oauth] Re: OAuth Security Advisory

[Josh Roesslein]

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 25, 2009 at 2:58 PM, J. Adam Moore  wrote:

>
> EDIT LAST POST: The second "consumer" I meant to say provider.
>
> On Apr 25, 12:55 pm, "J. Adam Moore"  wrote:
> > What I should have added was that using my solution, the consumer is
> > completely capable of being stupid and giving the consumer a redirect
> > that doesn't require a login on the consumer side, but they can also
> > take a gun and blow their brains out. You can't stop people from being
> > stupid and it's not the Providers job to even care if the redirect
> > they were given is secure.
> >
> > I'll say it again. I AM NOT CHANGING THE OAUTH MODEL. Everything works
> > exactly as before EXCEPT the request token HAPPENS AFTER
> > AUTHENTICATION ON THE PROVIDER SIDE. That is all. That fixes
> > everything. Triggering the authentication flow AS IT IS NOW from
> > behind a login ON THE PROVIDER SIDE. An attacker cannot generate a
> > reusable token or spoof/calculate an access token. Totally secure
> > would be the scenario I explained where both sites redirect behind a
> > login. It's simple. It's easy. Lets do it.
> >
> > On Apr 25, 12:41 pm, "J. Adam Moore"  wrote:
> >
> > > Logically I find that the only way to guarantee that two different
> > > users at two different sites are really the same person is to make
> > > them self authenticate BEFORE establishing a secure communication. By
> > > having both the Provider and Consumer redirect to a spot behind a
> > > login on both sites it fulfills this requirement without breaking the
> > > current model or people's brains. Making something simpler for the
> > > sake of simplicity is simply not a compelling argument against
> > > requiring habeas corpus at each end. I think too many people are
> > > trying to adjust the model instead of the implementation. The model is
> > > fine once you can prove (on each end) that it is the same user. Not
> > > caring what your login is on the consumer? What does that even mean?
> > > Either the redirect url is publicly accessible or it requires a login.
> > > I don't need to know WHO you are or care if you are logged in or not,
> > > but nothing is going to happen until you prove that you are who you
> > > 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 that doesn't add or take away
> > > anything from the current model. Basically a protocol that reorders
> > > passing information to occur after user authentication and tightens
> > > rules on where redirects point.
> >
> > > On Apr 25, 12:12 pm, Josh Roesslein  wrote:
> >
> > > > We don't really need the user to be logged into the consumer to
> generate our
> > > > token. The service provider should not care what our login is on the
> > > > consumer.
> > > > All it cares about is authorizing a consumer access to our data. We
> log into
> > > > the provider and authorize the creation of an access token for the
> consumer.
> > > > We then visit this consumer and hand over our token (either manually
> for
> > > > desktop apps or by being redirect by a callback w/ token attached).
> > > > The consumer can now access our data. It is up to the consumer now on
> how to
> > > > store this token.  (Here is a link to the flow:
> http://pastie.org/pastes/457478)
> >
> > > > I don't think preventing middle attacks or phishing is really what
> oauth
> > > > should be doing. SSL does this well and it should be used for the
> transfer
> > > > of the token
> > > > from the provider to the consumer. This way an attacker can't
> intercept the
> > > > token and use it to log in to the consumer under their account and
> access
> > > > our data on our provider account.
> >
> > > > The user can't be easily phished since both URL's (authorization URL
> and
> > > > callback URL) are verifiable by SSL. Also the callback is either
> stored on
> > > > the service provider or signed in the authorization request by the
> consumer.
> >
> > >

[oauth] Re: meeting notes from Friday

[Josh Roesslein]

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 to point out that anyone can organize one of these events
> wherever
> > they are — this need not happen in the Bay Area exclusively!
>
> We had a meeting in Mountain View on Friday, our notes are here:
> https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory.
>
> (Both of the proposals we focused on have already been discussed on
> this list in various forms.)
>
> >
>

--~--~-~--~~~---~--~~
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: OAuth Security Advisory

[Josh Roesslein]

We don't really need the user to be logged into the consumer to generate our
token. The service provider should not care what our login is on the
consumer.
All it cares about is authorizing a consumer access to our data. We log into
the provider and authorize the creation of an access token for the consumer.
We then visit this consumer and hand over our token (either manually for
desktop apps or by being redirect by a callback w/ token attached).
The consumer can now access our data. It is up to the consumer now on how to
store this token.  (Here is a link to the flow:
http://pastie.org/pastes/457478)

I don't think preventing middle attacks or phishing is really what oauth
should be doing. SSL does this well and it should be used for the transfer
of the token
from the provider to the consumer. This way an attacker can't intercept the
token and use it to log in to the consumer under their account and access
our data on our provider account.

The user can't be easily phished since both URL's (authorization URL and
callback URL) are verifiable by SSL. Also the callback is either stored on
the service provider or signed in the authorization request by the consumer.

On Sat, Apr 25, 2009 at 1:43 PM, J. Adam Moore  wrote:

>
> The idea is that the communication between the Consumer and Provider
> sites consist of urls that are composed behind user logins ON BOTH
> SITES at the same time. I believe that this prevents simpler attacks
> 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 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 likely an attacker can find a
> hole.
> > The double trip just creates a second chance for an attack.
> >
> > On Sat, Apr 25, 2009 at 12:33 PM, J. Adam Moore  >wrote:
> >
> >
> >
> > > I'm writing a blog post to explain why I think I have a solution, but
> > > I believe it is as simple as moving the provider login to before the
> > > consumer token generation which is triggered by a provider-side
> > > redirect. This is simply playing keep-away with redirects, but it
> > > arguably works if your goal is web-based "sudo" permissions for an app
> > > or site.
> >
> > > 1) User clicks on Consumer site link to Provider (no tokens or
> > > anything, just a request for a protected area on the site that IDs the
> > > Consumer)
> > > 2) Link is protected, requires login. (This should generate your
> > > session/user identifier)
> > > 3) Once logged in user is redirected (with a unique identifier,
> > > encrypted or not) back to a Consumer redirect page
> > > 4) Consumer generates request token and automatically redirects back
> > > to Provider's user authorization page
> > > 5) User approves access, Provider automatically logs user out,
> > > callbacks are optional.
> > > 6) Desktop apps can use a one-time-only password-reset-style cut-n-
> > > paste token IN THE NORMAL PASSWORD FIELD to authenticate.
> >
> > > There are many suggestions that duplicate tokens, information, or
> > > steps in the process. If the initial association of the process with a
> > > user is the problem, then requiring a login first will ALWAYS be the
> > > solution. The flow is fine as it is, with the small exception that the
> > > provider-side login requirement needs to be moved up in the process.
> >
> > > The game of keep-away doesn't hinge on obfuscation of the McGuffin,
> > > but in passing it outside of the reach of the attacker. If an attacker
> > > can use redirects to jump into the position of a player, then we can
> > > use redirects to never pass the McGuffin to the same position with the
> > > same info.
> >
> > > As far as I can tell there was only one INSIGNIFICANT flaw with OAuth
> > > and that was the Provider login requirement happening too late. That's
> > > it. Once you do that you can check the session or user, send nonces or
> > > encrypted user_ids with the initial redirect, or just about any crazy
> > > security measure you can think up.
> >
> > > Steps 3,4,and 5 are invisible to the user and end with a token that
> > > can be 

[oauth] Re: OAuth Security Advisory

[Josh Roesslein]

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 likely an attacker can find a hole.
The double trip just creates a second chance for an attack.

On Sat, Apr 25, 2009 at 12:33 PM, J. Adam Moore wrote:

>
> I'm writing a blog post to explain why I think I have a solution, but
> I believe it is as simple as moving the provider login to before the
> consumer token generation which is triggered by a provider-side
> redirect. This is simply playing keep-away with redirects, but it
> arguably works if your goal is web-based "sudo" permissions for an app
> or site.
>
> 1) User clicks on Consumer site link to Provider (no tokens or
> anything, just a request for a protected area on the site that IDs the
> Consumer)
> 2) Link is protected, requires login. (This should generate your
> session/user identifier)
> 3) Once logged in user is redirected (with a unique identifier,
> encrypted or not) back to a Consumer redirect page
> 4) Consumer generates request token and automatically redirects back
> to Provider's user authorization page
> 5) User approves access, Provider automatically logs user out,
> callbacks are optional.
> 6) Desktop apps can use a one-time-only password-reset-style cut-n-
> paste token IN THE NORMAL PASSWORD FIELD to authenticate.
>
> There are many suggestions that duplicate tokens, information, or
> steps in the process. If the initial association of the process with a
> user is the problem, then requiring a login first will ALWAYS be the
> solution. The flow is fine as it is, with the small exception that the
> provider-side login requirement needs to be moved up in the process.
>
> The game of keep-away doesn't hinge on obfuscation of the McGuffin,
> but in passing it outside of the reach of the attacker. If an attacker
> can use redirects to jump into the position of a player, then we can
> use redirects to never pass the McGuffin to the same position with the
> same info.
>
> As far as I can tell there was only one INSIGNIFICANT flaw with OAuth
> and that was the Provider login requirement happening too late. That's
> it. Once you do that you can check the session or user, send nonces or
> encrypted user_ids with the initial redirect, or just about any crazy
> security measure you can think up.
>
> Steps 3,4,and 5 are invisible to the user and end with a token that
> can be used as a temporary password which triggers token authorization
> and association with a seamless manual option that appears to jump
> straight to step 6. Because all of this is happening behind a Provider
> login, it is as secure as you're going to get it without fundamentally
> changing the structure of the whole process.
>
> >
>

--~--~-~--~~~---~--~~
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: OAuth Security Advisory

[Josh Roesslein]

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 parameter
(oauth_callback_data) which the
consumer could set that will be returned back on the callback. This of
course would have to be signed still since an attacker could figure out what
this data does and exploit it in some way.

With the way I outlined the flow their is no pin exchange. The user by
agreeing to generate a token for the consumer is enough. We know by signing
that the
consumer the token is being generated for can only be used by that consumer.
Their is no need to exchange a pin to verify this consumer.
Once the callback is executed with the access token attached, it is now up
to the consumer to properly use this token. They must either bind it to an
account by having the user
login on the callback(or use a cookie session if the user logged in before
starting the oauth flow) or by creating a temporary session and binding the
token to that. Since the callback can't be
tampered with (it's registered with the SP) we know the user will be
directed to the correct location with their new token. We could for extra
security return an "authorization token" instead that must be
swaped by the consumer for the final access token for some extra security.

On Sat, Apr 25, 2009 at 5:34 AM, Rob Richards wrote:

>
> pkeane wrote:
> >
> > This seems like it addresses the the hole adequately as long as  an
> > attacker that cannot manipulate the callback url cannot succeed (I
> > think that's true...).
> >
> > Further thought on this whole thing makes me think that a one-time
> > only token exchange plus a non-modifiable callback are what's needed.
> > Maybe OAuth++ or somesuch can provide an extra authentication piece on
> > the front end for providers wishing to require that.  Also, making it
> > very explicit on the provider's OAuth page that the user is
> > establishing an authenticated access agreement between the Consumer
> > app and the Service Provider  that *they* own (i.e., are responsible
> > for, can revoke at any time,etc.).  I also think (as I have said
> > before) that the spec should be explicit about the social engineering
> > exploits that are possible.
> >
> >
> >
> I have to agree with you on the one-time token exchange, but as you had
> mentioned before, mandate it between the consumer and SP. It really
> should be some code/pin/session key (whatever you want to call it) that
> the user enters on the consumer side. This would then need to be entered
> on the SP side as well. Currently there is not enough human integration
> within the flow. With this type of flow, the SP knows or at least can
> expect that the user trusts the consumer to some degree because they
> gave the same key to both parties. Wording on the SP's page of what is
> going on is not enough. The user also needs to be actively involved with
> the consumer simply is not enough imho.
>
> There seemed way too many responses to your original proposal that it
> would cause a bad user experience. I really don't see how requiring the
> user to enter some additional piece of information in an extra step is
> enough to cause a bad user experience compared to the additional
> security it provides. This step really should not be optional or an
> additional extension as there should be a consistent experience the user
> can come to expect. The user should know that regardless of how
> authentication is handled by the SP, this key is always going to be
> required by them during the flow.
>
> Too many people want simplicity at the sake of security. I am a strong
> advocate of Information Cards. Its central focus is the user; the user
> is the central point for flow of information. At every point they know
> who is getting what and why. The technology used is complex and
> unfortunately its not widely available for usage yet. I would hope tough
> that it at least serves as a model to show how important the user is and
> that they should be more engaged in the aware of what is happening
> around them.
>
> Rob
>
> >
>

--~--~-~--~~~---~--~~
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: OAuth Security Advisory

[Josh Roesslein]

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 be possible to just use a single URL that you register with the
provider. I just can't think of an use case that would require a dynamic
callback.

On Sat, Apr 25, 2009 at 12:00 AM, Dossy Shiobara  wrote:

>
> On 4/25/09 12:31 AM, pkeane wrote:
> > If I am following correctly, this should work.  But there are a few
> > drawbacks I see.  It is fairly dramatically different from the way
> > OAuth works now for all parties: user, consumer, provider.
>
> Right.  OAuth, as it is specified in 1.0, has flaws that will require
> changes that affect all parties.
>
> > It also seems quite complex (maybe I am being dense :) to me, a
> > hallmark of a good security scheme is simplicity and clarity to the
> > extent possible.
>
> I dunno, it seems remarkably simple to me.  Matter of fact, I don't see
> any ways to make it any simpler without losing important security.
>
> --
> 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: OAuth Security Advisory

[Josh Roesslein]

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 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 signing the authorization
> request we prevent the callback from being tampered with.
>
> Compared with the solution I presented this would probably be easier to
> apply. The way I specified does eliminate the need for the request token and
> helps shorten the flow, but
> would require some major changes. Perhaps this could be something we can do
> in 2.0 spec. For a quick fix this idea would work and I don't see any
> security flaws in it.
> As long as the authorization token is random enough, the attacker can't
> really guess it.
>
>
> On Fri, Apr 24, 2009 at 9:36 PM, Zachary Voase 
> wrote:
>
>>
>> I'd like to propose the following flow (which is basically an
>> amalgamation of a few ideas throughout this thread):
>>
>>1) User visits Consumer's website, Consumer gets request token
>> from Service Provider.
>>2) Consumer sends user to the Service Provider's user auth URL,
>> with 'oauth_token' and 'oauth_callback' as before but also
>> 'oauth_signature' and 'oauth_signature_method' parameters.
>> Alternatively, 'oauth_callback' may be omitted if the Consumer has pre-
>> specified a callback URL with the Service Provider. Both of these
>> methods prevent the attacker from spoofing a callback.
>>3) User logs in to the Service Provider (if necessary) and grants
>> access to the Consumer.
>>4) Service Provider generates a nonce, and if the callback was
>> specified (with either the 'oauth_callback' parameter or when the
>> Consumer signed up to the Service Provider), the User is redirected to
>> the callback with 'oauth_token' and 'oauth_callback_nonce' parameters.
>> If no callback is specified, the Service Provider gives the User the
>> nonce to enter into their desktop application, etc.
>>5) The Consumer then attempts to exchange the old request token
>> for a new access token, including the 'oauth_callback_nonce' in the
>> parameters for this request. This exchange may only be attempted once
>> for a single request token, after which it will any subsequent
>> attempts with the same request token will fail unconditionally. In
>> addition, the callback nonce must be present and correct. Since the
>> attacker in the session fixation trick doesn't know this parameter
>> (and indeed *cannot* know this parameter), (he/she/it) cannot attempt
>> to get the access token (which would originally have been done by
>> visiting the Consumer's callback URL).
>>
>> In the case of a desktop application, the User would have the callback
>> nonce displayed to them by the Service Provider and would have to
>> enter it manually into the application. The Service Provider has the
>> responsibility of making it *crystal clear* to the User that this
>> should be kept secret. It's a lot easier to get the User to keep the
>> callback nonce a secret than it is to get them to think critically
>> about the Consumers they authorize.
>>
>> Can anyone find a security hole in this workflow?
>>
>> Regards,
>> Zack
>> >>
>>
>

--~--~-~--~~~---~--~~
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: OAuth Security Advisory

[Josh Roesslein]

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 signing the authorization request
we prevent the callback from being tampered with.

Compared with the solution I presented this would probably be easier to
apply. The way I specified does eliminate the need for the request token and
helps shorten the flow, but
would require some major changes. Perhaps this could be something we can do
in 2.0 spec. For a quick fix this idea would work and I don't see any
security flaws in it.
As long as the authorization token is random enough, the attacker can't
really guess it.

On Fri, Apr 24, 2009 at 9:36 PM, Zachary Voase wrote:

>
> I'd like to propose the following flow (which is basically an
> amalgamation of a few ideas throughout this thread):
>
>1) User visits Consumer's website, Consumer gets request token
> from Service Provider.
>2) Consumer sends user to the Service Provider's user auth URL,
> with 'oauth_token' and 'oauth_callback' as before but also
> 'oauth_signature' and 'oauth_signature_method' parameters.
> Alternatively, 'oauth_callback' may be omitted if the Consumer has pre-
> specified a callback URL with the Service Provider. Both of these
> methods prevent the attacker from spoofing a callback.
>3) User logs in to the Service Provider (if necessary) and grants
> access to the Consumer.
>4) Service Provider generates a nonce, and if the callback was
> specified (with either the 'oauth_callback' parameter or when the
> Consumer signed up to the Service Provider), the User is redirected to
> the callback with 'oauth_token' and 'oauth_callback_nonce' parameters.
> If no callback is specified, the Service Provider gives the User the
> nonce to enter into their desktop application, etc.
>5) The Consumer then attempts to exchange the old request token
> for a new access token, including the 'oauth_callback_nonce' in the
> parameters for this request. This exchange may only be attempted once
> for a single request token, after which it will any subsequent
> attempts with the same request token will fail unconditionally. In
> addition, the callback nonce must be present and correct. Since the
> attacker in the session fixation trick doesn't know this parameter
> (and indeed *cannot* know this parameter), (he/she/it) cannot attempt
> to get the access token (which would originally have been done by
> visiting the Consumer's callback URL).
>
> In the case of a desktop application, the User would have the callback
> nonce displayed to them by the Service Provider and would have to
> enter it manually into the application. The Service Provider has the
> responsibility of making it *crystal clear* to the User that this
> should be kept secret. It's a lot easier to get the User to keep the
> callback nonce a secret than it is to get them to think critically
> about the Consumers they authorize.
>
> Can anyone find a security hole in this workflow?
>
> Regards,
> Zack
> >
>

--~--~-~--~~~---~--~~
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: OAuth Security Advisory

[Josh Roesslein]

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 was registered. Could also
support dynamically setting callback by including
it in the authorization URL and signing it.

The flow would be:
User visits consumer --> Consumer directs user to authorization URL --> User
authenticates with service provider --> Grant access to consumer -->
Directed back to consumer with access token

By not having request tokens, an attacker can't really get into the flow.
There are two issues:

1. Service providers and Users must watch out for bad consumers that
register with the service provider. This can be avoided by
proper screening by the service provider (make sure the consumer is
legit) and the User knowing the consumer they are granting access.

Example:

- Attacker sends user this link:
http://www.serviceprovider.com/oauth/authorize?consumer=badconsumer.com
- User authenticates and grants access
- Directed to bad consumer site with access key
- Bad consumer steals private data with access key

   To fix attack:
- Delete consumer account on service provider
- Invalidate all access tokens generated by this consumer account

2. The token can be stolen by a man in the middle attack during the
callback. This can be avoided by using https.

On Fri, Apr 24, 2009 at 4:59 PM, pkeane  wrote:

>
>
>
> On Apr 24, 3:23 pm, joshthecoder  wrote:
> > Actually after some more thought I have come up with this new
> > revision:
> >
> > 1. User visits authorization URL that directs them to the service
> > provider's site.
> >This link can be provided by the consumer.
> >Example:
> http://www.pictureland.com/oauth/authenticate?consumer=printit.com
> > 2. User authenticates with service provider.
> > 3. User authorizes access to the consumer. Optionally this page can
> > also be used
> >for setting other restrictions (ex. lifetime of token, resource
> > access rights, etc)
>
> Am I correct in characterizing #2 & #3 as collapsing the OAuth A & B
> steps into one interaction.  Or perhaps more accurately, eliminating
> step A (getting a request token that will need to be authorized) and
> going right to B & C?
>
> --peter
>
> > 4. Service provider generates access token (only usable by the
> > consumer)
> > 5. User redirected to consumer URL with token attached.
> >Example:http://www.printit.com/oauth/regiser?token=12345
> > 6. Consumer can optionally have user login and bind token with the
> > account
> >OR
> >Create session cookie stored in browser and token is bound to this
> > session.
> > 7. Consumer can now use token to access protected resources.
> >
> > This way the service provider does not have to manage consumer account
> > <--> service account relationships.
> > It simply generates a token for a specific consumer and then redirects
> > user with token to consumer provided URL.
> > It is now up to the service provider to bind this token to an account
> > or session.
> >
> > To prevent man in the middle attack of stealing this token, this
> > callback URL should use SSL.
> >
> > On Apr 24, 3:07 pm, joshthecoder  wrote:
> >
> > > How about this idea...
> >
> > > Instead of the Request token --> Redirect to Service provider w/ token
> > > process how about just redirecting
> > > straight to the service provider with just the consumer ID in the
> > > URL.
> >
> > > 1. User visits Consumer site and can optionally register an account.
> > > 2. Consumer registers account or pin with Service provider by making
> > > request.
> > > 3. User visits the generated URL from the consumer (ex.
> http://www.pictureland.com/oauth?consumer_id=)
> > > 4. User authenticates with Service provider
> > > 5. User directed to consumer authorization page on Service provider
> > > where they must enter in the username or PIN for the consumer (more on
> > > PINs later)
> > > 6. User enters in username or pin # and clicks authorize (optionally
> > > can also select access restrictions for the consumer on this page
> > > also)
> > > 7. Service provider validates username / pin and if valid calls
> > > consumer callback URL with access token included
> > > 8. User redirected to consumer
> > > 9. Consumer can now use access token
> >
> > > Pins: Allow for authorizing consumer access w/o having to create an
> > > account. Pin is generated by consumer and then registered with service
> > > provider.
> > >   User must then copy and paste pin into authorization page on
> > > service provider.
> >
> > > Here is a diagram displaying this process (using username method):
> http://i42.tinypic.com/2uqlimd.png
> >
> > > So what is do you think?
> >
> > > On Apr 24, 2:43 pm, Luca Mearelli  wrote:
> >
> > > > On Fri, Apr 24, 2009 at 8:03 PM, Brian Eaton 
> w