This is a PowerPoint Presentation (and extraction of the contents) I made as per a couple of friends’ request (@EmadAshi and @AmrEldib) to show how OAuth works along with Twitter and how easy it is to cache OAuth credentials.
As I was doing related work for TweetToEmail. I felt a PowerPoint presentation will be even better than a blog post for this one, but here you get the two.
- A Twitter user creates a Twitter Application
- If the application is web based, it needs to provide a URL. “Localhost” is not accepted as a domain for this URL
- A Twitter Application gets two pieces of information
- Consumer Key
- Consumer Secret
- A Twitter Application will use these in all coming requests.
Initializing The Process
- User comes to the application and it decides to authenticate against Twitter
- Application makes a request using Consumer Key and Secret to obtain “Oauth Request Token”, which consists of two parts
- Token Secret
- Application makes authentication URL including the “Oauth Request Token” parameter, and optionally a “Call-back URL” (if different than default URL in first step)
- The user is redirected to Twitter, the URL contains the “Oauth Request” to identify application authentication session
- Assuming the Twitter User being logged in and authorizes the Application
- If the application is a desktop application, Twitter gives the a user a number “Verifier” to manually write back to the application
- If the application is a web application, the user is redirected back to the application call-back URL with a complex “Verifier” parameter in the URL
Obtaining the Access Token
- The Application makes a request to Twitter including the “Oauth Request Token” and the “Verifier”
- It obtains an “Access Token”, likewise it consists of two-parts:
- Token Secret
- The application needs to send the Consumer Key and Secret and Access Token in every future request that needs the Twitter User privileges
- The application needs at least one authorization process as before
- The Access Token returned can be saved in session/DB/whatever and then re-used later
- The application can later use the Access Token directly along with the Consumer Key / Secret to communicate with Twitter without going through any of the previous steps
Sample Code (TweetSharp v 2.0)
Request Token & Redirect
Getting Access Token
Hints for Web Applications
- The method GetAuthenticationUrl() has an overload that accepts a call-back URL for the user to be redirected to after obtaining verifer
- The important part in RequestToken is the Token part, not the secret.
- All parts of AccessToken are important and required
- When the user is redirected back from Twitter to your application, you get the following QueryString parameters sent to you
- oauth_token: The Token part of the Request Token
- oauth_verifier: The verifier required to obtain the Access Token later
Using Cached Access Token
- More Content Like This
- Twitter Developers Site
- Questions / Suggestions?
How did I learn that?
As a bonus for coming here, I'm giving away a free newsletter for web developers that you can sign up for from here.
It's not an anything-and-everything link list. It's thoughtfully collected picks of articles and tools, that focus on Angular 2+, ASP.NET (4.x/MVC5 and Core), and other fullstack developer goodies.
Take it for a test ride, and you may unsubscribe any time.
You might also want to support me by checking these out [Thanks]: