Auth Model

[Relentlesslba]

@ytitov

We will have more than one GRPC service, and all of them will require for the client to be authenticated, except one - the auth service.

The auth service will not have an interceptor. It will include a call to authenticate the client, expecting a username and password, and returning a session ID. Once the client has a session ID, it will communicate through other GRPC services (tasks, messages). These services will include an interceptor for both client and server.

Flow:

1. Client calls a GRPC procedure (log in) under the auth service. The message includes fields for username and password.
2. Server returns a message with the session ID, and stores the session ID in redis with an expiration time.
3. Client retrieves tasks and messages using other GRPC services. The client interceptor will insert the session ID into the header (metadata) of each message it sends via any non-auth service.
4. The server will intercept the header of any message that arrives via any other service except auth, expecting a session ID in the metadata, and authenticating via redis (and potentially refreshing the timer on the session ID).

In summary, one auth interceptor will function for all GRPC services except the auth service on both the server and the client.

[ytitov]

@Relentlesslba Thanks for writing that out. The way I see it you can create the following issues, which reference this issue.

Issue to address 1 and 2:

1. create login rpc
   • takes a username and password and returns a payload that contains a session id which is a string.
   • handles password error
   • store in redis (what I've done in the past was create an entry where the key is the session id you will be sending back, and the value is a json string), to be honest though, you can store session id and the value can just be the user id.

think about how you would write an integration test to test this process.