Skip to content

ADR - Authentication and authorization flows in client and server #4

@thoraxe

Description

@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 >

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions