Use Auth credentials to interact with API

[nickclyde]

Right now, applications are assigned a user ID just by passing the ID directly to the API. We should have some kind of authorization mechanism that ensures users can only create applications for themselves rather than passing any User ID they choose.

Related: #127

[nickclyde]

Thinking about using the approach outlined here for this, using interceptors to wrap all grpc API calls with some kind of auth credential, though attaching username and password with every call seems like overkill. Maybe each login could return some kind of session token that could be used instead?

Thoughts on this @paulsmith?

[paulsmith]

I think using interceptors is the right basic approach. The client should first authenticate with the service using username and password, and get back a session token. It should then supply the token for any subsequent request to the API. The API server should validate the token (perhaps it is an HMAC of the user ID and some secret -- TBD) and reject calls for which that user is not authorized (eg., operating on an application that the user does not know, etc.).

Start by doing the simplest thing that could work, and then we'll expand/generalize/clean up the code eventually as we use it and grow to understand how it works.

[nickclyde]

@paulsmith Is there any way to skip an interceptor based on the type of request? For example, we don't want to verify the token when a user is trying to login or create an account. Is there some way to read the specific API method being called from ctx or req in the interceptor function?