[oauth] Re: C# OAuthBase.cs bug
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
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
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
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
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
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 jpan...@acm.org mailto:jpan...@acm.org 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 http://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 h...@granqvist.com 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. With non-easily addressable consumers (like desktop
[oauth] Re: OAuth Security Advisory
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: Duplicate Parameters
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=1foo=barfoo=gorpa=1 would be signed as http://example.com?a=1a=1foo=barfoo=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
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
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
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 http://factoryjoe.com # diso-project.org
http://diso-project.org
citizenagency.com http://citizenagency.com # vidoop.com
http://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] OAuth Test Page
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
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 jrcon...@gmail.com 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
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 jrcon...@gmail.com 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 jrcon...@gmail.com 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: Distinction between Request Token and Access token
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
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 -~--~~~~--~~--~--~---
