Game Auth Server: Login und Game Server Trennen

Der erste echte Schritt zu einer skalierbaren Online-Spielarchitektur ist meist dieser: den Game Auth Server von dem Server zu trennen, der die Spielwelt selbst betreibt. Wenn ein einziger Prozess versucht, die Passwörter eingehender Spieler zu prüfen und gleichzeitig die Bewegung, den Kampf und das Inventar tausender Charaktere zu verarbeiten, reißt schon die kleinste Verkehrsspitze die ganze Welt nieder. Die Antwort ist, die Authentifizierung in einen separaten Login Server und die Spiellogik in einen oder mehrere Game Server zu verlagern.

Was der Auth Server tatsächlich tut

Der Auth Server (Login Server) ist der Torwächter, der die Identität eines Spielers prüft und ihm das Recht gewährt, eine Spielwelt zu betreten. In einem typischen Ablauf sind seine Aufgaben:

• Authentifizierung: Er prüft Benutzername und Passwort (in gehashter Form) gegen die Datenbank.
• Kontostatus: Er setzt Bans, Zahlung/Abonnement, Altersgrenzen und IP-/Hardware-Blacklists durch.
• Serverliste: Er zeigt dem Spieler, welche Welten (Realms/Channels) offen sind und wie voll sie sind.
• Ausstellung des Session-Tokens: Bei erfolgreichem Login erzeugt er ein einmaliges, kurzlebiges session token und übergibt es dem Game Server.

Der entscheidende Punkt: Der Auth Server tritt ab, sobald der Login abgeschlossen ist. Sobald der Spieler in der Welt ist, spricht er nicht mehr mit dem Auth Server; der gesamte Echtzeitverkehr geht an den Game Server.

Warum man sie trennt: die Probleme eines einzelnen Servers

Login und Spiellogik im selben Prozess zu halten, wirkt anfangs einfach, bringt aber mehrere grundlegende Probleme mit sich:

• Sehr unterschiedliche Lastprofile: Der Login ist kurz, aber CPU-intensiv (Verifikation des Passwort-Hashes) und datenbankgebunden; die Game Loop braucht konstanten Netzwerkverkehr mit niedriger Latenz. Beides in denselben Thread-Pool zu stecken bedeutet, dass eine abendliche Login-Welle für alle bereits Spielenden Lag erzeugt.
• Sicherheitsoberfläche: Passwörter und Kontodaten sind die sensibelsten Werte. Sie in einem separaten Prozess mit strengeren Sicherheitsregeln zu halten, isoliert von der Spiellogik, verkleinert die Angriffsfläche.
• Single Point of Failure: Stürzt ein Game Server ab, ist nur diese Welt betroffen; ist aber alles ein Prozess, sperrt ein einziger Crash alle Spieler aus, auch jene, die sich nur einloggen wollten.
• Skalierung: Ein Auth Server kann Dutzende Game Server dahinter versorgen. Wächst die Spielerzahl, fügt man Game Server hinzu, ohne die Login-Infrastruktur duplizieren zu müssen.

Token-basierter Handshake

Die sichere Kommunikation zwischen Login- und Game Server läuft über ein Session-Token. Der klassische Ablauf: Der Spieler loggt sich am Auth Server ein, der Auth Server erzeugt ein kurzlebiges Token und gibt es sowohl dem Spieler als auch (über eine gemeinsame DB oder das interne Netz) dem Game Server, der Spieler verbindet sich mit diesem Token zum Game Server, und der Game Server validiert es.

// Auth Server: bei erfolgreichem Login ein Token ausstellen
Token issueSession(uint32_t accountId) {
    Token t;
    t.value   = randomBytes(32);        // unvorhersehbar
    t.account = accountId;
    t.expires = now() + seconds(30);    // kurze Lebensdauer
    t.used    = false;
    db.storeSession(t);                 // in gemeinsame Tabelle schreiben
    return t;
}

// Game Server: das Token validieren, wenn der Spieler sich verbindet
bool verifySession(const std::string& token, uint32_t accountId) {
    auto s = db.loadSession(token);
    if (!s || s.used || s.account != accountId) return false;
    if (now() > s.expires) return false;   // abgelaufen
    db.markUsed(token);                     // einmalige Nutzung
    return true;
}

