I'm surprised by this. Honestly, I think Twitter should not be allowing authenticated requests -- whether via signature or Basic Auth -- to happen over non- encrypted connections. Verifying the authenticity of the server is important, as a fair bit of trust is put in the data clients get back from Twitter.
from <http://tools.ietf.org/html/draft-hammer-oauth-10> "4.3. Spoofing by Counterfeit Servers This protocol makes no attempt to verify the authenticity of the server. A hostile party could take advantage of this by intercepting the client's requests and returning misleading or otherwise incorrect responses. Service providers should consider such attacks when developing services using this protocol, and should require transport-layer security for any requests where the authenticity of the server or of request responses is an issue." In addition, if the consumer secret is discovered (which doesn't seem terribly difficult, especially with OSS apps), I do worry about the potential for session hijacking with plain text OAuth parameters. It's more challenging than some situations, but with enough motivation it seems doable. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Mar 4, 12:15 pm, Taylor Singletary <taylorsinglet...@twitter.com> wrote: > Good point. > > I'll considering encouraging it by default by presenting it that way. I > certainly prefer it over https. > > A gating issue are design choices in many OAuth libraries where a base URL > is utilized for both authorization steps and resource requests. If the base > URL is https, then that bleeds to all resource requests, which often aren't > necessary over HTTPs. > > I much prefer OAuth libraries that don't make any base URL considerations, > requiring request_token, access_token, authorization, and resource requests > all to be addressed by explicit URLs. > > Taylor > > > > On Thu, Mar 4, 2010 at 8:57 AM, Jaanus <jaa...@gmail.com> wrote: > > Is there a reason why the OAuth URL in the api wiki could not be HTTPS > > by default? Why would you want to recommend HTTP over HTTPS? (I know > > that OAuth was designed to be safe over HTTP, immune against man-in- > > the-middle and all, but HTTPS just gives me a warm and fuzzy feel. ;) > > > rgds, > > Jaanus > > > On Mar 4, 10:18 am, Thomas Woolway <tswool...@gmail.com> wrote: > > > It's good to know that this is the recommended URI root for OAuth. Any > > > chance of getting the docs ( > >http://apiwiki.twitter.com/Twitter-REST-API-Method:-oauth-access_toke...) > > > updated to help out newcomers? Also, it might be worth adding a big NB > > that > > > those resources aren't versioned - it's one of those things that is quite > > > easy to miss. > > > > Cheers, > > > > Tom > > > > On Wed, Mar 3, 2010 at 3:26 PM, Scott Wilcox <sc...@tig.gr> wrote: > > > > Zhami, > > > > > I'd go withhttps://api.twitter.com/1 > > > > > Scott. > > > > > On 3 Mar 2010, at 15:02, Zhami wrote: > > > > > > What is the correct API end-point for OAuth authenticated, > > > > > *documented* API calls? > > > > > > http(s)://twitter.com > > > > > > http(s)://api.twitter.com > > > > > > http(s)://api.twitter.com/1
