[oauth] Re: C# OAuthBase.cs bug

[jr conlin]

You may want to use the OAuthBase.UrlEncode() method for this. I know 
that C# tends to use lowercase hex for values where OAuth prefers 
uppercase. This way, you know that the signature value being generated 
will match. (Yes, I realize that the values are also read opaquely and 
case doesn't matter, but it's also good to be consistent.)



rjlopes wrote:
> Hi,
>
> I was testing the OAuthBase and find out a bug when using it with
> MySpace.
>
> The problem is that MySpace uses an url as oauth_consumer_key and the
> NormalizeRequestParameters doesn't encode the parameters values.
>
> The fix is really simple, just change:
>
> sb.AppendFormat("{0}={1}", p.Name,p.Value);
>
> to:
>
> sb.AppendFormat("{0}={1}", p.Name, UrlEncode(p.Value));
>
> >
>
>   


--~--~-~--~~~---~--~~
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: Improved User Experience for Installed Applications using OAuth

[jr conlin]

Nathan Beach wrote:
> Google has enhanced our OAuth approval flow to significantly improve 
> the user experience for installed applications that use OAuth to 
> access our GData APIs.
Perhaps I'm missing something, but doesn't this kinda saw one of the 
legs off of OAuth?

This approach basically is:  Everyone gets in using the same key, we'll 
do our best to keep users from using your app, but if they do, you'll be 
able to get their info.

We may be the off case, but we're actually kind of interested in using 
the two legged approach so that we can validate developers and grant 
some customers adjusted rates. What this approach says is "There's no 
way to secure the first leg of OAuth, so we're going to ignore that." 
Frankly, it kind of makes me wonder why bother using OAuth at all? 
Couldn't you simply create a new auth protocol where an app uses https 
to connect and "authorize" and then stores a returned token set you can 
use to validate future requests?

It may just be that there are certain environments that one can't do 
OAuth. I'd rather that folks use a different auth mechanism for those 
than further confuse the standard.

I really don't want to be a protocol dork here, but this sets off a good 
many paranoid bells in my head.


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

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

[JR Conlin]

Partly because the authors weren't interested or didn't have the time. 
Partly as a personal exercise to learn new languages. Partly to 
understand the protocol in real, practical terms, and partly because 
like you, I believe it's better to just shut up and do something rather 
than whine or bitch at others to do it. I'd love to get some help, but 
I'm not fretting if I don't.

To address Hans' question, my goal is to provide a reasonably common 
library that folks can give the same sort of inputs and get the same 
sort of outputs. I'm focusing on client only services since that's going 
to be the larger audience. Programmers (like Kent) don't care what the 
minutia of OAuth is. They just want to get to people's address books, 
movie listings, or whatever crap OAuth grants them access to with the 
least amount of hassle.

The libraries all take the same set of arguments (in a few different 
ways based on what folks are most comfortable using).

The libraries all return (as much as they can) a hash of:

