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> 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 <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> >> wrote: >> > Is OAuth this hard for everyone else? >> > http://kentbrewster.com/oauth-confessions/ >> > *Sniff*. >> > Chris >> > >> > >> > -- >> > Chris Messina >> > Open Web Advocate >> > >> > factoryjoe.com // diso-project.org // openid.net // 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 -~----------~----~----~----~------~----~------~--~---
