Now that we have the basic infrastructure ready, it is time to test the authentication mechanism itself. So we have the basic screen, that asks the user to acquire the PIN. Ultimately, we need to store two values - access token and access token secret, both obtained through the authentication API. As a secondary identifier, we might as well store the Twitter ID that is linked with the application.

For the Acquire PIN button we can easily invoke the OAuthClient-based PerformRequest method. However, we need to introduce some modifications in that mechanism because of the fact that there are multiple requests going through the same method, and we need different asynchronous handling depending on the data we receive.

Inside OAuthClient, create a new enum, called RequestType:

public enum RequestType
{
InitialToken
}

The main PerformRequest method all of a sudden suffers a change as well - instead of the byte type at the end, I am using RequestType, so the method declaration now looks like this:

The GetToken method can now either remain with this name, because it is indeed going to be used to obtain the token, or generalized to GetResponse - all Twitter operations will return a string anyway. So to do some re-using of the existing components, I am going to rename it.

There now appears to be another problem - how exactly am I going to pass the request type to the async callback? After all, the general requirement for a new instance of AsyncCallback is to pass a method with the signature of void (IAsyncResult). Don't forget that you are also passing the AsyncState object - in this case, it is simply the request, but we can make it an object array. Just like this:

Notice that now I am taking the array passed as the state and assign proper objects considering the index passed at the very beginning. The InitialToken type is the request to obtain the token and show the PIN code.

We're now ready to go back to the UI. We need to perform the request for the initial token and show the pin. So here it is:

According to the OAuth documentation (coupled with what Twitter states), we need the parameters I specified above to request a unique app token. The callback is set to oob - this will ultimately force the PIN screen to show up, since that's the only way MangoTree will authenticate the user.

The timestamp must be in the UNIX time format, so I created a property in the StringHelper class that will always return the correct timestamp.

The nonce should be a unique string, and for now I decided to use a GUID - ultimately, we will change it for security purposes, but for now it's a great unique value to experiment with.

When the request is performed, I am obtaining three values:

oauth_token

oath_token_secret

oauth_callback_confirmed

I am not as much interested in the callback, as I am interested in the token and the token secret, that will be used to sign future requests. Before I am going to talk about storing these values, let's see what happens when the user proceeds with the operation.

This is where Twitter will tell the user what my intension are with the application. The moment the user clicks on Authorize app with the correct credentials entered, the application will receive all permissions outlined above.

Once done, the PIN will appear on the screen.

The user has to store this code manually - currently, there is no way for me to access the content in IE9. Ultimately, I could use my own WebBrowser component in the app itself, but that will create another unnecessary layer. Once the user copies this PIN, it will be used to perform another request, this time to get the access token.

So the scenario in this case most likely will go like this - the user will get the PIN code and then press the Back button to navigate back to the application and enter the code he just got. All this time, the token and the token secret should be preserved, because we will need them now.

If the application is automatically tombstoned and then it is activated via the back button, we don't need to do anything about the existing values, since those will remain where they were.

What I am going to do is store these values in the App class for now:

That being said, some small modifications should be added to the GetResponse method, to set the correct values. Look at the changes:

There are several things I have to mention here. First and foremost, the verifier parameter is the PIN code obtained by the user. You might've also noticed that I am using RequestType.AccessToken - a new addition to the enum we have in OAuthClient.

Now I simply need to add a custom async callback behavior based on the new type.

Notice that I replaced the existing token and token secret with the new ones - these will be the core elements as we go. Also, I added two more static string fields - UserID and UserName, to temporarily store the user identifier (numeric) and his Twitter handle. Once the request completes, with the correct PIN, you are ready to execute any other requests on the Twitter API - the authentication circle is complete.