In order to access any Twitter API functionality, it is necessary for your program to be authenticated and authorized. Authentication is a handshake that takes place between your program, your user (optionally), and Twitter. Once your application is authenticated, you are then authorized to make API calls. ((For various reasons, the terms authentication and authorization tend to be used interchangeably, even though they have distinct meanings.))
There are two major kinds of authentication, application and user. In application authentication, your application runs independently of any user and cannot act on behalf of any user. It’s authorization is tied to the application itself. In user authentication your application acts, in some fashion (even if only in a read only fashion) on behalf of a user. The process starts with the user authorizing you to make Twitter API calls on behalf of him or her, and then your application receives a set of tokens it can use to authenticate its access.
That was confusing to write, so I imagine it’s confusing to read! Let me see if I can clear things up a bit.
First, you are not allowed to make anonymous calls to Twitter’s API. You used to be able to (the old API 1.0 which has been replaced by API 1.1). So, before you make any API calls ((except for the calls that tell Twitter who you are, of course)), you have to tell Twitter who you are and get a special access token.
Once you have an access token, you use it to sign your Twitter calls. Signing does two things: One, it marks the call as coming from your application on behalf of some user ((except for application authentication, bear with me for a moment)). Second, it includes a hash of the call that proves to Twitter that the call has not been forged or changed in flight.
To get an access token, you need to use one of two approaches to authorization
The only variation of this is application authentication, where you do not act on behalf of a specific user nor do you need any user’s permission. It simplifies things somewhat, but the basics are the same.
While there is basically just one way to do application authentication, user authentication has three different ways you can invoke it. The first mode is really only suitable for testing purposes, where you hard code a set of user tokens into your application. The second mode is suitable for GUI/mobile applications (that is, programs not running in a browser), and is called PIN authentication. The third mode is a standard web based authentication, where the user is given the option, from Twitter, of approving your access.
Why not just always use application authentication? There are a few reasons:
- Application authentication does not allow you to see Twitter like the user does (e.g., you cannot see messages from protected accounts that your user is following).
- Application authentication does not allow you to post messages to Twitter.
- Application authentication does not grow its rate limits as you add users. With user authentication, each additional user gets their own set of rate limits.
Why use application authorization?
- It’s simpler
- If your application really doesn’t have a user, it has much higher rate limits for Searching.
The subpages have examples of each type of authorization: