What is the correct OAuth API endpoint

[Zhami]

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

[Taylor Singletary]

Hi Zhami,

http(s)://api.twitter.com is best for OAuth-related operations like the requestToken, accessToken, and authorizeToken steps of the OAuth flow. These aren't versioned the way that resource-based APIs are.

http://api.twitter.com/oauth/request_token
http://api.twitter.com/oauth/authorize

http://api.twitter.com/oauth/access_token

For resource requests for things like tweets, timelines, lists, etc. use the versioned URL scheme with the api.twitter.com. Adopting the versioning scheme helps protect you from future changes to what might be considered the "default version" of the API, should things ever change significantly.

http://api.twitter.com/1/statuses/friends_timeline.json

Taylor

[Scott Wilcox]

Zhami,

I'd go with https://api.twitter.com/1

Scott.

[Thomas Woolway]

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_token etc) 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

[Taylor Singletary]

The OAuth steps in the apiwiki have been updated to reflect the preferred subdomain of "api" as well as a note about the URLs not being versioned yet.

Thanks,

Taylor

[Jaanus]

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_tokenetc)
> 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

[Brian Smith]

Jaanus 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. ;)

I also recommend everybody to use HTTPS instead of HTTP. If you don't
use HTTPS for OAuth, then the authorization page that Twitter server the
end user will have a form that the user will use to submit his
username/password, and that form submission will happen over HTTP
instead of HTTPS. That means that anybody on the same network as the
user can easily grab his credentials when he's authorizing your app. (I
think the http:// authorization page should always submit via HTTPS by
default like the https:// version does, and it should include a link to
an insecure login page for those that are unable to use HTTPS.)

Twitter's servers don't support persistent connections, so accessing
several API resources over HTTPS often results in too much latency. But,
even if an app avoids HTTPS for regular API methods because of
performance, it should still use HTTPS for OAuth, IMO.

Regards,
Brian

[Taylor Singletary]

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

[Jaanus]

The one other thing you might want to do is to update the interface on
http://twitter.com/oauth, which is where you configure your OAuth
apps. This returns you the URLs to use, which are now different from
what the wiki says. twitter.com/oauth should also return the correct
updated urls.

On Mar 4, 11:27 am, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:

> The OAuth steps in the apiwiki have been updated to reflect the preferred
> subdomain of "api" as well as a note about the URLs not being versioned yet.
>
> Thanks,
> Taylor
>
>
>
> On Thu, Mar 4, 2010 at 7: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_tokenetc)
> > 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

[funkatron]

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:funk...@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...)