the fully signed and qualified GET URL (pop it into your web call of 
choice and it should just work)
the Header arguments (if you prefer using those instead).
the signature value (if that's all you wanted)
and an array of escaped parameters (should you want to construct the 
POST or other fetch)

Right now, it's limited to just HMAC-SHA1, but again, that's what most 
services are using. I can add in RSA or other encryption easily enough.

A lot of the other libraries are very good, if possibly providing more 
than most folks need or want. I'm currently working on the .Net library 
since that's where folks that are using our services are having the most 
amount of problems with. I'm building this stuff in my 'off hours' which 
means that I don't always have 40 hours a week to devote to it, and I 
may go days without doing something. Since there's no pressing demand, 
I'm not particularly worried about getting these out quickly.

Eran Hammer-Lahav wrote:
> Why alone? Did you try to partner with more people and no one was interested?
>
> EHL
>
>   
>> -Original Message-
>> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
>> Of JR Conlin
>> Sent: Wednesday, April 29, 2009 8:41 PM
>> To: oauth@googlegroups.com
>> Subject: [oauth] Re: True OAuth Confessions, or Why My Hand-Rolled
>> Calls All Blew Chunks
>>
>>
>> Eran Hammer-Lahav wrote:
>> 
>>> This is my favorite thread theme to bark at.
>>>
>>>   
>>> 3. Libraries are Shit
>>>
>>> Some are. How about write a new one or fix an existing one? How about
>>> just ask the developer for help? People always bring up the idea of a
>>> uniform interface across libraries which is a great idea, but no one
>>> actually put any effort into this.
>>>   
>> Actually, I am trying to do something about this, so you're wrong about
>> "no one". Trying to figure out the various nuances of languages I've
>> not
>> programmed in before is a bit of a trick so it's taking me longer to
>> build them than I'd prefer.
>>
>>
>>
>> 
>
> >
>
>   


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

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

[JR Conlin]

Eran Hammer-Lahav wrote:
> This is my favorite thread theme to bark at.
>

> 3. Libraries are Shit
>
> Some are. How about write a new one or fix an existing one? How about 
> just ask the developer for help? People always bring up the idea of a 
> uniform interface across libraries which is a great idea, but no one 
> actually put any effort into this.
Actually, I am trying to do something about this, so you're wrong about 
"no one". Trying to figure out the various nuances of languages I've not 
programmed in before is a bit of a trick so it's taking me longer to 
build them than I'd prefer.


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

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

[jr conlin]

Kent Brewster wrote:
> I don't think I'm alone in this; there have to be developers out there
> who have never touched OAuth and are under terrific pressure to get it
> working right freaking now.  For them it's much less important to know
> how a thing works than it is how to work it.  Does that make sense?
>
>   
No, you're not alone. It's an argument I tend to make a good deal, but 
generally get dismissed about.

OAuth is a tool. It's part of a solution. As anyone who's ever worked at 
a Sears can tell you, people will use screwdrivers as hammers, chisels 
and pry bars even though that's not what the tool was originally 
designed to do. If your tool isn't simple enough for them to use and 
doesn't provide what they'd expect, they'll move on to a different tool.

OAuth isn't the only solution out there. There are others. The value of 
those other tools can be argued ad much as the value of OAuth can be. 
Demanding additional effort for seemingly minor return simply makes 
those other tools more attractive.

Consider it this way, there are lots of ways of making the Betamax far 
better, but does it really matter?

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

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

[jr conlin]

Agreed.

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

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


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

[oauth] Re: OAuth Security Advisory

[JR Conlin]

Brian Eaton wrote:
> There are a few options.
>
> 1) Keep using OAuth 1.0.
>SPs can tell users that they are authorizing an application on
> their desktop.  There is some risk of social engineering as you
> describe, but hopefully the language on service provider pages
> mentioning desktop applications will help.
>
> 2) Callback token displayed on page.
>SPs can display a callback token, which the user will manually
> enter into their desktop application.  This is not a good user
> experience, but provides better security than option 1.
>
> 3) Callback token sent to desktop app.
> There are a bunch of ways to get a callback token to a desktop app
> automatically, most of them mentioned earlier in this thread.
>   
4) The Callback URL is registered with the Provider at the time that the 
Consumer Key and Secret are issued.

This is pretty much what Facebook does and removes the idea of having 
the callback appearing anywhere in the handshake. Yes, it means that you 
can't have pure, dynamically generated URLs. Yes, it means extra work 
and storage for service providers. It also means that the end user 
doesn't have to do anything extra in order to continue using OAuth, 
which should be one of the bigger goals.

I'm pretty sure I'm missing something here, so feel free to chime in why 
this is dumb.

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

[JR Conlin]

Mike Malone wrote:
> On Thu, Apr 23, 2009 at 12:03 PM, Brian Eaton  > wrote:
>
>
> On Thu, Apr 23, 2009 at 11:54 AM, Mike Malone  > wrote:
> > In the manual case the user is already typing the request token key
> > manually.
>
> The manual case is not a good user experience, and it isn't necessary
> for the vast majority of installed applications:
> https://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps
>
> Pownce and several other companies have written iphone, android, and
> blackberry apps that bypass the manual token entry step.
>
>
> Er, right. Sorry. I was thinking of the Netflix style case. You're 
> right, for many Desktop apps manual entry of the request token key is 
> not required.
Netflix doesn't require the end-user to enter a token. The user login 
and confirmation is done via a separate request (something that we get a 
lot of heat about) invoked by the client.

Most of the apps we have register a local handler and then use that as 
the associated callback.

One other thing to note is that the more steps you require the end user 
to perform, the less likely they are to complete the 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: Twitter OAuth Direct Access

[JR Conlin]

If I may, no, actually, it's not a neat idea.

There's a big difference between OAuth credentials and your username and 
password. OAuth credentials aren't really designed to be completely 
secure, and you should be able to easily generate a new shared secret 
should your old one be compromised in some manner. (e.g. you suddenly 
realize that putting both of these in some Javascript code on your site 
is a bad idea when you find out your usage goes through the ceiling 
after someone posts your code to 4chan.)

If your OAuth credentials are your username and password, you kinda lose 
the ability to reset things should they go horribly wrong.

There's also some merit to the idea that when you get credentials for a 
three legged lookup, the person giving you the credentials should be 
able to say "Uhm, no, just call me that long string of gobbledy-gook. I 
don't want you to have my name, email, or anything else." Granted, it's 
rare, but different people have very different views on what information 
they want to hand out.

