I have got a demo script that lets me authorize with my app and sends back my token. But this is confusing.

I have always used username and password in my CURL or simpleXML functions to authorize the API call. I don't understand how this relates to oauth.

I get that I will store the token, but what do I do with it once i have it? Nothing I've found online is clear and it makes the assumption that I'm stephen hawking and already know 9/10ths of what they are talking about.

Help me go from using username and password in the http address, to using my oauth token instead.

4 Answers
4

I have always used username and password in my CURL or simpleXML functions to authorize the API call. What the hell is going on with this oauth thing by comparison?

Nobody in their right mind should trust their Twitter password to your web application so your application is unable to access Twitter on their behalf. OAuth is a way around this by letting the user selectively grant access for your application to their Twitter account without you knowing the password. That way, the password remains a credential only shared between the user and Twitter and no untrusted third party (you).

That’s what’s up with that crap.Try saying it aloud, fast, with a British accent. *scnr*

It's not like oauth is any better. Any app that wants your password can now trick most normal users into sharing it by showing a fake oauth screen.
–
JacobJan 28 '11 at 12:37

@Jacob: you’re unfortunately right there. But OAuth isn’t broken in principle (as far as I know!). It’s unfortunately broken in practice because users have been trained not to pay attention to OAuth screens, and just authorize anything. Twitter has to drastically change their stance vis-a-vis third party applications if they want to restore the usefulness of OAuth.
–
Konrad RudolphJan 28 '11 at 13:39

The basic idea behind OAuth is it allows you to act on behalf of a person without knowing their password.

Let's say you have a social networking website (my example would be Plantworking, shameless plug). And you want to use Twitter as a third party to verify the creation of new accounts. Or you want to allow users on your site to automatically post tweets from your website.

You as the operator of Plantworking first of all have a shared secret with Twitter: you sign up for this key and store it. I'm not sure but I would guess it's used to sign all your requests.

A user comes to your site.

You show them a nice link saying "Sign up using your Twitter account".

They click on it, and in the background, you send a request for a token to Twitter

You get a request token back.

You send the user to Twitter with this request token.

Twitter shows them a nice page, with the name of the site making the request and what Plantworking wants permission to do.

They click that they agree, so Twitter marks that request token as accepted.

Twitter directs them back to Plantworking

Plantworking takes the request token, and sends a request to Twitter (with the request token) for an "access token". If the swap is successful, Plantworking gets the access token, and knows that that user is legitimate. Plantworking can then create the account based on that information. Or, if the permission you were asking for was to use resources or interact with the Twitter site on the user's behalf, you now can do so.