Authoritative Server

An authoritative server is the single trusted instance that runs your game’s logic and determines what is true in a match — no client can override it, which makes cheating structurally impossible.

Every player’s client sends inputs — move, shoot, jump — to the server. The server processes them, resolves any conflicts, and sends the result back to all clients. What the server says happened is what happened. A client that reports a different state is simply wrong, and the server ignores it.

Why “authoritative” matters

Without an authoritative server, you’re relying on clients to agree among themselves about what happened — which is the peer-to-peer model. That works for small, casual games, but breaks down as player count or competitive stakes rise. Clients can desync, drop out, or in the worst case deliberately send false state to gain an advantage (aimbots, speed hacks, position spoofing).

An authoritative server eliminates that entire category of problem. You can still have cheaters at the input level — a player might use a macro or an external tool — but they cannot manipulate the game state itself, because they never control it.

Authoritative server vs. dedicated server

These terms are often used interchangeably but they describe different things. A dedicated server describes the infrastructure — a machine with no player attached, running only the game process. An authoritative server describes the architecture — a single source of truth for game state.

In practice, most dedicated servers are authoritative, and most authoritative servers run on dedicated hardware. But a listen server (where one player’s machine hosts the session) can also be authoritative in a limited sense — it’s just that the host player has a physical advantage (zero latency to the server they’re running) and the session dies if they leave.

For competitive or ranked multiplayer, you want both: a dedicated machine that is also the sole authority on game state.

How it affects your netcode

Running an authoritative server means all game logic lives server-side. Your clients become thin — they render the world and send inputs, but they never simulate the definitive outcome of those inputs. This requires careful netcode design:

Client-side prediction — the client speculatively runs the same logic locally so the player sees immediate feedback, then reconciles with the server’s authoritative result
Lag compensation — the server rewinds time slightly when processing a player’s input, so their aim is evaluated against the world state they actually saw, not the server’s current state

Getting this right is non-trivial, but the frameworks that handle it (Unreal’s GAS/movement replication, Unity Netcode for GameObjects, Fish-Net, Mirror) all assume an authoritative server as their foundation.

Back to Glossary