I'll be honest. Facebook Connect is certainly easy to implement and use, 
but it absolutely scares the crap out of me what someone could do with 
that if they were malicious. Likewise, Twitter has created the really 
horrible behavior pattern of "Go ahead and give your username and 
password to whoever asks for it". Oauth is a bit better in that it is a 
way to have users agree to share information, but as some folks note, 
it's far from perfect and has it's own behavioral problems.

Your credentials, regardless of form, are the keys to that bright, shiny 
Ferrari that's hopefully in your driveway and not mowing down 
pedestrians with a full complement of police chasing after it because 
you left the doors open and the motor running.

CA Meijer wrote:
> Cool, thanks for the info.  It's kind of a pity; it was a good vision
> and a neat idea.
>
>
> On Mar 8, 8:39 pm, Eran Hammer-Lahav  wrote:
>   
>> This statement was more 'vision' than 'practice'. I'll adjust it to correct 
>> this misconception. The idea is that OAuth *could* be used in such a way, 
>> but as far as I know, no one is applying it like that.
>>
>> EHL
>>
>> 
>>> -Original Message-
>>> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
>>> Of CA Meijer
>>> Sent: Sunday, March 08, 2009 11:01 AM
>>> To: OAuth
>>> Subject: [oauth] Re: Twitter OAuth Direct Access
>>>   
>>> Thanks for the reply. I think that I understand your point but it
>>> seems somewhat at odds with the following sentence in the basic guide:
>>> "When OAuth is used as a direct replacement of HTTP 'Basic', the
>>> Consumer Key and Consumer Secret should hold the username and
>>> password, and the Token and Token Secret should remain empty."
>>>   
>>> If I want to update my status at Twitter, using my username and
>>> password in the "consumer parameter" seems (1) consistent with the
>>> quote above and (2) an inherently sensible choice.
>>>   
>>> Is it impossible to use "OAuth as a direct replacement of HTTP
>>> 'Basic'" at twitter?  Or am I missing something completely trivial?
>>>   
>>> On Mar 8, 6:20 pm, Eran Hammer-Lahav  wrote:
>>>   
 It doesn't refer to the idea that you can put your basic-auth
 
>>> credentials and just stick them into random parameters. The idea of
>>> direct access is when the application want to call the service without
>>> a user-context. That is, to perform some administrative work related to
>>> the service but not on behalf of a user. In the case of Twitter, the
>>> only thing you can put in the consumer parameter is something Twitter
>>> gives you when you register a new application.
>>>   
 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: OAuth for PHP4

[jr conlin]

If I remember php4, yes, you should quote those if you don't want the 
warning messages in the error log.

You can also turn off warnings in your php configuration files.

Zhihong wrote:
> Thanks for the information.
>
> I am glad I didn't try to port it to PHP 4. Sounds like a project I
> did to port C++ to C.
>
> I tried that library from iamcal.com, it's really nice and clean.
> However, it prints warnings like this,
>
> Notice:  Use of undefined constant oauth_key - assumed
> 'oauth_key' in /home/zhang/cvswork/idp/trunk/tools/api-client/src/
> main/php4/lib_oauth.php on line 41
>
> This is the line,
>
> $oauth_params['oauth_consumer_key'] = $key_bucket
> [oauth_key];
>
> I don't know PHP much. Should the 'oauth_key' be quoted?
>
> Thanks for the help!
>
> Zhihong
>
>
> On Mar 5, 11:18 am, kellan  wrote:
>   
>> https://svn.iamcal.com/public/php/lib_oauth/
>>
>> The terminology is a bit quirky, but the basic functionality is there,
>> and nicely light weight
>>
>> -kellan
>>
>> On Thu, Mar 5, 2009 at 10:35 AM, Zhihong  wrote:
>>
>> 
>>> Does anyone have an OAuth library that works in PHP4?
>>>   
>>> We have a client who is entrenched in PHP4. They already use OpenSSL
>>> so all the crypto functions are there. I don't think it would be hard
>>> to port current OAuth library to PHP4, is it?
>>>   
>>> Thanks!
>>>   
>>> Zhihong
>>>   
> >
>
>   


--~--~-~--~~~---~--~~
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: Duplicate Parameters

[JR Conlin]

Zhihong wrote:
> What's OAuth's rule on duplicate parameters? Any parameter can appear
> in query string, Authorization header or post body. What happens if
> the same parameter (say oauth_version) appears in more than one place?
>   
if I remember correctly, non oauth parameters are sorted by key value, 
then value, so
http://example.com?a=1&foo=bar&foo=gorp&a=1
would be signed as
http://example.com?a=1&a=1&foo=bar&foo=gorp

