Do applications dream of authenticated requests?

Monday, 11 March 2013

People — our users — are central to everything at Twitter. Users read, retweet, favorite, and compose tweets. They follow other users and search for what’s meaningful to them. The user is the primary agent of the Twitter experience, in all its varieties.

Applications built on the Twitter REST API are typically vehicles for user interaction with Twitter, but we recognize that applications may sometimes need to interact with Twitter on their own behalf, without bearing a user context.

To service this need, we’re releasing our application-only authentication scheme, based on the OAuth 2.0 client credentials flow. In this easily-implemented approach, applications securely exchange their credentials to obtain a bearer token which can then be simply used to make requests on the application’s own behalf.

Many v1.1 API methods support application-only auth and each has its own rate limit allocation respective to your application’s usage within fifteen minute windows. Some applications may want to use this pool as a reserve to service direct user requests. Others may find that for basic tasks, this form of auth is dramatically friendlier than the rigid formality of OAuth 1.0A.

Application-only auth is now the easiest way to get started with the Twitter REST API. While these new capabilities afforded to applications through application-only auth will certainly not be the last, asking users to authenticate is still required to properly scale API usage with user growth.

If you have any questions or comments after reading the documentation, please add them to this discussion thread.