Três semanas de login, de novo, não.

Em três pontos que mudam a conta no fim do mês e a arquitetura do seu backend: o preço é fixo e não escala por usuário ativo, então crescer não aumenta a fatura; multi-tenancy é o modelo de dados e não um add-on pago — organizações, membros e papéis já existem no painel; e o plugin Elysia verifica o JWT localmente via JWKS com cache de 1 h, sem round-trip à API de auth a cada request. Para ser justo com a comparação: o login social já existe aqui — com Google e Apple, e com as credenciais do seu próprio projeto — mas o Clerk tem dezenas de provedores e proteção de rota por papel prontos, e nisso ainda estamos atrás. Se algum dos dois é decisivo agora, vale saber antes.

Integração típica de frontend em uma tarde: AuthProvider na raiz, Protect nas rotas privadas, SignIn em /auth/signin. No backend Elysia, um único authPlugin adiciona a extração de user em cada request. Se você codifica com IA, o caminho é mais curto: passe https://myinfrastructure.click/products/auth/llms.txt para o seu agente — é a documentação inteira em um arquivo, e ela também lista o que ainda não existe, para o agente não gerar código morto.

Serve. Entrar com o código no e-mail ou com Google e Apple, perfil e sessões em vários aparelhos funcionam sem você tocar em organizações. A conta do usuário nasce no primeiro código que ele digita: não há tela de cadastro nem senha para recuperar. O multi-tenant fica disponível no modelo de dados caso o produto evolua para times — mas não é pré-requisito de nada.

Cada usuário pertence a uma aplicação: a chave única é (e-mail, applicationId), e toda consulta filtra por aplicação. O mesmo e-mail em dois produtos seus são dois usuários independentes, com sessões separadas. Organizações e papéis ficam no painel; o token não carrega papéis, então a regra por papel mora no seu backend.

Ele expõe uma aplicação sua como ferramentas que um agente pode chamar. São doze. Oito leem: detalhar a aplicação, listar as organizações dela, listar usuários, buscar usuários e organizações, ler estatísticas, listar as sessões de um usuário, listar as conexões de login social e listar os webhooks. Quatro escrevem, e exigem papel owner ou admin: revogar as sessões de um usuário, configurar e remover a conexão com Google ou Apple, e cadastrar um webhook (do plano Scale). O endereço é https://auth.worker.myinfrastructure.click/mcp/<applicationId> — o id vem do painel, em Acesso → MCP, e é ele que delimita o alcance do token: um consentimento dado a uma aplicação não vale para as outras. Implementa a revisão 2026-07-28 da spec — a que removeu o handshake de initialize e tornou o protocolo stateless. Como é um servidor remoto, não há nada para instalar: o cliente aponta para a URL e autentica por OAuth no navegador.

Sim — é o segundo uso, e o mais valioso. A spec do MCP exige que servidores protegidos sejam resource servers OAuth 2.1: PKCE obrigatório, Protected Resource Metadata (RFC 9728), discovery (RFC 8414) e validação de audiência (RFC 8707). O Auth faz o papel de authorization server nisso tudo. Do seu lado ficam duas coisas: publicar o documento de Protected Resource Metadata apontando para nós, e verificar que o campo aud do token é o seu recurso. Essa verificação de audiência não é burocracia — é o que impede que um token emitido para outro servidor seja aceito pelo seu.

É por isso que o controle não fica na UI. Três camadas: (1) o catálogo de ferramentas é filtrado pelo token — um member simplesmente não recebe as ferramentas de escrita na listagem, elas não existem naquela sessão; (2) toda ferramenta revalida o vínculo de organização no banco a cada chamada, então um ID de outra aplicação retorna erro mesmo com token válido; (3) há rate limiting por usuário e por método, porque um agente em laço tem um padrão de carga que um humano num painel não tem. As ferramentas de escrita também vêm marcadas com destructiveHint, o que faz o cliente pedir confirmação antes de executar.

Não há SLA contratual nem crédito por queda, e não publicamos número de uptime que não medimos. O que existe é o uso real: o Auth roda em Cloudflare Workers e é o login de todos os painéis das cinco linhas do Ciro, todos os dias. Se o seu caso exige contrato, fale antes de integrar.

JWT assinado com RS256 e JWKS público — seu backend verifica localmente, sem round-trip. Revogação de sessão por ID ou em massa (revokeOtherSessions). Cada sessão registra device, IP e timestamp, auditável via API. Não há senha para vazar nem link para interceptar: a única prova é o código de 8 caracteres que chega no e-mail, que expira e tem as tentativas contadas. Google e Apple entram com as credenciais do seu próprio projeto.

A API roda em Cloudflare Workers, com escala horizontal automática por região. Como a verificação JWT acontece no seu backend com cache JWKS de 1 hora, a maior parte das requests nem toca no Auth Worker.

Sim. O Auth é o login dos painéis das cinco linhas (Infrastructure, Operations, Customers, Marketing e Agents), com planos pagos por aplicação. Para workloads críticos recomendamos conversar antes — alinhamos limites, runbooks e canais de suporte.

Suporte por e-mail e canal direto com quem escreveu o código, em todos os planos. Ajudamos inclusive em decisões de arquitetura (ex: modelagem de papéis, migração de provedor, custom claims).

Com a nossa engenharia junto, caso a caso — e isso é uma vantagem enquanto somos pequenos: quem migra fala com quem escreveu o código, não com um formulário. Levamos usuários, e-mails verificados e organizações, e olhamos caso a caso antes de prometer prazo. A importação self-service via API é uma das próximas entregas. Fale com a gente e você sabe na hora se o seu caso já é suportado.

O Auth é SaaS gerenciado, e isso é deliberado: rodando no edge da Cloudflare, você recebe as correções de segurança no momento em que saem, sem precisar acompanhar CVE, agendar janela ou manter alguém de plantão para atualizar. É o trabalho que a maioria dos times não quer ter em autenticação. Para quem tem exigência de contrato ou compliance que peça self-host, fale com a gente antes de integrar e avaliamos caso a caso.