X offers applications the ability to issue authenticated requests on behalf of the application itself, as opposed to on behalf of a specific user. X’s implementation is based on the Client Credentials Grant flow of the OAuth 2 specification.
Application-only authentication doesn’t include any user-context and is a form of authentication where an application makes API requests on its own behalf. This method is for developers that just need read-only access to public information.
You can do application-only authentication using your apps consumer API keys, or by using a App only Access Token (Bearer Token). This means that the only requests you can make to a X API must not require an authenticated user.
With application-only authentication, you can perform actions such as:
Please note that only OAuth 1.0a or OAuth 2.0 Authorization Code Flow with PKCE is required to issues requests on behalf of users. The API reference page describes the authentication method required to use an API. You will need user-authentication, user-context, with an access token to perform the following:
To use this method, you need to use a App only Access Token(also known as Bearer Token). You can generate an App only Access Token (Bearer Token) by passing your consumer key and secret through the POST oauth2/token endpoint.
The application-only auth flow follows these steps:
Because there is no need to sign a request, this approach is much simpler than the standard OAuth 1.0a model.
Tokens are passwords
Keep in mind that the consumer key & secret and the App only Access Token (Bearer Token) itself grant access to make requests on behalf of an application. These values should be considered as sensitive as passwords, and must not be shared or distributed to untrusted parties.
SSL required
All requests (both to obtain and use the tokens) must use HTTPS endpoints. Follow the best practices detailed in Connecting to X API using TLS — peers should always be verified.
No user-context
When issuing requests using application-only auth, there is no concept of a “current user”. Therefore, endpoints such as POST statuses/update will not function with application-only auth. See using OAuth for more information for issuing requests on behalf of a user.
Rate limiting
Applications have two kinds of rate limiting pools.
Requests made on behalf of users with access tokens, also known as user-context, depletes from a different rate limiting context than that used in application-only authentication. So, in other words, requests made on behalf of users will not deplete from the rate limits available through app-only auth, and requests made through app-only auth will not deplete from the rate limits used in user-based auth.
Read more about API Rate Limiting and review the limits.
Step 1: Encode consumer key and secret
The steps to encode an application’s consumer key and secret into a set of credentials to obtain a Bearer Token are:
Below are example values showing the result of this algorithm. Note that the consumer secret used in this page is for test purposes and will not work for real requests.
Consumer key | xvz1evFS4wEEPTGEFPHBog |
Consumer secret | L8qq9PZyRg6ieKGEKhZolGC0vJWLw8iEJ88DRdyOg |
RFC 1738 encoded consumer key (does not change) | xvz1evFS4wEEPTGEFPHBog |
RFC 1738 encoded consumer secret (does not change) | L8qq9PZyRg6ieKGEKhZolGC0vJWLw8iEJ88DRdyOg |
Bearer Token credentials | xvz1evFS4wEEPTGEFPHBog:L8qq9PZyRg6ieKGEKhZolGC0vJWLw8iEJ88DRdyOg |
Base64 encoded Bearer Token credentials | :: eHZ6MWV2RlM0d0VFUFRHRUZQSEJvZzpMOHFxOVBaeVJnNmllS0dFS2hab2xHQzB2SldMdzhpRUo4OERSZHlPZw== |
Step 2: Obtain an App only Access Token (Bearer Token)
The value calculated in step 1 must be exchanged for an App only Access Token by issuing a request to POST oauth2/token:
Authorization
header with the value of Basic <base64 encoded value from step 1>.
Content-Type
header with the value of application/x-www-form-urlencoded;charset=UTF-8.
grant_type=client_credentials
.Example request (Authorization header has been wrapped):
If the request was formatted correctly, the server would respond with a JSON-encoded payload:
Example response:
Applications should verify that the value associated with the token_type
key of the returned object is bearer
. The value associated with the access_token
key is the App only Access Token (Bearer Token).
Note that one App only Access Token is valid for an application at a time. Issuing another request with the same credentials to /oauth2/token
will return the same token until it is invalidated.
Step 3: Authenticate API requests with the App only Access Token (Bearer Token)
The App only Access Token (Bearer Token) may be used to issue requests to API endpoints that support application-only auth. To use the App Access Token, construct a normal HTTPS request and include an Authorization
header with the value of Bearer <base64 bearer token value from step 2>. Signing is not required.
Example request (Authorization header has been wrapped):
Invalidating an App only Access Token (Bearer Token)
Should a App only Access Token become compromised or need to be invalidated for any reason, issue a call to POST oauth2/invalidate_token.
Example request (Authorization header has been wrapped):
Example response:
This section describes some common mistakes involved in the negotiation and use of Bearer Tokens. Be aware that not all possible error responses are covered here - be observant of unhandled error codes and responses.
Invalid requests to obtain or revoke an App only Access Token
Attempts to:
grant_type=client_credentials
).Will result in:
Using an incorrect or revoked Access Token to make API requests will result in:
Requesting an endpoint which requires a user context (such as statuses/home_timeline
) with a n App only Access Token (Bearer Token) will produce: