OAuth

API v1.1's Authentication Model

There are two forms of authentication in the new model, both still leveraging OAuth 1.0A.

Application-user authentication

This is the most common form of resource authentication in Twitter's OAuth 1.0A implementation to date. Your signed request both identifies your application's identity in addition to the identity accompanying granted permissions of the end-user you're making API calls on behalf of, represented by the user's access token.

Application authentication

This form of authentication is not yet supported. Stay tuned.

This is a less common form of OAuth 1.0A where your signed requests identify your application's identity alone. Use this form of authentication on API methods that support application-only authentication. You would use this form of authentication for many so-called "logged out" experiences in applications or contexts in which you don't want to first obtain user permission to act on their behalf (or avoid the OAuth request_token -> authorization -> access_token "dance"). The simplest way to consider this: these are fully signed OAuth 1.0A requests without the use of an oauth_token or oauth_token_secret.

API v1.0's Authentication Model

In the now-deprecated API v1.0, some API resource requests require OAuth 1.0A authentication, some merely support it, and others do not require nor support authorization. All forms of authentication used contain a user context — there is no means to identify as an application-only to a resource. When credentials are incorrect and the method can be evaluated in an unauthenticated context, the request is treated as an unauthenticated request for convenience. The Search API supports only unauthenticated requests.

• Using OAuth →