Server-side Twitter client possible with OAUTH?

Question

Twitter'll phase out HTTP basic authentication by August 2010. In the link my scenarios are from Desktop Applications. Basically my client should tweet new posts on a website.

This would be incredibly simple with HTTP basic auth, because I can store and use my account's username and password in the app to authenticate. However, with OAUTH I can get final credentials by two means:

• Callback method. You are redirected to Twitter, (login if isn't), click allow access, get redirection back to your callback URL.
• PIN mode. You get a link to open, (login if isn't), click allow access, receive PIN code. Use this PIN code to authenticate your app.

Do I understand correctly that PIN codes also expire? How is it possible, given a username and password just to tweet from a client application? How can a server side script log in with the username/password and click allow access? All scenarios I could google up are for a web application to authenticate via twitter where the user is in front of the browser to walk through the redirect.

Answer 1

The PIN does expire under OAuth 1.0a. Using the verification code returned requires use of the temporary request token in the initial authorization request.

OAuth 2.0 defines more flows - one of which uses a direct login/password mechanism. It's up to Twitter to determine which flows they decide to implement. You can also embed a user-agent in the app.

Desktop apps suffered from a really bad user-experience with OAuth 1.0 which led to 2.0. It's doable, but painful. You can request XAuth access if you need to from Twitter as well. It's almost the same as basic auth.

Answer 2

All scenarios I could google up are for a web application to authenticate via twitter where the user is in front of the browser to walk through the redirect.

The user has to be there to authorise you the first time (just as they'd have to provide you a username and password), but the resulting access token does not expire and can be reused (unless the user deauthorises your application, that is).

Store the access token - it's as good as a username/password. Better, actually - if they change their password, your access remains.