There are numerous online resources which provide JavaScript APIs to access their services. To be more clear, I will base my question on the example of MapBox, but this applies well to many other services in various domains.
When someone wants to use such a service in a web application (like the map imagery from MapBox for example), they typically need to Register/Sign Up and obtain an access token to access the service.
Now, if I would use the API from the server side - there is no issue: I know my token is stored securely somewhere on the server and is only exposed upon communication between my server and the service provider, which is OK as long it is HTTPS. However, in case of a JavaScript API (for example if I use Leaflet to render a map from MapBox), I am supposed to have my access token in a JavaScript which is exposed to the user's web browser - and so it makes it extremely easy to find someone's access token. My users, or in a case of a public service, literally anyone, would be able to find the token in the browser's "Dev Tools".
This token however, as for me, should be considered as a sensetive data - service usage is tracked based on the authentication this token provides. If you pay for the service based on its usage it becomes critical, but even if you don't (like, if you use a Free/Starter/Non Paid plan) - service usage is limited and I'd like to be sure it is only me who uses it.
Is my only option a proxy via my own web server?
Is there a way to secure the access token used by a JavaScript API to access an external service, provided that JavaScript is executed in a user's browser?
Restrict Access with CORS
Make your web server return the access tokens on an ajax request from you javascript with CORS setup. Token can be captured with this method visiting your app.
Provide Tokens to Authorized Users
You can also add authentication on your webserver to provide limited access to the users you allow. Token can be captured with this method but only by authorized users.
Proxy Requests
The only way to completely protect that token is to proxy the requests through your server. Token cannot be captured with this method. Note that this may be against terms of service.
Javascript API tokens (and all client tokens, in fact) are always visible to the client (unless using them only server-side, as in node). There is no way around that. As you mentioned, the only way to truly secure an API key and keep it private is to store it in the server, then request the server to make the request on the client's behalf.
5 years later, this is not necessarily for the original poster but for anyone still interested, Mapbox now allows you to easily restrict tokens by domain(s):
https://account.mapbox.com/access-tokens (assuming you are signed in)
I will speak only about map imagery APIs like Mapbox, it seems that unfortunatly only services like Google Maps, Here Maps, Bing Maps etc offer ip/domain filtering by service provider or this type of security, all offers based on OSM i met don't propose it. As Justin Poehnelt said the only reliable way is to build a proxy, but it's usually forbidden. I find this in the ToU of Mapbox:
You may not redistribute Map Assets, including from a cache, by
proxying, or by using a screenshot or other static image instead of
accessing Map Assets through the Mapping APIs.
You may like to read up on CORS headers
These allow you restrict which domain can call a remote web service.
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 am using Google Cloud Storage. To upload to cloud storage I have looked at different methods. The method I find most common is that the file is sent to the server, and from there it is sent to Google Cloud storage.
I want to move the file directly from the user's web browser to Google Cloud Storage. I can't find any tutorials related to this. I have read through the Google API Client SDK for JavaScript.
Going through the Google API reference, it states that files can be transferred using a HTTP request. But I am confused about how to do it using the API client library for JavaScript.
People here would require to share some code. But I haven't written any code, I have failed in finding a method to do the job.
EDIT 1: Untested Sample Code
So I got really interested in this, and had a few minutes to throw some code together. I decided to build a tiny Express server to get the access token, but still do the upload from the client. I used fetch to do the upload instead of the client library.
I don't have a Google cloud account, and thus have not tested this, so I can't confirm that it works, but I can't see why it shouldn't. Code is on my GitHub here.
Please read through it and make the necessary changes before attempting to run it. Most notably, you need to specify the location of the private key file, as well as ensure that it's there, and you need to set the bucket name in index.html.
End of edit 1
Disclaimer: I've only ever used the Node.js Google client library for sending emails, but I think I have a basic grasp of Google's APIs.
In order to use any Google service, we need access tokens to verify our identity; however, since we are looking to allow any user to upload to our own Cloud Storage bucket, we do not need to go through the standard OAuth process.
Google provides what they call a service account, which is an account that we use to identify instances of our own apps accessing our own resources. Whereas in a standard OAuth process we'd need to identify our app to the service, have the user consent to using our app (and thus grant us permission), get an access token for that specific user, and then make requests to the service; with a service account, we can skip the user consent process, since we are, in a sense, our own user. Using a service account enables us to simply use our credentials generated from the Google API console to generate a JWT (JSON web token), which we then use to get an access token, which we use to make requests to the cloud storage service. See here for Google's guide on this process.
In the past, I've used packages like this one to generate JWT's, but I couldn't find any client libraries for encoding JWT's; mostly because they are generated almost exclusively on servers. However, I found this tutorial, which, at a cursory glance, seems sufficient enough to write our own encoding algorithm.
I'd like to point out here that opening an app to allow the public free access to your Google resources may prove detrimental to you or your organization in the future, as I'm sure you've considered. This is a major security risk, which is why all the tutorials you've seen so far have implemented two consecutive uploads.
If it were me, I would at least do the first part of the authentication process on my server: when the user is ready to upload, I would send a request to my server to generate the access token for Google services using my service account's credentials, and then I would send each user a new access token that my server generated. This way, I have an added layer of security between the outside world and my Google account, as the burden of the authentication lies with my server, and only the uploading gets done by the client.
Anyways, once we have the access token, we can utilize the CORS feature that Google provides to upload files to our bucket. This feature allows us to use standard XHR 2 requests to use Google's services, and is essentially designed to be used in place of the JavaScript client library. I would prefer to use the CORS feature over the client library only because I think it's a little more straightforward, and slightly more flexible in its implementation. (I haven't tested this, but I think fetch would work here just as well as XHR 2.).
From here, we'd need to get the file from the user, as well as any information we want from them regarding the file (read: file name), and then make a POST request to https://www.googleapis.com/upload/storage/v1/b/<BUCKET_NAME_HERE>/o (replacing with the name of your bucket, of course) with the access token added to the URL as per the Making authenticated requests section of the CORS feature page and whatever other parameters in the body/query string that you wish to include, as per the Cloud Storage API documentation on inserting an object. An API listing for the Cloud Storage service can be found here for reference.
As I've never done this before, and I don't have the ability to test this out, I don't have any sample code to include with my answer, but I hope that my post is clear enough that putting together the code should be relatively straightforward from here.
Just to set the record straight, I've always found OAuth to be pretty confusing, and have generally shied away from playing with it due to my fear of its unknowns. However, I think I've finally mastered it, especially after this post, so I can't wait to get a free hour to play around with it.
Please let me know if anything I said is not clear or coherent.
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
I could do with some help on my REST API. I'm writing a Node.js app which is using Express, MongoDB and has Backbone.js on the client side. I've spent the last two days trying to work out all of this and not having much luck. I've already checked out:
Securing a REST API
Securing my REST API with OAuth while still allowing authentication via third party OAuth providers (using DotNetOpenAuth)
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
http://tesoriere.com/2011/10/10/node.js-getting-oauth-up-and-working-using-express.js-and-railway.js/
I want to keep my backend and frontend as separate as possible so I thought about using a carefully designed REST API would be good. My thinking is that if I ever get round to developing an iPhone app (or something else like that), it could use the API to access data.
BUT, I want this to be secure. A user has logged into my web app and I want to ensure my API is secure. I read about OAuth, OAuth 2.0, OpenID, Hmac, hashes etc... I want to avoid using external logging in (Facebook/Twitter/etc) I want the registering and logging in to be on my app/server.
...but I'm still confused here. Maybe it's late at night or my brain is just fried, but I could really do with some steps on what to do here. What are the steps for me to create a secure API?
Any help, any information, any examples, steps or anything would be great. Please help!
In order of increasing security / complexity:
Basic HTTP Auth
Many API libraries will let you build this in (Piston in Django for example) or you can let your webserver handle it. Both Nginx and Apache can use server directives to secure a site with a simple b64encoded password. It's not the most secure thing in the world but it is at least a username and password!
If you're using Nginx you can add a section to your host config like so:
auth_basic "Restricted";
auth_basic_user_file /path/to/htpasswd;
(Put it in your location / block)
Docs: http://wiki.nginx.org/HttpAuthBasicModule
You'll need to get the python script to generate that password and put the output into a file: http://trac.edgewall.org/browser/trunk/contrib/htpasswd.py?format=txt
The location of the file doesn't matter too much as long as Nginx has access to it.
HTTPS
Secure the connection from your server to the app, this is the most basic and will prevent man in the middle attacks.
You can do this with Nginx, the docs for it are very comprehensive: http://wiki.nginx.org/HttpSslModule
A self-signed certificate for this would be fine (and free!).
API Keys
These could be in any format you like but they give you the benefit of revoking access should you need to. Possibly not the perfect solution for you if you're developing both ends of the connection. They tend to be used when you have third parties using the API, eg Github.
OAuth
OAuth 2.0 is the one to go with here. While I don't know the underlying workings of the spec it's the defacto standard for most authentication now (Twitter, Facebook, Google, etc.) and there are a ton of libraries and docs to help you get those implemented. That being said, it's usually used to authenticate a user by asking a third party service for the authentication.
Given that you doing the development both ends it would probably be enough to put your API behind Basic HTTP Auth and serve it over HTTPS, especially if you don't want to waste time messing around with OAuth.
Here's a different way of thinking about it:
Let's suppose for a moment that you're not using an API. Your user logs into the app, providing some credentials, and you give a cookie or similar token of some sort to the user, which you use to identify that user has logged in. The user then requests a page containing restricted information (or creating/modifying/deleting it), so you check that this token to ensure that the user is allowed to view that information.
Now, it sounds to me that the only thing you're changing here is the way that information is delivered. Instead of delivering the information as rendered HTML, you're returning the information as JSON and rendering it on the client side. Your AJAX requests to the server will carry that same logged-in token as before, so I suggest just checking that token, and restricting the information down to 'just what the user is allowed to know' in the same way.
Your API is now as secure as your login is - if anyone was to know the token necessary for accessing the api, they would also be logged into the site and have access to all the information anyway. Best bit is, if you've already implemented login, you've not really had to do any more work.
The point of systems such as OAuth is to provide this 'logging in' method, usually from a third party application and as a developer. This would potentially be a good solution for an iPhone app or similar, but that's in the future. Nothing wrong with the API accepting more than one authentication method!
The answers so far do a great job of explaining, but don't give any actual steps. I came across this blog post that goes into great detail about how to create and manage tokens securely with Node + Passport.
http://aleksandrov.ws/2013/09/12/restful-api-with-nodejs-plus-mongodb/
Tips valid for securing any web application
If you want to secure your application, then you should definitely start by using HTTPS instead of HTTP, this ensures a creating secure channel between you & the users that will prevent sniffing the data sent back & forth to the users & will help keep the data exchanged confidential.
You can use JWTs (JSON Web Tokens) to secure RESTful APIs, this has many benefits when compared to the server-side sessions, the benefits are mainly:
1- More scalable, as your API servers will not have to maintain sessions for each user (which can be a big burden when you have many sessions)
2- JWTs are self contained & have the claims which define the user role for example & what he can access & issued at date & expiry date (after which JWT won't be valid)
3- Easier to handle across load-balancers & if you have multiple API servers as you won't have to share session data nor configure server to route the session to same server, whenever a request with a JWT hit any server it can be authenticated & authorized
4- Less pressure on your DB as well as you won't have to constantly store & retrieve session id & data for each request
5- The JWTs can't be tampered with if you use a strong key to sign the JWT, so you can trust the claims in the JWT that is sent with the request without having to check the user session & whether he is authorized or not, you can just check the JWT & then you are all set to know who & what this user can do.
Node.js specific libraries to implement JWTs:
Many libraries provide easy ways to create & validate JWTs, for example: in node.js one of the most popular is jsonwebtoken, also for validating the JWTs you can use the same library or use express-jwt or koa-jwt (if you are using express/koa)
Since REST APIs generally aims to keep the server stateless, so JWTs are more compatible with that concept as each request is sent with Authorization token that is self contained (JWT) without the server having to keep track of user session compared to sessions which make the server stateful so that it remembers the user & his role, however, sessions are also widely used & have their pros, which you can search for if you want.
One important thing to note is that you have to securely deliver the JWT to the client using HTTPS & save it in a secure place (for example in local storage).
You can learn more about JWTs from this link