oauth_* parameters should not be duplicated, but if they were, I'd 
imagine that most libraries would sort them according to similar rules. 
The obvious reason that the oauth_* parameters shouldn't be duplicated 
is that there's no telling which token or secret would be used.

> I tried to find some guidance in the spec with no avail. Our current
> implementation allows duplicate parameters as long as signature counts
> for the duplication (the parameters is repeated in base string).
> However, it's still a mystery which one takes precedence if they have
> different values. In my opinion, this should be cleared banned in 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: OAuth FAIL

[JR Conlin]

The biggest complaint I hear about is the confusion around "consumer 
key" vs. "oauth token".

For Netflix, the problem is determining who the consumer is, often with 
the individual creating the third party app to be sold on iPhones 
inevitably getting it wrong.

We use API Key and secret for the Consumer Key and Shared Secret along 
with Access Token and Access Secret for the OAuth Token and OAuth 
Secret. We do that because we use two legged OAuth for information that 
doesn't involve our customers and three legged for info that does. By 
and large, most folks get it.

Obviously "API Key" doesn't work for services that don't provide them, 
but they should be named something a bit more descriptive and less 
confusing, possibly "primary" and "secondary" to indicate how they're 
generally used.


Eran Hammer-Lahav wrote:
> I am getting ready to making a complete rewrite of the current OAuth spec.
> The idea is to make it much easier to read without changing anything that
> will impact implementation. This will be useful both for clarity but also as
> a better starting point for the upcoming OAuth effort at the IETF.
>
> What I would like to ask people who have read the spec or implemented it to
> share as many problems, errors, failures, mistakes, misunderstandings,
> wasted time, etc. caused by the spec not being clear enough.
>
> You can simply describe the error (did not sort parameter, did not %-encode,
> %-encoded twice, etc.) or the section of the spec you had to read 325 times
> before it made any sense.
>
> Please reply to this thread so we have a public inventory of OAuth FAILs.
>
> 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: OAuth-like user experience examples

[jr conlin]

Christian Scholz / Tao Takashi (SL) wrote
> So I am wondering in the iPhone case how I can be sure that I am 
> really at yahoo and not somewhere else. I don't see any URL, whether 
> it's SSL or not etc. and even if I would this application could of 
> course fake this as well (which I guess is also the point in [1]). So 
> I agree with [1] that a better way would be something inside the OS to 
> provide that but that this of course also might not happen (or at 
> least soon).
Yep. Granted, that's been kind of a rallying cry for the folks that are 
against OAuth. "You could easily phish credentials because nobody ever 
looks at the URL line anyway." There are ways to tokenize the login page 
(e.g. what Yahoo does with the login) but that only works on devices 
where you've created a common cookie which means that devices or 
programs that have a sandboxed webkit would never get that info.

Facebook isn't immune to this issue either, and in fact, kind of makes 
it worse by having an inconsistent log in experience. Sometimes it's a 
pop out window, sometimes it's an iframe. Sometimes it asks you to log 
in, other times it asks you to just auth.

