What should security look like?

Awesome to see RC1!

I think security is the next big priority. What would that look like? I can think of a couple issues:
1. Secure the front-end.

At the very least, just put everything behind a normal Meteor login screen. Login via Meteor Developer account. I read this in the Meteor docs:

> More functionality for OAuth clients. Currently, OAuth clients can check that the user is authenticated as a Meteor developer and get their username, but that's all they can do. Apps can't receive your email address or check your organization membership. We could give apps the ability to prompt users for permission to do these things.

So it does not seem you could restrict logins by Meteor org, for example. There used to be an `allowedUsers` settings. I think hard-coding names in this way is perfectly fine. Can we use that to restrict logins to the front-end?
2. Secure `meteor-tool`.

I'm not familiar with the innards of meteor-tool. What commands does it authenticate for? Is it in any way possible to restrict _any_ command that interacts with Stratosphere? That is, a user should have to authenticate to run `meteor add/remove`, `meteor search/show` against Stratosphere.

Just putting some thoughts down...

The issue does not name files, tests, or entry points. Start by mapping the front-end login flow and the meteor-tool commands that interact with Stratosphere; a contributor would first need an agreed scope, authentication behavior, and access policy before implementation can be considered done.

Written by the indexing model from the issue text.