Geek Social — Documentação
Módulos

Auth

Registro, login, OAuth com Google, refresh, recuperação e troca de senha.

Visão geral

O módulo Auth é responsável por toda a autenticação do Geek Social. Ele cobre:

  • Registro de conta com e-mail/senha
  • Login com e-mail/senha
  • Login social com Google (OpenID Connect)
  • Vínculo/desvínculo da conta Google em conta já existente
  • Rotação de tokens (access JWT curto + refresh longo via cookie HttpOnly)
  • Recuperação de senha por e-mail (forgot/reset)
  • Troca de senha autenticada e definição inicial de senha (para contas criadas via OAuth)

Entidades principais

TabelaO que guarda
usersConta do usuário, senha hash, vínculo Google, flags (email_verified, privacy, etc.)
refresh_tokensTokens de refresh ativos (1 por sessão); rotacionados a cada /auth/refresh
password_reset_tokensTokens single-use de reset, TTL 1h

Endpoints

Ver API Reference — Auth. 12 endpoints no total:

EndpointAuthResumo
POST /auth/registerpúblicoCria conta + emite tokens
POST /auth/loginpúblicoEmail/senha → tokens
POST /auth/refreshcookieRotaciona o par de tokens
POST /auth/logoutcookieRevoga refresh e limpa cookie
POST /auth/forgot-passwordpúblicoDispara e-mail com token de reset
POST /auth/reset-passwordpúblicoConsome token + nova senha
PUT /auth/change-passwordJWTSenha atual + nova
POST /auth/set-passwordJWTDefine senha inicial (após OAuth)
GET /auth/googlepúblicoInicia OAuth (redirect)
GET /auth/google/linkJWTInicia vínculo (retorna URL)
GET /auth/google/callbackCallback do Google (sempre redireciona)
DELETE /auth/google/linkJWTDesvincula Google

Fluxos

1. Registro com e-mail/senha

2. Login com e-mail/senha

3. Login com Google OAuth

4. Refresh token rotation

5. Recuperação de senha (forgot + reset)

Eventos de socket

O módulo Auth não emite nem consome eventos de socket diretamente — autenticação é HTTP. O socket separado (Socket.IO) recebe o JWT no handshake; ver Realtime (em breve).

Edge cases e regras especiais

  • Refresh rotation cega — todo /auth/refresh rotaciona o cookie. Replay de token antigo retorna 401. Se duas tabs disputarem refresh ao mesmo tempo, uma vai falhar com 401 e cair pro login — comportamento aceito como trade-off de segurança.
  • Reset revoga tudo/auth/reset-password apaga TODOS os refresh tokens do usuário. Sessões em outros dispositivos caem pro login no próximo refresh. Isso é intencional pra cobrir caso de conta comprometida.
  • change-password NÃO revoga sessões — diferente do reset. Quem trocar senha continua logado em outros dispositivos. Use reset se quiser invalidar tudo.
  • forgot-password é idempotente e silenciosa — sempre retorna 200, mesmo com e-mail inexistente, pra não vazar quais contas existem (enumeration attack).
  • OAuth state token JWT (5min)/auth/google assina um JWT curto com mode e (se link) userId. Callback verifica antes de aceitar. Inválido → INVALID_STATE.
  • Vínculo automático por e-mail — se o usuário já tem conta com aquele e-mail e usa Google pela primeira vez, a conta é vinculada automaticamente (modo linked-login na resposta).
  • Avatar do Google — copiado pra users.avatar_url no primeiro vínculo apenas se o usuário ainda não tem avatar próprio.
  • Unlink Google sem senha bloqueiaDELETE /auth/google/link falha com PASSWORD_REQUIRED_BEFORE_UNLINK (409) se o user não tiver password_hash. Use POST /auth/set-password antes.
  • set-password única vez — só permite se a conta ainda não tem senha (criada via OAuth). Falha com PASSWORD_ALREADY_SET (409) se já houver.
  • Bcrypt cost 12 — fixo. Hash leva ~250ms; não trocar sem cuidado de migração.
  • Refresh token armazenado como sha256 — DB nunca tem o token raw. Comparação faz sha256 do cookie e compara. Mesmo um dump de DB não revela tokens válidos.

Dependências entre módulos

  • Middleware authenticate (em shared/middleware/) é consumido por TODOS os outros módulos. Lê Authorization: Bearer <jwt>, verifica via app.jwt.verify, popula request.user = { userId, email }.
  • UserRepositoryauth.repository.ts é o dono das tabelas users, refresh_tokens, password_reset_tokens. Outros módulos NÃO devem inserir/atualizar essas tabelas; usam usersRepository (read-only views) ou contracts.
  • emailServiceauth.service.ts injeta um IEmailService (em dev, console adapter; em prod, SES). Mesmo padrão usado por outros módulos que mandam e-mail.
  • Google OAuth opcional — só registra rotas se GOOGLE_OAUTH_ENABLED=true e credenciais estão setadas. App funciona sem isso.

On this page