I don't want to wave my hands at the problem, but the solution is going 
to require more than just OAuth and Facebook. It's going to require 
working with browser manufacturers to make sure that there's a reliable 
way to indicate to users the host and URL they're connected to.
>
>
> I also see this more as a problem for e.g. the iPhone where you 
> usually need to close the application in order to jump to safari. This 
> is not such a problem on the desktop and (as you demonstrate) has been 
> done for quite a while with flickr.
If I remember correctly (I don't have a mac so no iphone SDK for me) 
it's possible to register a fake protocol which will allow you to jump 
back into your app. Most of the Netflix iPhone apps do something like 
this to do the auth.
>
> I also agree with [2] that authenticating for multiple services might 
> make this whole process a bit annoying. We might also face this issue 
> in the proposed MMOX IETF working group[3] if we go with OAuth and in 
> order to connect to a world you might first need to authorize various 
> services (profile, inventory, contacts, IM, ...).
I'm actually alright with that idea. Let me be in control of my own 
data. If you have the additional concept of "profiles", where I can give 
some inquiring service a slightly different identifier that's tied to a 
specific "group" of permissions, then it's not as much a hassle as it 
might be. (e.g. I give a site like Blizzard "jrconlin-max" and expose 
every bit of data, or I give a site like http://EvilOnAStick.com 
"jrconlin-rhubarb" which has a greatly reduced set of available 
information.)
>
> -- Christian
>
> [3] http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter
>
>
>
> Chris
>
> [1] http://blog.atebits.com/2009/02/fixing-oauth/
> [2] https://twitter.pbwiki.com/oauth-desktop-discussion
>


--~--~-~--~~~---~--~~
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: OpenID Guides

[jr conlin]

I think the #1 thing to keep in mind regarding OAuth is that it's not 
the sum total of what folks will be doing.

We all tend to be a little steeped in things here, but in many respects 
the OAuth specs are a bit like telling folks interested in building 
houses how to forge the steel for making their hammers. Regardless of 
how simple or complicated OAuth happens to be, it's just one tiny part 
of a much larger solution.

People also have a really hard time thinking in abstract. Where Facebook 
wins is that they present effectively a single solution to the problem 
of "Who is this person?" For site owners, they don't have to worry about 
user management since all that is now someone else's problem. The recent 
OpenID+OAuth+PortableContacts solution is a good first step, but it 
still doesn't make the lives of site operators all that much easier. 
Sure, accepting IDs from sites like Yahoo and Google are easy, but what 
about delphicresearch.com, unitedheroes.net, or gnomebondage.com? (Ooh, 
EvilOnAStick.com was available? Look out Billy Mayes!)

The best way to get this stuff out there and used is to make it damn 
easy.  It's why I keep pushing for a set of common libraries that folks 
can hook into. Is it easier to worry about SBS double escape issues and 
XRDS specifications, or call something like

user = OpenConnect(userId).userInfo;
if (user.isValid) {
print "Hello " + user.fullName();
}


The sooner we can get beyond defining the OSHA standards for carbon 
content of hammers, the sooner we can start building really useful stuff.


Chris Messina wrote:
> I just discovered this site and thought that it was something that we 
> really should continue doing for OpenID (and OAuth):
>
> http://guides.rubyonrails.org/
>
> After reading Joseph's blog post yesterday:
>
> http://josephsmarr.com/2009/02/17/implementing-oauth-is-still-too-hard-but-it-doesnt-have-to-be/
>
> It's clear that we must make these technologies easier to implement, 
> and we can start by making more tools and recipes available.
>
> As you're doing your own implementation, please share feedback and 
> your own approaches and take notes along the way where things didn't 
> make sense or where the specs weren't clear. It would be great to get 
> this feedback in one place, and then write documentation to help 
> others avoid similar pitfalls. 
>
> Feel free to use the respective wikis to documents these issues.
>
> Thanks!
>
> Chris 
>
> -- 
> Chris Messina
> Citizen-Participant &
>  Open Web Advocate-at-Large
>
> factoryjoe.com  # diso-project.org 
> 
> citizenagency.com  # vidoop.com 
> 
> This email is:   [ ] bloggable[X] ask first   [ ] private
>
> >


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

[oauth] Re: OAuth Test Page

[JR Conlin]

Odd, I just hit that page and got HTML source code. Looks like the 
Content-Type is set to: text/plain.

Looks like it should work just fine, though. Cool! Thanks to whoever set 
that up. Having more than one tool means that at least one is always 
available.

John Kristian wrote:
> There's another test tool at 
> http://oauth.googlecode.com/svn/code/javascript/example/signature.html
>
> On Feb 4, 3:29 pm, jr conlin  wrote:
>   
>> http://developer.netflix.com/resources/OAuthTest
>>
>> provides a third party page to prove your OAuth HMAC-SHA1 signature
>> generation, and allows you to set the nonce and timestamp in order to
>> validate that your signature matches the signature I'm generating.
>> 


--~--~-~--~~~---~--~~
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 Test Page

[jr conlin]

Yep, caught that bug when I was adding the "advanced" section. (it's in 
gray toward the bottom right).
I'll also add the Version string as a static field.

thanks!

Seth Fitzsimmons wrote:
> Fair enough.
>
> Upon further investigation, the "nonce" and "timestamp" fields aren't
> being respected (they're being generated regardless of input).
>
> seth
>
> On Wed, Feb 4, 2009 at 4:10 PM, jr conlin  wrote:
>   
>> Sure, I'll see what I can do about dumping that. (Possibly as an
>> "advanced" feature.)
>>
>> The API Key /Shared Secret is something that we use, partly because we
>> discovered a good deal of confusion about what "consumer" meant. (For
>> that matter, folks didn't understand the difference between "oauth" and
>> "consumer" either and would frequently swap them.) Since we provide the
>> key/secret with that term, I stuck with it here.
>>
>> Seth Fitzsimmons wrote:
>> 
>>> Hey JR.
>>>
>>> This is great.  It would be really helpful if you dumped the
>>> normalized parameter string and the signature base string as well as
>>> allowing the method to be overridden.  I've found that the signature
>>> base string is usually the piece that doesn't match between
>>> implementations, so being able to compare them is really valuable.
>>>
>>> Is there a reason that you're using the "Api key" / "Shared secret"
>>> terminology instead of "Consumer key" / "Consumer secret"?
>>>
>>> seth
>>>
>>> On Wed, Feb 4, 2009 at 3:29 PM, jr conlin  wrote:
>>>
>>>   
>>>> Hi all,
>>>>
>>>> My apologies for being a slug and not staying on top of the OAuth
>>>> Library stuff, but I did want to pass along one tool I just pushed live.
>>>>
>>>> http://developer.netflix.com/resources/OAuthTest
>>>>
>>>> provides a third party page to prove your OAuth HMAC-SHA1 signature
>>>> generation, and allows you to set the nonce and timestamp in order to
>>>> validate that your signature matches the signature I'm generating.
>>>>
>>>> Considering the number of times I've been asked in forums about "why is
>>>> my signature generated by library X being rejected?", I figured it might
>>>> be helpful to have something like this.
>>>>
>>>> Although it's targeted for Netflix, it's obviously not restricted to
>>>> only Netflix calls. It also doesn't fetch or store tokens or secrets, so
>>>> you'd have to provide your own.
>>>>
>>>> Let me know if you have any questions or comments about this. (I'd love
>>>> to hear that someone else had already built something like this, but the
>>>> term.ie form seems to be more targeted toward fetching the 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 Test Page

[jr conlin]

Heh.  Yep, knew about that one, Rob. (Actually, thanks for reminding me 
to add it to our Resources page.) The problem with that one was that it 
wasn't available for some mobile platforms that were asking for 
something like this. I used your tool pretty heavily when I was trying 
to debug my library.

Rob Richards wrote:
> Hi JR,
>
> We also have a similar tool, though it's a windows based app.
> http://solutions.mashery.com/docs/tips_and_tricks/oAuth
>
> I had written it for the same exact reasons :)
>
> Rob
>
> jr conlin wrote:
>   
>> Hi all,
>>
>> My apologies for being a slug and not staying on top of the OAuth 
>> Library stuff, but I did want to pass along one tool I just pushed live.
>>
>> http://developer.netflix.com/resources/OAuthTest
>>
>> provides a third party page to prove your OAuth HMAC-SHA1 signature 
>> generation, and allows you to set the nonce and timestamp in order to 
>> validate that your signature matches the signature I'm generating.
>>
>> Considering the number of times I've been asked in forums about "why is 
>> my signature generated by library X being rejected?", I figured it might 
>> be helpful to have something like this.
>>
>> Although it's targeted for Netflix, it's obviously not restricted to 
>> only Netflix calls. It also doesn't fetch or store tokens or secrets, so 
>> you'd have to provide your own.
>>
>> Let me know if you have any questions or comments about this. (I'd love 
>> to hear that someone else had already built something like this, but the 
>> term.ie form seems to be more targeted toward fetching the 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 Test Page

[jr conlin]

Sure, I'll see what I can do about dumping that. (Possibly as an 
"advanced" feature.)

The API Key /Shared Secret is something that we use, partly because we 
discovered a good deal of confusion about what "consumer" meant. (For 
that matter, folks didn't understand the difference between "oauth" and 
"consumer" either and would frequently swap them.) Since we provide the 
key/secret with that term, I stuck with it here.

Seth Fitzsimmons wrote:
> Hey JR.
>
> This is great.  It would be really helpful if you dumped the
> normalized parameter string and the signature base string as well as
> allowing the method to be overridden.  I've found that the signature
> base string is usually the piece that doesn't match between
> implementations, so being able to compare them is really valuable.
>
> Is there a reason that you're using the "Api key" / "Shared secret"
> terminology instead of "Consumer key" / "Consumer secret"?
>
> seth
>
> On Wed, Feb 4, 2009 at 3:29 PM, jr conlin  wrote:
>   
>> Hi all,
>>
>> My apologies for being a slug and not staying on top of the OAuth
>> Library stuff, but I did want to pass along one tool I just pushed live.
>>
>> http://developer.netflix.com/resources/OAuthTest
>>
>> provides a third party page to prove your OAuth HMAC-SHA1 signature
>> generation, and allows you to set the nonce and timestamp in order to
>> validate that your signature matches the signature I'm generating.
>>
>> Considering the number of times I've been asked in forums about "why is
>> my signature generated by library X being rejected?", I figured it might
>> be helpful to have something like this.
>>
>> Although it's targeted for Netflix, it's obviously not restricted to
>> only Netflix calls. It also doesn't fetch or store tokens or secrets, so
>> you'd have to provide your own.
>>
>> Let me know if you have any questions or comments about this. (I'd love
>> to hear that someone else had already built something like this, but the
>> term.ie form seems to be more targeted toward fetching the 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] OAuth Test Page

[jr conlin]

Hi all,

My apologies for being a slug and not staying on top of the OAuth 
Library stuff, but I did want to pass along one tool I just pushed live.

http://developer.netflix.com/resources/OAuthTest

provides a third party page to prove your OAuth HMAC-SHA1 signature 
generation, and allows you to set the nonce and timestamp in order to 
validate that your signature matches the signature I'm generating.

Considering the number of times I've been asked in forums about "why is 
my signature generated by library X being rejected?", I figured it might 
be helpful to have something like this.

Although it's targeted for Netflix, it's obviously not restricted to 
only Netflix calls. It also doesn't fetch or store tokens or secrets, so 
you'd have to provide your own.

Let me know if you have any questions or comments about this. (I'd love 
to hear that someone else had already built something like this, but the 
term.ie form seems to be more targeted toward fetching the 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: Possible to implement user authentication similar to Facebook Connect via OAuth?

[JR Conlin]

Senad wrote:
> I'm looking for possibility to implement user authentication similar
> to Facebook Connect via OAuth. I understand that OAuth is not OpenID
> extension, but as far as understand Consumer can also authenticate a
> user of Service Provider, if Consumer has authorization to access
> user's data stored on service provider. In similar way how Facebook
> Connect does things: all messages are signed by Service Provided (that
> is Facebook), so Consumer just needs to verify whether user's data
> send by user are correctly signed.
>   
Well, Facebook Connect does indeed bundle a few things together in order 
to do what you want, and it's certainly possible to duplicate it using a 
combination of OpenID (for user login credentialing), OAuth (for secure 
third party authorization) and Portable Contacts (for contact exchange). 
Take a look at the work that Joseph Smarr and Plaxo are doing for tips 
about that. http://www.plaxo.com/api/portablecontacts  (Heh, Facebook 
uses a simple MD5 hash of the arguments + a shared secret, so in some 
respects, an OpenID/OAuth combination would be more secure, but that's 
beside the point.)

One of the bigger problems, honestly, is making sure that you've got a 
system that either maps the OpenID token to your existing UserID, or 
uses the OpenID token as your UserID. Once you have that, it's fairly 
trivial to create a table that maps to user information returned by 
Portable Contacts.

It's not as "advanced" as Facebook is (although facebook relies heavily 
on the use of their Javascript libraries and localized cookies unless 
you're a trusted party), and frankly, if you're running a simple app or 
blog, the Facebook API is far easier to get running right now. Then 
again, their system is absolutely tied to just Facebook so if your life 
happens to involve other sites, well, you're not going to get them.

The OpenConnect stuff is still very much a work in progress, so feel 
free to help out.

> Did anybody investigated this? Any pointers how to do this?
>
> Thanks!
> Senad
>   


--~--~-~--~~~---~--~~
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: Distinction between Request Token and Access token

[JR Conlin]

Jorgito wrote:
>
>   Hi! I'm new to this group. I am very grateful for the possibility it
> brings me to ask questions, so thanks in advance ;)
>
>   Reading the spec of OAuth there's something whose motivation I can't
> understand. Why distinguishing between a Request Token first, and an
> Access Token next? I agree that from a theoretical, software
> engineering point of view the process of obtaining a ticket to access
> the protected resource is different from the process of getting the
> resource itself. However, in practice this approach leads to
> additional delays during which the Service Provider is in a temporal
> state.
>   
At Netflix, we use all three in a significant manner.

