Access Token Confusion


#1

There’s something a bit confusing about the Twitter API.

I recently created my own Twitter Access Token to make API requests. It’s a read-only token for the sole purpose of reading JSON data from my own user_timeline (my own account).

I retrieved the access token as described here:
https://dev.twitter.com/oauth/overview/application-owner-access-tokens

To authenticate to make API calls, I followed these directions:
https://dev.twitter.com/oauth/application-only

But the instructions on that page say I still need to use the “consumer_key” and “consumer_secret” in order to authenticate my request.

That doesn’t make sense. What good is an Access Token if I still have to use my consumer_key and consumer_secret to make read-only API calls to my own account?

What am I missing?

I’m looking for a way to make API calls without having to hard-code any other keys into my JavaScript code.

If I have an Access Token – shouldn’t that be all I need?

Any suggestions are greatly appreciated!!

Thanks,
-Marc


#2

You are misunderstanding something. You do not need the Access tokens for App Only Auth, that is the whole point of it, since giving away the Access tokens would make it possible for users to access your Account.

App only Auth flow diagram

As you can see in this diagram the steps for App only auth are the following:

  1. Use Consumer key and Secret to request Bearer token.
  2. You use this bearer token to authenticate requests on behalf or your App

The most important thing here is that the Bearer token should be treated as sensitive as passwords, which is explicitly noted in a super-large section on the docs:

Keep in mind that the consumer key & secret, bearer token credentials, and the 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.

Therefore you can’t use them in your JavaScript code, as it would leak them to third parties. Another issue would be that Twitter API responses do not contain the needed CORS Headers, so you would again run into issues there.
While leaking the bearer token would not make it possible to do any ‘serious’ things, it is still not very good to do so, so you should avoid it.

If you need to make requests to the Twitter API using JavaScript, the best option you have is to use a server-side proxy that knows your tokens, instead of putting them in your JavaScript code.

Update: You might ask what is the whole reason for App auth then, it is for the case when your App needs to fetch data from Twitter, but you don’t want or can’t ask a user to authenticate with your App.


#3

Thank you for clarifying that.

I remember reading that about the Bearer Token and what you’re saying make perfect sense.

But since I’m only fetching public data (read-only) from Twitter, without requiring any other user to authenticate from a browser, I was hoping for non-server-side solution, something similar to what’s offered by YouTube and Google+.

For example, this would give me my most recent Google+ posts:
https://www.googleapis.com/plus/v1/people/[userid]/activities/public?maxResults=1&key=[public-access-key]

Just so I’m clear: based on your answer and my knowledge of the current API, it appears the type of read-only API call (like my Google+ example) does not exist at Twitter and the only way to get public data from my own account (safely and securely) is with server-side authentication.


#4

That’s right.