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, com o acesso via SDK em desenvolvimento; 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 Clerk tem hoje catálogo de login social e proteção de rota por papel prontos, e nós ainda não — 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/SignUp nas rotas de auth. 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. Login, cadastro, magic link, recuperação de senha, verificação de e-mail, perfil e sessões multi-device funcionam sem você tocar em organizações. 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 e senhas separadas. Organizações e papéis existem hoje no painel — a exposição deles ao usuário final via SDK está em desenvolvimento.

Ele expõe uma aplicação sua como ferramentas que um agente pode chamar. São sete: detalhar a aplicação, listar as organizações dela, listar usuários, buscar usuários e organizações, ler estatísticas, listar sessões de um usuário e revogar as sessões dele. Seis são de leitura; só a de revogação escreve, e ela exige papel owner ou admin. 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 a ferramenta de escrita na listagem, ela não existe 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. A ferramenta destrutiva também vem marcada com destructiveHint, o que faz o cliente pedir confirmação antes de executar.

Beta access opera com uptime target de 99.9% e monitoração contínua. SLAs contratuais (99.95%+, créditos de downtime, suporte 24/7) ficam disponíveis nos planos Enterprise após o lançamento comercial — beta users recebem acesso prioritário.

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. Senhas com PBKDF2-SHA256 e salt por usuário: é a função aceita dentro do limite de CPU do edge, e estamos elevando o número de iterações — quando fechar, publicamos o número exato aqui.

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 já opera produções reais em beta. Para workloads críticos recomendamos conversar antes — alinhamos limites, runbooks e canais de suporte.

Suporte por e-mail e canal direto com engenharia para beta users. 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; o que muda por provedor é o formato do hash de senha, e é por isso que 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, avaliamos caso a caso em planos Enterprise.