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:
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.
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?
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?
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).
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."
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.
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.
Related
Where to save security information when I want to send a Web API call to DialogFlow from Browser? I use Angular.
I have a backend of the application, but I don't want to send the request through my backend (don't want to pay for the additional traffic).
Is it even possible to make a secure call from a browser?
Are there any techniques I could apply to achieve this? As I know DialogFlow uses Google Cloud (GCP) behind the scene, are there any recommendations from GCP (so far can't find any)?
Anything sensitive you need to store client side is out of your control, and therefore you need to assume it will be compromised.
If the API can be called from your server instead of the browser then you can store the token on the server to protect it, but this depends on what the API is used for.
It appears their documentation on accessing the API can be found here: https://dialogflow.com/docs/reference/v2-auth-setup#getting_the_service_account_key
I would to ask a few questions to better understand some procedures. I'm trying to write a web api project which will be a backend for both web and mobile clients.
The problem that i've in mind is about security. I don't want to use Identity or any other providers. I want to use my own database user and role structures.
Only authenticated client applications should be consuming my application. So that anonymous applications should not consume it.
So what should be the approach ? I 've written a custom AuthorizationAttribute and check some custom headers like "AppID","AppSecurity" key which i store in my own database and if the client sends the right appId and the key it means the app is authenticated to consume the API which does not sound very secure to me.
Another issue is that ; Lets say i've developed a javascript web application and i've to first authenticate the application itself before making GET/POST/PUT/DELETE etc requests which means i've to add some kind of authentication data like username, appkey, password in one of the js files for sending the "AppID" and the "AppSecurity" keys in the header. A client who knows how to use some developer tools or fiddler can easily capture my header values that are being sent to the server side? Even if i pass authentication values on the body of my json request it still can be found on the js files that are sent to the client. I'm also confused about that tooç
So basically i want to build a server side api that will serve the data and get data from the authenticated client applications only. What i need is a simple example for that without using any identity providers.
I need to send the response of a api call to another server, is there a secure way of doing this? I need to make sure that the client server doesn't tamper with the data too.
The goal is to allow the user (with there own api key) to make a request to a 3rd party api, and securely give the response to me to verify information. This needs to be done, given that the the 3rd party api doesn't have oauth support.
As you've not had a response for a month, I'll have a pop at a broad answer.
The 3rd party API server would need to store a return URL against the client's API key. When they receive a request using the client's API key they will match the key with the URL in their database and send the response to that URL instead of back to the client.
This will require cooperation with the 3rd party API provider, and implementation specifics would depend on them.
An aside, oAuth wouldn't necessarily help you here as the token generation system (that I rather assume you are referring to) is only relevant for the authentication part of any API interaction, and you didn't mention specific uses.
Consider the usecase in which a website uses a paid analytics package to track user behavior on said site.
In that case the website needs to securely communicate with an API of the analytics provider (all clientside through javascript).
How can this be done securely? To my understanding of the various authentication protocols a secret token is always needed to setup a secret-handshake between client and server. Using oAuth1a this is all packed in HMAC, etc. but still the secret must be available.
Given that:
the secret code must be available to the client in javascript to do authenticated calls
javascript on the client can obviously be inspected by anyone
How would you keep the secret safe? It seems you can't, but how then do all these paid 3rd party services which communicate through clientside JS keep things secure?
As stipulated by the referenced answer below, it seems Google Maps API is doing this with the HOST header which apparently (?) can't be spoofed.
How does Google Maps secure their API Key? How to make something similar?.
Thus, having a sever-side map which uses a map of <apikey -> allowed HOST headers> would do the trick.
I am building an API and had questions about handling authentication when using a front-end framework such as Backbone.js.
I have a single API server that is responsible for returning and modifying data based on RESTful web requests.
I have another app server that is a Backbone application. I want this application to connect directly with my API server, so set the entire project up so that this app server can make cross-domain AJAX requests to the API server.
There are some API routes that I do not want unauthorized parties to obtain access to. For example, I have a path /users that lists all the users of my app. I need this path later on for admin functions, but I don't want it publicly available to my app server.
What is a good authentication scheme to use? OAuth won't work because the secret token would be exposed on the front-end. And after that, I'm a little stuck with what my options are. Does anyone have any suggestions moving forward?
In cases like these I use a combination of techniques.
-- Good ole Cookie based auth
As a backbone app will always be used inside a browser and browsers have built-in cookie support, I would suggest that you should accept cookie based sessions on the server side. All the auth related stuff will be handled by the browser and you don't have to worry about storing keys etc. On top many libraries like (NSURL in iPhone) and frameworks (like PhoneGap/Trigger) all support cookies so woha you can support all kind of clients with litte work.
-- Plain API Key
For third-parties, I use api-key based authentication. You provide username and password, I provide key. You send me that key every time in HTTP header for all subsequent requests. I use the key to identify you and then allow/disallow actions accordingly.
I assume once you can authenticate a user (wait..who are you?), then you can setup authorizations ( you say Micheal ? ...ok you can access /users )
Also take a look at my backbone-parse plugin for an idea on how to authenticate users against an external API service #shamelessplug