Best practice for security of Meteor service access tokens

Question

There are some good answers already about how to publish access tokens of Meteor user accounts from server to client. I'm just wondering whether it's better from a security perspective to:

1. publish the current user's access token and make the request from the client, or
2. keep the tokens hidden on the server, make the API calls from there, and return the results to the client?

If this is too subjective, let me rephrase it as, from a security perspective, is there any difference in the two approaches?

Meteor's "database everywhere" philosophy suggests to me that it should be safe to publish private data, since the other user data being published would be considered private too. On the other hand, the more places the tokens are made available, the more vectors there are for them to be stolen. What would you recommend, and are there more important considerations?

EDIT: I suppose another consideration is that, at least for Google's REST API, you need to pass your app's client key as a parameter. It's probably best to keep that hidden from the end user, which would be an argument in favour of sending requests from the server.

Answer 1

It would be best to avoid sending the token to the client at all if it is possible. This is because even if there is the slightest chance you can avoid some malicious toolbar/extension accessing your JS and accessing the token its very bad for the user and yourself.

You also have control over what the access can do.

For example if it were facebook and you published it to the client. It could be used to change their status for example, in your app's name. On the server where the token isn't exposed, this would not be possible.

You would also not be aware of changes made from the client, whereas you always would be on the server.

Unless your api has some kind of 'publishable key' then never send an access token to the client.

The approach in 2 where you proxy it through the server is better.

The advantage with 1. (and pretty much the only one I can think of) is when you have some kind of usage throttling by the API provider which is per ip address (such as twitter's hosepipe).