Produto
MW Identity
Login, e-mail e autorização Google compartilhados entre apps conectados.
Serviços compartilhados para apps integrados à MattediWorks. O MW Identity oferece login via OIDC, com suporte a passkeys. O MW Mail envia e-mail por um adapter Resend, e o MW OAuth cuida da autorização Google e entrega o resultado ao app solicitante. Um console de admin gerencia os três serviços. Working On It e NightMare usam o MW Identity para login; o Working On It também usa o MW Mail.
Estudo de caso público · app requer login
Serviços compartilhados, apps independentes
Working On It e NightMare usam o MW Identity para login; o Working On It também envia e-mail pelo MW Mail. Os apps mantêm seus próprios dados de negócio. Identity, o gateway de e-mail Resend e o broker de autorização Google compartilham a administração sem virar um único banco de dados de aplicação.
Por que construí esses serviços
Parte foi aprender Go construindo algo de verdade, e não mais um projeto de exemplo. O resto veio dos próprios apps: conforme a MattediWorks cresceu, cada um estava prestes a reconstruir a mesma infraestrutura.
O MW Mail nasceu como um gateway na frente do Resend: uso e limite por projeto e rastreio de entrega, para que os apps integrados usassem uma API interna. O MW OAuth centralizou a autorização Google e os callbacks, deixando o app consumidor responsável pelas credenciais e pelos dados que recebe. O MW Identity trouxe contas compartilhadas, controle de acesso e administração para os apps conectados, e virou o control plane.
Keycloak e ZITADEL já oferecem SSO, OIDC, MFA e gestão de identidade, e são muito mais maduros e completos. Eles atenderiam os requisitos de identidade. O que eu queria era uma implementação com escopo definido, que eu entendesse de ponta a ponta, integrada com o resto da MattediWorks e livre para evoluir junto.
O trade-off existe: construir infraestrutura de identidade significa assumir a segurança, a manutenção e a correção dela. Não estou dizendo que isso é melhor do que adotar uma plataforma madura.
O que os apps conectados compartilham
Uma conta, passkey primeiro
Login uma vez com passkey, com app autenticador como alternativa. Os apps que precisam podem recusar senha sozinha.
Saia de qualquer app
A pessoa vê todo app a que está conectada e pode se desconectar de um ou de todos. Todo app precisa tratar a exclusão de conta.
Um gateway de e-mail compartilhado
Os apps integrados enviam pelo MW Mail em vez de chamar o Resend diretamente. As requisições usam uma chave de idempotência por projeto para que novas tentativas possam reutilizar um resultado de envio registrado.
Autorização Google por um broker
O MW OAuth cuida do fluxo de autorização Google e entrega um resultado assinado ao app solicitante. O broker processa os tokens do provedor em memória, sem persistir esses tokens; o app que recebe gerencia as credenciais de que precisa.
Um console para três serviços
Registre apps, rotacione chaves e gerencie projetos de Identity, Mail e OAuth num lugar só. As operações protegidas exigem autenticação recente com passkey.
Auditoria por pessoa
Uma chamada de admin feita pelo console fica registrada em nome de quem fez, não do serviço no meio do caminho.
Contexto da implementação
- Time
- Sozinho, do design ao deploy
- Período
- 2026-08 – atual
- Status
- No ar; usado pelo Working On It e pelo NightMare
- Testes
- 339 automatizados (207 Go, 132 console)
Limites de segurança e escolhas
Tokens bearer de admin ficam no BFF
O console de admin se autentica no BFF com um cookie de sessão HttpOnly e usa tokens CSRF nas operações de escrita. Os tokens bearer de identidade e delegação ficam no BFF, no servidor, em vez de expostos ao JavaScript do console. Isso limita a exposição desses tokens; não impede que um JavaScript malicioso faça requisições por uma sessão ativa. O custo é um serviço a mais entre o console e as APIs de admin.
Token delegado: uma audiência, cinco minutos
Para cada chamada de admin, o BFF troca a sessão por um token (RFC 8693) que só um serviço aceita, para o escopo de uma rota, por cinco minutos. Um serviço só pode fazer introspection de tokens feitos para ele, e se o Identity cair a requisição é recusada: fail closed.
Sem e-mail de "esqueci a senha", de propósito
A recuperação de conta passa por um operador, em vez de um link de redefinição por e-mail. O fluxo revoga as sessões e os tokens existentes e emite uma capability de uso único para cadastrar uma passkey substituta. Controlar a caixa de e-mail, por si só, não basta para concluir esse fluxo; a recuperação ainda depende da verificação de identidade feita pelo operador.
Regra de segurança é teste, não recomendação
O control plane documenta 21 invariantes de segurança e testa ponta a ponta: audiência errada, escopo faltando, Identity fora do ar e rota não mapeada têm checagem. O BFF nunca é um proxy genérico: toda rota declara método, caminho e escopo, e o que não está mapeado é 404.
Identity, BFF, Mail e OAuth
mw-identity: o OIDC provider, em Go, sobre SQLite.mw-bff: o backend-for-frontend de admin, em Go; o console em React 19 só fala com ele.- MW Mail (adapter Resend) e MW OAuth (adapter Google): Go e SQLite, cada um com sua API pública para os apps, autenticada por chave de projeto.
- No modo de admin federado, MW Mail e MW OAuth validam tokens delegados por introspection no
mw-identity.
Escopo e revisão de segurança
- Instância única em SQLite.
- Sem auditoria de segurança externa ainda.
- Repositórios privados; a história do lado do usuário é pública em mwecosystem.mattediworks.com.