Need help with OAuth obtaining oauth_token/signature. Documentation seems to be an endless circle!

[sluu99]

I’m trying to do a server-side authentication. Basically I want the user to click on a button “Sign in using Twitter on my website,” the user will be redirected to twitter where he will authorize my application to access his information. Twitter then redirect him back to my website along with an access token.

I’ve been following the documentation in this order:

1. Implementing Sign in with Twitter (https://dev.twitter.com/docs/auth/implementing-sign-twitter)
   As I understand, this is where I make a request to obtain a request_token before I can convert it to an access_token. However, the request here has to be signed/authorize…

2. Authorizing a request (https://dev.twitter.com/docs/auth/authorizing-request)
   This page gives instruction to authorize a request by putting appropriate parameters on the header, including a signature…

3. Creating a signature (https://dev.twitter.com/docs/auth/creating-signature)
   This page explains how to create a signature from the existing parameters. However, it requires the consumer_secret and oauth_token_secret. I can get the consumer_secret from the application’s page, but to get the oauth_token_secret, I have to go back to step 1. Thus the circle never ends.

Please help!

[episod]

The documentation makes efforts to make sure you understand OAuth end-to-end (it’s a whole process) before attempting something like leveraging it for authentication.

If you’re wanting to do the sign in with Twitter flow you need to follow a series of steps (this is common to just about any OAuth implementation):

1. Obtain a request token using a signed request to oauth/request_token. You’ll be returned an oauth_token and oauth_token_secret, collectively at this step the “request token”
2. Take that oauth_token and send the user to oauth/authorize or oauth/authenticate (the choice of which one of these to send the user to depends on what implementation you prefer and whether you’re asking for DM permissions or not)
3. Once the user has completed the form on oauth/authorize or oauth/authenticate they’ll be redirected to the oauth_callback URL you specified on the oauth/request_token step. Your callback URL will get a reference to the same request token along with an oauth_verifier value
4. You exchange the request token (leveraging the oauth_token and oauth_token_secret that makes it) with a signed request to oauth/access_token, also containing the oauth_verifier you got in your callback. In response, you’ll get an access token, made up of, again, oauth_token and oauth_token_secret. It’s this particular set of oauth_token and oauth_token_secret that you want to persist.

[sluu99]

I understand the process, but I still don’t know how to sign the requests because your documentation says that to sign a request I need the request_token_secret, which I don’t have until I make a signed request to oauth/request_token

[episod]

I’ll see about clarifying that section to mention the part of the OAuth spec that’s not clear in this part – when there’s no oauth_token context, you omit oauth_token from the signing parameters and your composite signing key changes from “{consumer_secret}&{oauth_token_secret}” to “{consumer_secret}&” – or, if you think of it slightly different, it stays the same but just recognizes the null context of the oauth_token_secret.

[sluu99]

I initially wanted to write some simple method to separate my library’s dependency from the web framework I was using (Play! Framework), but I ended up using the built in solution for the meantime:
Documentation: http://www.playframework.org/documentation/2.0.1/ScalaOAuth
Code snippet from my project: https://gist.github.com/2876581

[not_me]

Yes. Update the documentation. I’ve been googling all day trying to figure this exact thing out, ‘okay but to get the token I need to sign the request, to sign the request I need the token’

[y02y08]

Hi, is it possible to give a clear description of what is used to create the signature if I want to use sign in with twitter for my website? I have tried creating the signature by following the instructions on https://dev.twitter.com/docs/auth/creating-signature but it does not seems to work. Do we need to include oauth_token="" as we have not obtained this token yet and also do we need to include oauth_callback when we create the signature? Note that I do not intend to use any external library. Thanks!

[episod]

You should really leverage an existing library – it can be difficult to get all the ins and outs of OAuth right even for people who’ve been working with it for a long time.

Signing in with Twitter will have three phases:

• Getting a request token – this request doesn’t use an oauth_token value but you do send a properly encoded fully qualified callback URL as part of the request, which becomes part of the signature.
• Sending the user to oauth/authenticate or oauth/authorize – an unsigned request, you send an oauth_token (the request token) on the querystring
• Exchanging the request token for an access token, you get an oauth_token back that is now your representation of the end user

Then you use that access token (your oauth_token for the user) in every signed request to the Twitter API from that point forward.

[mariorz]

“You exchange the request token (leveraging the oauth_token and oauth_token_secret that makes it) with a signed request to oauth/access_token, also containing the oauth_verifier you got in your callback.”

I mentioned this on another thread (https://dev.twitter.com/discussions/9711) but for users of “Twitter for Iphone” htting a url on a tweet, it has become impossible to “leverage the oauth_token_secret” since the app breaks out of UIWebView and into mobile safari when redirecting the user to the /oauth/autenticate url. This is done, I presume, to protect the users from phishing attacks, given that the UIWebView does not display a URL bar. But, since the UIWebView and the Mobile Safari sessions are not the same, when the user finally hits the site’s callback url, it is impossible to check that the oauth_token matches the one originally given, or to sign the request to oauth/acces_token with the oauth_token_secret. I have found two ways around this issue, they are mentioned in the above linked thread. One diverges from the oauth spec and the other is just plain ugly, it wold be helpful to know if the differences from the spec are intentional and if that is the recommend pattern for getting around the issue. thanks.