ADR - Authentication and authorization flows in client and server

[thoraxe]

ADR Context / Overview

Multiple authentication flows are required for both the client and the server.

• Eventually, as servers scale-out and come online, they need to be authenticated to the system at large. This prevents someone from spinning up a rogue server that should not be allowed to participate.
• The server needs to validate that the player/client is the "right" one sending commands. This prevents someone from spinning up a rogue client and hijacking another user.

Decision

<Describe here our response to these forces, that is, the design decision that was made. State the decision in full sentences, with active voice ("We will...").>

Rationale

<Describe here the rationale for the design decision. Also indicate the rationale for significant rejected alternatives. This section may also indicate assumptions, constraints, requirements, and results of evaluations and experiments.>

Status

<[Proposed | Accepted | Deprecated | Superseded]
If deprecated, indicate why. If superseded, include a link to the new ADR. >

Consequences

<Describe here the resulting context, after applying the decision. All consequences should be listed, not just the "positive" ones. >

Authors

< at anyone involved in the decision >

[thoraxe]

I think for the MVP we can ignore server auth to the "system" for now and focus only on client auth. The benefit to client auth is that it provides a pathway mechanism for player identity/uniqueness as well as authentication.

I had built a prototype lobby that would authenticate against RHSSO (where RHSSO was tied into GitHub auth):
https://github.com/redhat-gamedev/srt-ruby-lobby

The Javascript Phaser client got wrapped with Node.js and also did some ugly JWT auth:
https://github.com/redhat-gamedev/srt-web-client

Proposal for client auth

1. The game client should know where the RHSSO/auth server is and, when it starts, direct the player to the auth server to have them login. This establishes their identity.
2. The client should use the unique identity from the auth server (eg: GitHub ID) as the UUID parameter for all messages after that.
3. The client should include a JWT from the authenticated session with every message sent via AMQP
4. The server should validate the JWTs for the messages

Considerations

• It's not clear how performance-impactful validating the incoming commands JWTs would be
• How do we make the client gracefully handle re-auth if the player is still playing when the session expires?

Notes

There is a future consideration of persistent state ("user account") due to the nature of the game. At some point the auth flow may need to include some kind of account creation process. We have not settled on a persistent state engine, and it might be nice to include a partner (CockroachDB).

[dudash]

This sounds good to me. I think we might need to dig into specifics of what is and isn't allowed with an expired session. Also, play with expiration times to ensure they won't expire during any "typical" gameplay session.

• The join game scenario is the easy one - Can't join unless your token is valid.
• During the game play we won't want to kick anyone on expired tokens
• Future game play things that are menu driven would probably be an OK place to reauth (i.e. not in any ship battle action). I'm thinking like upgrading/customizing your ship

[dudash]

The persistent state engine will probably need a fronting service and API access - that will be a good place to validate the JWT token (or redirect to do auth) as well.

What you thinking "user account" will store? I'm thinking persistence-wise we need a place to keep player callsign... but also in the future potentially the ship inventory and ship customizations, player preferences, achievements, history of player combat metrics, etc... This might need its own ADR, but the persistent state note made me think that we should roughly design the data models and figure out if it will be one or more microservices, and what they will look like.

[thoraxe]

Being worked on by redhat-gamedev/srt-godot-client#54 and @bartoval