Devlog #8 · Auth server

Autenticação foi extraída para um processo separado com propósito único: verificar credenciais, emitir tokens e gerenciar sessões.

A separação é intencional. O game server cuida do mundo. O auth server cuida de quem pode entrar nele. Misturar essas responsabilidades num único processo cria acoplamento que complica escala e aumenta superfície de ataque.

Fluxo de entrada

O launcher faz login no auth server via HTTP. O auth server verifica a senha com Argon2id, registra a sessão em Redis e devolve um JWT assinado. O jogador abre conexão UDP com o game server e envia esse token no HELLO.

O game server valida assinatura offline e faz lookup de sessão ativa em Redis antes de aceitar. Dois checks independentes: token assinado + sessão viva. Token válido com sessão expirada é rejeitado. Logout invalida a sessão imediatamente.

Rate limiting e Argon2 sem travar o runtime

Rate limiting por IP via sliding-window Redis protege o endpoint de login. O Argon2 roda em pool de threads bloqueantes separado do runtime async — hashing de senha é CPU-bound por design, e isso não pode parar o loop de eventos.

Toda sessão é auditada em Postgres: login, logout, timestamp, IP.

Bench / validação
— Meta arquitetural: 1.000 logins/s com pool Argon2 dimensionado
— JWT issue: alvo p50 < 100 µs
— Argon2id por hash: 200–500 ms (custo intencional — segurança de senha)
— Validação no handshake: offline, sem network call ao auth server por tick
— Sessão auditada em Postgres em cada login e logout

Próximo: movimento — o jogador começa a se mover no mundo.