The Consumer Key and Secret are used for access to our "low protection" 
movie catalog. In effect, they're our API Key and we only require two 
legged Auth to access.

The Request Token is used not only to acquire the User Access Token, but 
also as part of the User Access Grant process (since we've got three 
parties in this, we require an extra step where the user grants 
permission for us to provide the access token, and we use the Request 
Token as the common element). It's a somewhat controversial and 
occasionally confusing step, but once folks understand the process, they 
actually agree that it's fairly simple.

Finally, we use the User Access Token to grant the App permission to 
User protected resources such as their movie queue.

>   On the one hand, temporal states should be avoided as far as
> possible in Web design. On the other hand, the User will notice that
> the Consumer takes a significant time to retrieve the protected
> resource (ok, this time will not be significant when accessing ONE
> resource, but what if they are one thousand resources from the same
> Service Provider? The additional time consequence from the distinction
> between Request Token and Access token is increased 3 orders of
> magnitude).
>   
Honestly, it's not that much time, and frankly even with hundreds of 
thousands of keys, it can be handled by a single key in-memory cache. 
There are various optimizations one can do with the data. We process a 
fairly large number of two and three legged auth and barely see the CPU 
tick past 1%.

>   Don't get me wrong. I think that OAuth is a very interesting
> technology and I can't wait to put my hands on it and develop my own
> Web applications. I'm not criticizing OAuth. I'm asking these
> questions sincerely because I really want to know why these decisions
> have been taken.
>   
Damn straight. It's called "Critical Thought" and it's sadly missing 
from a great many folks.What's nice is that there's also the concept of 
"Shared Knowledge" and thus why groups and forums like this are really, 
really handy.
>   Thank you for your patience. Greetings,
>
>
>   Jorgito
>   


