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 apps) you > run into > the "turtles all > the way down" problem when introducing authentication inside an > authorization protocol: > you can issue secrets and tokens to an app, or try one of the > n-legged > approaches, but > they fail as you never can be sure who or what you're ultimately > authenticating. > > I'm probably rambling a bit, just some thoughts, > Hans > > > On Mon, Apr 27, 2009 at 10:42 PM, Chris Messina > <chris.mess...@gmail.com <mailto:chris.mess...@gmail.com>> wrote: > > Is OAuth this hard for everyone else? > > http://kentbrewster.com/oauth-confessions/ > > *Sniff*. > > Chris > > > > > > -- > > Chris Messina > > Open Web Advocate > > > > factoryjoe.com <http://factoryjoe.com> // diso-project.org > <http://diso-project.org> // openid.net <http://openid.net> // > 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 -~----------~----~----~----~------~----~------~--~---