Die Schlüsseleigenschaften: Das Token muss unvorhersehbar (kryptografisch zufällig), kurzlebig (Sekunden) und einmalig sein. So bleibt das Zeitfenster selbst bei Abfangen winzig. Das Passwort erreicht nie den Game Server; der Game Server bespricht mit niemandem Passwörter, er validiert nur Tokens.

Datenbank und gemeinsamer Zustand

Wie kommunizieren die beiden Server? Der häufigste Ansatz ist eine gemeinsame Datenbank (meist MySQL): Konten, Sessions und Charakterdaten liegen in zentralen Tabellen. Der Auth Server liest die Kontotabelle und schreibt in die Session-Tabelle; der Game Server validiert die Session-Tabelle und verwaltet die Charakter-/Spieldaten.

In größeren Setups schiebt sich ein schneller In-Memory-Speicher wie Redis dazwischen: kurzlebige Session-Tokens sind zu flüchtig, um sie auf persistente Festplatte zu schreiben; sie im RAM zu halten ist sowohl schnell als auch leicht über automatischen Ablauf (TTL) zu bereinigen. Manche Architekturen nutzen einen internen RPC-/Message-Kanal, statt Tokens direkt zu teilen: Der Auth Server teilt dem Game Server über das Netz mit „dieses Konto kommt mit diesem Token".

Welche Methode auch immer, eine Regel ändert sich nie: Der Kanal zwischen den beiden Servern muss intern und sicher sein. Tokenvalidierung oder RPC-Verkehr dürfen nicht ins Internet exponiert werden, und der Client des Spielers darf diesen Kanal nie erreichen.

Der Übergang zu einer Multi-Realm-Struktur

Die wahre Stärke liegt darin, mehrere Game Server hinter einen Login Server stellen zu können. Der Spieler loggt sich ein, der Auth Server zeigt ihm eine Weltenliste, der Spieler wählt eine aus, und der Auth Server stellt das Token aus, das ihn zum Game Server dieser Welt leitet.

• Horizontale Skalierung: Mit wachsender Beliebtheit fügt man neue Welten (Channels) hinzu, jede ein eigener Game-Server-Prozess.
• Lastverteilung: Der Auth Server kann volle Welten verbergen oder neue Spieler zu leereren Channels lenken.
• Einfachere Wartung: Um eine Welt zu aktualisieren, fährt man nur diesen einen Game Server herunter; Spieler spielen in anderen Welten weiter, und der Login-Dienst fällt nie aus.

Metin2, WoW-artige Emulatoren und viele MMO-Stacks nutzen genau dieses Modell: eine einzige Auth-/Account-Schicht, dahinter als Channels oder Realms aufgeteilte Spielkerne.

Häufige Fragen

Lohnt es sich, den Auth Server für ein kleines Spiel zu trennen?

Ein separater Prozess ab dem ersten Tag ist nicht zwingend, aber die Logik von vornherein zu trennen ist sehr wertvoll. Wenn man den Authentifizierungscode als ein von der Game Loop unabhängiges Modul schreibt, ist das Verlagern in einen eigenen Prozess bei wachsender Spielerzahl ein einfaches Refactoring; ist alles verflochten, wird es ein teures Neuschreiben.

Könnte ich statt eines Tokens einfach das Passwort bei jedem Paket senden?

Nein. Das Passwort wiederholt über das Netz zu transportieren ist sowohl ein Sicherheitsrisiko als auch eine teure Hash-Berechnung bei jeder Prüfung. Ein kurzlebiges, einmaliges Token ist sowohl sicher als auch günstig zu validieren; das Passwort wird nur einmal verarbeitet, ausschließlich auf dem Auth Server.

Werden Spieler im Spiel rausgeworfen, wenn der Auth Server abstürzt?

Nein, nicht in einem korrekten Design. Der Auth Server ist nur beim Login beteiligt; Spieler in der Welt sind mit dem Game Server verbunden. Fällt der Auth Server aus, stoppen nur neue Logins, bestehende Sessions bleiben unberührt — das ist der größte Robustheitsvorteil der Trennung.

Möchtest du eine solide Auth-/Login-Architektur für dein Spiel bauen? Wenn du Hilfe bei der Login-Server-Trennung, der token-basierten Session-Verwaltung und der Multi-Welt-Skalierung brauchst, nimm Kontakt mit mir auf.