0

I'm trying to create a web application which will have a component to retrieve 3rd party data from Twitter. Assuming that I've registered my application with Twitter and have a token:

  1. Is the preferred location to store my token on my server side code (I'm using Node / Express for my backend)? The alternative would be to store it on my client side code but that seems really dangerous since everyone would be able to inspect my code.

  2. Assuming that I do store my token on the server side, does this mean that if I want to make AJAX calls to the 3rd party API (i.e. Twitter), the flow of the request would be from client to server, and then server to 3rd party web service?

  3. If the above case is accurate, then would my server side code have to include some asynchronous callback / promise logic such that once the data is ready from the 3rd party web service, the server will execute my callback to send the data back to the client side?

wmock
  • 5,382
  • 4
  • 40
  • 62
  • I've recently asked a question relating to this - I'm hoping to find some pointers on how to set up this server-side API request connected to AJAX (https://stackoverflow.com/q/48947618/1727467). If you have any feedback on how to achieve this with PHP that'd be much appreciated. – t-jam Feb 24 '18 at 00:13

1 Answers1

2

This answer makes the assumption that you are using Twitter's "application-only authentication" to make API requests on behalf of the application itself (https://dev.twitter.com/oauth/application-only).

  1. Your server side code is the preferred location to store any API keys you do not wish to make public. The developer guidance from Twitter states "These values should be considered as sensitive as passwords and must not be shared or distributed to untrusted parties."

  2. Yes, using an authentication model like Twitter's "application-only authentication" would require that all third party API requests be proxied through your server side code in order to protect the API token. The same is true for any third party API that requires a simple, static API key to be passed with each request.

  3. Although it may not technically be necessary, use of asynchronous operations on the server side when making third party API requests is preferred. This will give you a more robust architecture for dealing with the instability of internet requests as one benefit.

If you intend to read or post Twitter data on behalf of visitors to your website, be sure to read more about other methods of obtaining access tokens for use with Twitter: https://dev.twitter.com/oauth/overview. For example the "3-legged authorization" method is better suited to this scenario as it provides a secure way for the end-user to supply their Twitter credentials and authorize use of their data by the requesting application.

Brice Williams
  • 588
  • 1
  • 4
  • 9
  • Thanks @Brice-Williams. Even if this were not for Twitter, it sounds like the preferred approach is to use your server side code to contact and retrieve data from 3rd party API's and then have the server deliver that back to the client side, right? – wmock Dec 30 '14 at 14:51
  • 1
    Yes, for APIs that use service provider (application) level credentials the preferred approach would be to communicate with the API using server side code. For third party APIs that require end user credentials (ex: post to Twitter) the preferred approach would be to have the user submit these credentials directly to the API. OAuth v2 uses this method where the user submits their credentials in exchange for an authorization code. This authorization code is handed to the application which exchanges it for an access token, which is then valid for API requests on behalf of the end user. – Brice Williams Dec 30 '14 at 15:01