oAuth for server-side applications

[Rob]

Okay, I'm totally confused with Twitter's move to drop HTTP BASIC
authorization.

My problem is with a set of Twitter accounts that are primarily
accessed PROGRAMATICALLY by server-side processes; there is no
"client" per se, or rather, the server process IS the client. For
example, an automated process that periodically sends status tweets.
The programming currently uses the API with BASIC authentication (via
HTTPS). I am a loss as to how OAuth is applied in this situation.

A clearly expressed example would be greatly appreciated.

[Taylor Singletary]

You're likely best served by taking the approach of implementing only the parts of OAuth you need to complete your single-user use case. (Highly recommend using a library). We provide a feature that makes it easy for you to get your own access token from dev.twitter.com, which you can hard code into your application and essentially you'll be changing from a state of:

(current) Always passing a login and password with every request

to

Always passing an OAuth authorization header containing your access token on every request

Find out more about the "single token solution" here: http://dev.twitter.com/pages/oauth_single_token -- you'll be able to get your access tokens, in addition to your API keys, after registering an application there.

If you have the need for multiple users, you have a few approaches you can take, http://dev.twitter.com/pages/auth_overview goes over a number of them. Once you've acquired an access token, you can persist it for as long as you want to make calls with it (or until the user manually revokes the authorization)

Taylor Singletary
Developer Advocate, Twitter
http://twitter.com/episod

[Rob]

Taylor,

Thanks for the bootstrap info. Now, is there a soup-to-nuts CODING
example somewhere?.

[Taylor Singletary]

Working with OAuth is really platform/language-dependent. While there are some similarities to approach and object model between OAuth libraries in various languages, each has their own quirks. And each HTTP interface library has its own quirks. 

That said, I have been working on a guide specifically with the conversion from basic auth in mind. The core of it all is still wrapped

There's also some detailed examples of working with OAuth and Twitter here http://dev.twitter.com/pages/auth -- we also have compiled a good list of various OAuth libraries here: http://dev.twitter.com/pages/oauth_libraries

What programming language are you using?

Taylor

[Rob]

I'm working (more or less) in Java. I'm planning to start picking
through the Scribe library to see the flow.


The flow (http://dev.twitter.com/images/dev/oauth_diagram.png) makes
sense. What I'm having difficulty with is mapping the pieces of that
diagram to the single token solution. What steps from the diagram
(and in what sequence) apply to the STS?

Also, in the case of server-side accesses, what is the mapping of
Twitter "application registrations" to Twitter IDs? One app's
registration can access multiple Twitter IDs (concurrently) or is it
one app/reg per TwID?

[Taylor Singletary]

Scribe is an excellent choice. The author is very responsive to issues as well.

So, the "one access token" flow is essentially starting OAuth from the point of having completed the "Exchange Request Token for an Access Token" flow -- now you have an oauth_token and oauth_token_secret that comprise your "access token" and with it, you can make all the authenticated REST API calls you know and love, signing the request with these credentials. With a single access token use case, you don't implement any of the request_token, authorize, or get access_token steps.

As for multiple accounts -- that's really all up to you. To associate more accounts with the same application, you'll need to build out more of the OAuth flow -- the "my access token" feature we offer will only give you an access token for the user who owns the application. If you want to support more accounts, simply push them through the request_token -> authorize -> access_token flow, and you'll end up with more access tokens, which you'll store and associate with the specific user, shifting contexts as needed (or authorized) in your application.

Hope this helps.

Taylor

[Rob]

Sheesh, digests are always such a PITA. I wrote my own HTTP/DIGEST
auth routine once and what a pain to wade through the RFC and try to
get coding to work. I'd really like NOT to have to do that, BUT, I
want to be articulate enough (code-wise) so I'm not just blindly
relying on someone's library.

So, for the single token solution, I would:

-- for each Twitter account with server-side access, I register "my-
server-side-app" at dev.twitter.com/..., obtaining the Access Token
(oauth_token) and Access Token Secret (oauth_token_secret);

-- somehow, I plug token/secret into my HTTP request; I'm OK with
using the HTTP Authorization header:
(example from: http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/)
-----------------------------------------------------------------------------------------
GET /photos?size=original&file=vacation.jpg HTTP/1.1
Host: photos.example.net:80
Authorization: OAuth realm="http://photos.example.net/photos",
oauth_consumer_key="dpf43f3p2l4k3l03", oauth_token="nnch734d00sl2jdk",
oauth_nonce="kllo9940pd9333jh", oauth_timestamp="1191242096",
oauth_signature_method="HMAC-SHA1", oauth_version="1.0",
oauth_signature="tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D"
-----------------------------------------------------------------------------------------
oauth_consumer_key - check! (supplied by Twitter app registration
info)
oauth_token - check! (supplied by Twitter "my access token")

leaving me without a oauth_nonce or oauth_signature.


So, again, I ask (anyone) for some (fairly) LOW-LEVEL example Java
code; I'd like to know the lower-level coding mechanics WITHOUT
becoming married to the RFC AND not having to wade through someone's
framework. Like Joe Friday used to say, "Just the facts..."

Thanks.

[Taylor Singletary]

FACTS (you don't want to see my Java):

The nonce is a unique string. You create this on the fly for every request you make. A simple way to do this is to do a MD5_hex( current_time . access_token . request_path ) -- the nonce must be unique for every request sent by your API key.

The signature is the result of signing your OAuth signature base string. For requests that don't involve an oauth_token (the request_token step, for example) you sign the request using your consumer key followed by an ampersand, for requests that do involve an oauth_token (like the access token step where your oauth_token is a request_token that you are exchanging for an access_token, and any REST API calls with an access token) you sign the request using your consumer_key joined with the oauth_token_secret in play by an ampersand.

Here's some of the most basic Java for all of this around: http://oauth.googlecode.com/svn/code/java/

Taylor