--~--~-~--~~~---~--~~
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: Standardizing the OAuth Client Libraries

[JR Conlin]

John Kristian wrote:
> Take percent encoding for example.  Neglecting to percent encode leads
> to a protocol violation, but when you investigate the root cause you
> might find that the OAuth library provides a correct encoding
> algorithm but the application neglected to call it.  (Users of the
> Java library have done this.)  I would say that's a programming
> problem: it was caused by erroneous interaction between the
> application and the library.  The protocol violation is merely a
> consequence.
Actually, that's one of the things I've definitely noticed from folks 
using some libraries. The problem is that the library goes through great 
effort to calculate a signature based off of the rules and stipulations 
of OAuth, then makes the user try and guess what it did in order to come 
up with that solution. Users will use what they think should work, not 
necessarily what will indeed work.

I guess what I'm suggesting is more than just a "Ok, here's some inputs 
and outputs, make sure they match" sort of thing, but more a gentleman's 
agreement from the various library makers that they provide the user 
with enough utility that they're not going to try and do things on their 
own. In other words, they don't just return a signature value, but have 
options for returning a fully formatted Authorization header, or a set 
of OAuth key/value pairs so that users can duct-tape them onto the URL 
or in the POST body or what-have-you.

Many of the libraries offer this already, including the Objective C 
version, the Python version, and (ok, i'll pimp it) my OAuthSimple 
client library for Javascript and PHP. It'd be nice if the libraries had 
a reasonably similar way of providing that function so that even if your 
language of choice isn't well documented, it's trivial to figure out 
what to do from reading about one that is.

I'm working with some of the other library authors to try and get them 
to offer similar things, or at least do things like make their encoding 
methods public. Heh, maybe what we need is a "OAuth Seal of Approval" 
for libs that make life easier for noobs.

--~--~-~--~~~---~--~~
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] Standardizing the OAuth Client Libraries

