Login handshake - rebaserHEAD/NexusForever GitHub Wiki

How the client gets from a password to a character in the world: three servers, two tokens handed from one to the next, and where each step lives. Read from the code, and seen working on a local server.

The client talks to three servers in turn, and each hop hands it what the next one asks for.

sequenceDiagram
    participant C as Client
    participant S as STS
    participant A as Auth
    participant W as World
    C->>S: email, password proof
    S-->>C: game token
    C->>A: game token
    A-->>C: session key, realm address
    C->>W: session key
    W-->>C: realm and character lists

1. STS proves the password and issues a game token.
2. Auth takes the game token, picks a realm, and issues a session key along with that realm's address.
3. World takes the session key, and from then on the client is in the game: realm list, character list, character select, and into a map.

The two columns are also described on upstream's database documentation.

The STS server speaks a text protocol, STS/1.0: a request line naming a path, a couple of headers, and an XML body.

1. The client connects and starts the login with its email. The server looks the account up, sets up SRP6 from the stored salt and verifier, and sends back its half of the exchange.
2. The client answers with its own half and its proof. The server checks the proof, sends its own, and from there both sides encrypt the connection.
3. The client asks for a game token. The server writes a new GUID to the account and sends it.

The auth server speaks the game's binary protocol, the same framing as the world server.

1. It greets the client, and the client answers with its build number, email and game token.
2. The server refuses any build but 16042, looks the account up by email and game token, and checks for bans and suspensions.
3. It picks the first realm that's online, generates a session key, writes it to the account, and sends it with the realm's name, address and port.

1. The world server greets the client, and the client answers with its session key.
2. The server looks the account up by the session key, loads it, and switches the connection's encryption to a key derived from the session key.
3. The client asks for the realm list and the character list. The character list comes straight from the character database, with the account's currencies, unlocks and entitlements alongside.
4. From character select the client enters a map, and the game begins.

Switching realm from the realm list repeats the last hop: the world server issues a new session key and tells the client where to go.