3

Continuation from : Setting up Twitter OAuth without 3rd party libraries

Thanks to Mr. Nylander's help, I managed to get my oAuth class working (albeit only after a long time)! However, I'm confused about a few aspects of the oAuth flow.

Here's a breakdown of what's happening in a program I made:

==edit, I think I'll post partial code, it's hard to explain with just words for me==

//1st code segment
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://api.twitter.com/oauth/request_token");
string response = "";
HttpWebResponse resp = (HttpWebResponse)request.GetResponse();
using (StreamReader reader = new StreamReader(resp.GetResponseStream()))
{
response = reader.ReadToEnd();
}

Up to this point, I can get the response successfully.

Response --> oauth_token=asjndiqufh9uf&oauth_token_secret=oinroiqurhwunwer&oauth_callback_confirmed=true

//2nd code segment
Process proc = new Process();
proc.StartInfo.UseShellExecute = true;
proc.StartInfo.FileName = "https://api.twitter.com/oauth/authenticate?" + response;
proc.Start();

This brings the user(me) to a page where I have to choose whether I want to authorize it or not. If I agree, I'll then be taken to a page which contains a PIN.

//3rd code segment
Console.WriteLine("Enter the PIN");
string pin = Console.ReadLine();
baseString = generateBaseString("POST", "https://api.twitter.com/oauth/access_token", oauth_token);
oauth_signature = generateSignature(baseString, oauth_token_secret);

HttpWebRequest request2 = (HttpWebRequest)WebRequest.Create("https://api.twitter.com/oauth/access_token");
request2.Method = "POST";
request2.Headers["Authorization"] = generateAuthorizationHeader(oauth_token);
string response2 = "";
HttpWebResponse resp2 = (HttpWebResponse)request2.GetResponse();
using (StreamReader reader = new StreamReader(resp2.GetResponseStream()))
{
response2 = reader.ReadToEnd();
}
        Console.WriteLine(response2);

    }

The code here just requests for the PIN to be entered into the application and then returns the final oauth_token and oauth_token_secret in response2 for a fully working oAuth app. (tl;dr - At this point, the app already has ALL the tokens it needs)

-If I have NOT logged in during the second code segment, regardless of wether I enter a PIN or not, I get a 401 Unauthorized error, I'm guessing this is expected.

-If I have logged in during the second code segment and have been directed to the PIN page, but then chose NOT to enter the PIN/enter some wrong PIN into my application, I still get successfully authenticated and can get the final tokens without any problems. Why?

-Am I doing a 3-legged oAuth or an OOB oAuth?

-Why would I need the PIN then?

-How am I supposed to use the PIN correctly (if I need it)?

-How am I supposed to authenticate without the PIN (if I DON'T need it)?

-How do I make it so that users won't always see the PIN page after authenticating one time? I could put a callback in the very first request, but what if I don't want the user to get redirected to ANY page at all?

Community
  • 1
  • 1
Procrastinatus
  • 121
  • 2
  • 12

1 Answers1

5

Am I doing a 3-legged oAuth or an OOB oAuth?

You are doing both. 3-legged means you are involving a user, 2-legged is business to business, or service to service. OOB (Out of band) means that you automatically trigger the PIN-based authentication scheme. Basically this means that you are saying that you cannot receive the normal oauth_verifier parameter without the user manually entering it as a PIN.

Why would I need the PIN then?

You get the PIN because you are stating your callback as OOB. If you set up a real callback you can instead receive the oauth_verifier directly to your application.

How am I supposed to use the PIN correctly (if I need it)?

You use it in the next step, when exchanging the request token for an access token you pass it along in the request as the oauth_verifier.

How am I supposed to authenticate without the PIN (if I DON'T need it)?

You need the PIN, or if you use a real callback, the oauth_verifier. They are the same thing, the only difference is that the PIN gets printed on the screen so a user can copy-paste it into your application, while the oauth_verifier is automatically picked up by your application.

How do I make it so that users won't always see the PIN page after authenticating one time? I could put a callback in the very first request, but what if I don't want the user to get redirected to ANY page at all?

You use a real callback that intercepts and uses the oauth_verifier.

-If I have logged in during the second code segment and have been directed to the PIN page, but then chose NOT to enter the PIN/enter some wrong PIN into my application, I still get successfully authenticated and can get the final tokens without any problems. Why?

This simply cannot be true. There must be a good reason for this, perhaps your app already has an access token and simply uses it?

Jon Nylander
  • 8,743
  • 5
  • 34
  • 45
  • For the last answer, the only access token that I've gotten would be the response in the first code segment (request_token), it's an unauthorized request token so I'm guessing the app couldn't have used it? If I don't log in, I get a 401 upon entering the 3rd code segment, if I do log in but don't enter the correct PIN, it still works I've not hardcoded any token values in my application, other than the consumer key and consumer secret – Procrastinatus May 31 '12 at 12:24
  • If it is really so then I have no clue how that could happen. It would mean that there is a severe security hole in Twitters OAuth implementation. – Jon Nylander May 31 '12 at 15:48
  • After researching, apparantly the oauth_verifier is not mandatory, which probably explains why I could get the tokens. Anyway, I'm trying not to use oob now, but to use an actual verifier. Where do I get the verifier? I tried getting the httpwebresponse from https://api.twitter.com/oauth/authorize?oauth_token=... but ended up getting the source of the page instead. I also tried redirecting the user, so the verifier actually appeared in the URL, but I don't want to manually copy-paste it into my application. – Procrastinatus Jun 05 '12 at 10:33
  • Nice research! If you don't specify oob as your oauth_callback but rather a real URL that you control. The oauth_verifier gets sent there after the authorization step by means of a redirect. – Jon Nylander Jun 05 '12 at 11:06
  • I did specify an actual URL, http://google.com, the verifier does appear in the url address after I get redirected there, but I don't want to copy paste it manually into my application, is there any way I could get it in a response? – Procrastinatus Jun 05 '12 at 11:33
  • You can scrape the URL if you have control of the browser. Or you can specify a callback that leads to your application via a custom URL protocol. – Jon Nylander Jun 05 '12 at 12:25
  • Sorry, I forgot to mark it as answered, I just did so and thank you for helping me out so much, even though it's just oAuth, it's really a lot of new things for me. Programming is not my forte but I do try to do as much research as possible before asking. All that's left is getting the oauth_verifier, I'll try to figure this one out myself though, thanks! – Procrastinatus Jun 05 '12 at 13:02
  • 2
    There is nothing trivial about OAuth. Best of luck! – Jon Nylander Jun 05 '12 at 13:25