[jr conlin]

I know that this list is about OAuth in general, but I'm seeing a fairly 
consistent pattern with how people are using the client libraries.

Netflix uses OAuth for all requests. This means that consumers are using 
a vast majority of the libraries in order to use our services. Over the 
past few months, we've been working with them in order to isolate 
problems and I've been seeing a few issues like .Net's base URL encoder 
defaults to lower case hex, Ruby's URL encoder defaults to encoding 
spaces as '+', and others.

While the library authors have done great jobs at working around these 
issues, they haven't always made things easy for their users and have 
expected them to duplicate their efforts to ensure that variables are 
encoded for transfer the same way that they're encoded for the signature 
generator.

Users are often frustrated because they call the Library, get the OAuth 
Signature Value, yet when they make the call it fails for reasons that 
aren't always obvious.

My proposal is that to get OAuth wider usage, the libraries should be 
built to a common set of guidelines, things like: Hex Values should be 
in upper case, escape routines should be publicly accessible, libraries 
should return properly formatted OAuth Authorization Headers, etc. 
Basically, help users avoid making common mistakes which will lead to 
frustration around OAuth.

Thoughts?

--~--~-~--~~~---~--~~
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: 2-legged requests seem quite popular

[JR Conlin]

Keith Grennan wrote:
> Howdy,
>
> In the last couple months all the questions I've been asked about
> Net::OAuth (OAuth for Perl) have been around creating 2-legged /
> tokenless requests.
>
> I know this is not the primary OAuth use case, but it may be
> worthwhile for other OAuth library maintainers to include support (and
> docs, unit tests) for the 2-legged scenario, if they haven't already.
>
>
>   

Oddly, I think it may become one. (and possibly we're to blame)

Netflix uses two legged OAuth for general requests like getting catalog 
information. For us, OAuth provides a way to ensure that a developer's 
ID isn't compromised. Three legged OAuth is only used where there's a 
potential third party involved (e.g. access to a Netflix User's movie 
rental queue or other more private information.)

I know a number of groups are thinking along the same path because of 
the issues and headaches that come with managing things like AppIds.



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