Identidade e acesso perto de você, em qualquer lugar.
Uma plataforma de identidade e acesso de código aberto, OpenID Certified™, para Cloudflare Workers. Autenticação, autorização e federação em uma arquitetura criada para a borda da rede.
Antes da versão 1.0. Os protocolos principais estão implementados. O aprimoramento da segurança e da confiabilidade, assim como a validação para uso em produção, continua.
01
Autenticação sem senha
Entre com passkeys WebAuthn ou um código de 6 dígitos por e-mail. Ofereça acesso sem senha com uma alternativa para quem ainda não tem uma passkey.
02
SSO e federação de identidade
Conecte aplicações e provedores de identidade existentes com OpenID Connect e SAML 2.0. Crie contas no primeiro acesso e vincule identidades externas.
03
Controle de acesso
Controle o acesso por funções (RBAC), atributos (ABAC) e relacionamentos (ReBAC). Verifique permissões por API, com políticas específicas para cada tenant.
04
Expansão automática
Expanda automaticamente a capacidade do Cloudflare D1 conforme sua base de usuários cresce. O Authrim prevê a demanda e adiciona bancos de dados (shards), sem exigir uma troca de plataforma.
Este projeto começou com um desconforto comum na operação: investigar uma falha de login e acabar vendo informações pessoais de que você não precisava.
Quando investigar expõe dados pessoais
Quem opera uma plataforma de identidade recebe esse pedido com frequência: “Um usuário não consegue entrar.” Para investigar, você acessa o ambiente do cliente e procura a conta.
Você precisa de poucas informações: a conta está bloqueada? Quando e em que etapa a última tentativa falhou? Qual caminho de login foi usado? A passkey ainda está registrada e válida?
Nada disso exige saber quem é a pessoa. Mas, ao abrir a conta, aparecem nome, e-mail, telefone e contas vinculadas, tudo na mesma tela. Você precisava saber o estado do sistema. Acabou vendo informações sobre alguém.
“Por favor, não olhe” não é uma proteção quando a informação já está na tela.
Ninguém descumpriu o procedimento. O cliente pediu a investigação, você seguiu as regras e fez o trabalho. Mesmo assim, viu os dados. A estrutura do sistema os colocou na sua frente.
Resolver isso apenas com regras e treinamento faz a proteção depender da memória e da atenção de quem investiga. Com o tempo, isso pode virar um incidente. A separação dos dados pessoais em outro banco começou como uma tentativa de resolver esse problema na própria estrutura do sistema.
Dois bancos desde o início
Os dados que identificam diretamente uma pessoa ficam em um banco fisicamente separado. A separação não foi acrescentada depois: ela já existe na camada de acesso aos dados.
Observe os dois últimos itens à direita: os registros de exclusão e de leitura de dados pessoais ficam separados, no lado PII. O acesso a dados pessoais é acompanhado independentemente da auditoria comum.
Com essa separação, o problema inicial pode ser resolvido. Bloqueios, tentativas de login e informações de dispositivos ficam à esquerda. É possível liberar o acesso necessário à investigação sem abrir o lado direito. Ninguém precisa se lembrar de desviar o olhar.
A mesma estrutura também responde a perguntas de auditoria. Fica claro onde estão nomes e e-mails e quais dados uma exclusão abrange. Resolver o problema operacional tornou o projeto mais fácil de explicar.
Dados pessoais também existem fora do PII DB
É preciso deixar isso claro: essa separação não é uma fronteira jurídica entre dados pessoais e não pessoais.
O Core DB contém endereços IP, informações de dispositivos, histórico de sessões, eventos de autenticação, metadados de credenciais e IDs internos estáveis. Dependendo do contexto, esses também são dados pessoais. Isolados, talvez não identifiquem alguém; combinados com outras informações, podem identificar.
O Authrim separa dados de identificação direta de dados de identidade necessários à operação. A investigação deve poder usar o segundo grupo sem acessar o primeiro. Isso não dispensa a proteção do segundo grupo.
Por isso, seria incorreto dizer que dados pessoais só existem no PII DB. O correto é: nomes, e-mails e outros dados de identificação direta ficam isolados no PII DB, e o acesso para investigação pode ser concedido sem abrir esse armazenamento.
Excluir é só a primeira parte
Excluir uma conta a pedido do usuário é simples. Difíceis são as duas solicitações que podem vir depois.
A primeira é comprovar a exclusão: quando ocorreu, quem a executou e por quê. A segunda é impedir um novo cadastro durante um período definido, uma regra comum em alguns serviços.
As duas exigem reconhecer uma pessoa cujos dados foram excluídos. Mas guardar informações que a identifiquem diretamente contraria o propósito da exclusão.
Um índice cego com HMAC-SHA256 permite comparar valores sem guardar o original. É possível verificar se um endereço foi excluído. A tabela de registros, sozinha, não revela qual era o endereço.
O princípio é guardar apenas o resumo necessário para reconhecer um novo cadastro e excluí-lo ao fim do prazo de retenção, registrando também quem excluiu, quando e por quê.
Do que depende a impossibilidade de recuperar o valor
Um detalhe técnico importa: endereços de e-mail têm baixa entropia. Com um hash simples, um ataque de dicionário pode descobrir o endereço original. “Não recuperável” não é uma garantia sem condições.
O Authrim usa um índice cego HMAC-SHA256 com uma chave secreta. O registro inclui o número da geração da chave, permitindo sua rotação. Sem a chave, não é possível testar endereços candidatos recalculando seus resumos.
Isolar a chave é uma condição dessa proteção. Guardá-la junto dos resumos elimina essa garantia. Essa condição também precisa estar clara ao descrever o recurso.
Abrir só o que a investigação precisa
Voltando ao problema de login: é preciso descobrir onde a autenticação parou. Em geral, não é necessário abrir um nome ou telefone.
O Authrim separa as informações de identificação direta para permitir o diagnóstico sem acesso a esse armazenamento. Quando a investigação realmente exige dados pessoais, alguém com as permissões adicionais adequadas cuida dessa parte.
Criptografia e controle de acesso protegem os dados; logs de auditoria registram seu uso. Além disso, quem investiga deve poder concluir o trabalho de rotina sem abrir dados pessoais de que não precisa. A separação do armazenamento torna isso o ponto de partida da operação.
Implementação: separação do armazenamento e limites de acesso implementados.
Validação: coberta por testes automatizados no repositório.
Maturidade operacional: a segurança e a confiabilidade para uso em produção continuam sendo aprimoradas. O Authrim ainda não chegou à versão 1.0.
Esse projeto facilita os processos de exclusão. Por si só, ele não garante conformidade legal, que também depende dos procedimentos e contratos da organização.
A pessoa entra uma vez, mas várias sessões são criadas pelo caminho. Sair da conta depende de encerrar as sessões certas em cada sistema envolvido.
Um login, três chaves
Imagine adicionar “Entrar com o Google” ao seu serviço. Para o usuário, é um único clique.
Por trás desse clique, cada sistema no caminho cria e mantém sua própria sessão. O Google tem uma. O Authrim tem outra. Sua aplicação também. São três.
Uma sessão que permanece ativa pode permitir que a pessoa continue usando o serviço ou entre novamente sem digitar a senha.
Sair não é apenas exibir “Você saiu da conta”. É definir o alcance da saída e encerrar as sessões dentro dele.
Revogar tokens é outra operação
As “chaves” aqui são sessões. Tokens de acesso e de atualização são outro mecanismo. Encerrar uma sessão não invalida necessariamente os tokens já emitidos. Para interromper o uso de um token, é preciso revogá-lo, uma operação separada.
No OIDC, encerrar sessões, revogar tokens e desativar uma conta no provedor de origem são três coisas diferentes. Este artigo trata das sessões. Para saber quando um token deixa de funcionar, veja introspecção e revogação de tokens.
O Authrim fica no meio
O provedor de origem oferece a autenticação, enquanto sua aplicação a solicita. O papel do Authrim muda conforme o lado com que ele se comunica.
É como uma agência de viagens: para você, ela organiza a viagem; para a companhia aérea, é uma cliente comprando um assento. O Authrim exerce os dois papéis ao mesmo tempo.
A saída costuma parar no meio do caminho
O login percorre o caminho entre os sistemas. A saída precisa ser comunicada explicitamente aos próximos.
Encerrar a sessão no provedor de origem não remove automaticamente as sessões no Authrim e na aplicação. É preciso comunicar o encerramento, e cada destinatário deve encerrar a sessão correspondente. O próximo diagrama mostra a cadeia com os métodos e as configurações necessários.
A diferença está na seta do meio: o Authrim consegue receber a notificação e encaminhá-la? O provedor de origem e cada aplicação também precisam oferecer e configurar os métodos necessários.
Como o problema aparece no dia a dia
Situação
Efeito de uma cadeia interrompida
Desligamento de funcionário
O acesso é revogado, mas a aplicação continua aberta no notebook e os dados internos permanecem visíveis até a manhã seguinte.
Terminais compartilhados
Em uma loja, hospital ou central de atendimento, a pessoa anterior saiu. Mesmo assim, outra aba ainda mostra o painel dela.
Dispositivo perdido
A pessoa escolheu “Sair de todos os dispositivos”. Só a sessão que estava usando foi encerrada.
Resposta a incidentes
A conta comprometida é bloqueada, mas a sessão do invasor continua válida até expirar.
Auditoria
“Demonstre que a saída chega a todos os sistemas.” Não há evidência para apresentar.
Em nenhum desses casos falta um botão de sair. A tela até muda. Mas o alcance é menor do que se imaginava, e é isso que dificulta perceber o problema.
O caminho pelo navegador perde confiabilidade
Há duas formas de avisar as aplicações. Uma delas encontra cada vez mais limitações.
Na primeira opção, frames invisíveis avisam cada aplicação. Safari, Firefox e Chrome vêm restringindo esses frames. No back-channel, a comunicação ocorre diretamente entre servidores e não depende do estado do navegador. Isso não garante a entrega: falhas de rede, destinatários indisponíveis, timeouts e respostas 5xx podem impedi-la. Novas tentativas, filas e registros de falha são responsabilidade da implementação.
A certificação do Authrim cobre o recebimento pelo back-channel. Receber uma notificação e encaminhá-la são capacidades que precisam ser verificadas separadamente.
Verificar quem recebe e quem envia
O Authrim atua como Relying Party (RP), solicitando autenticação ao provedor de origem, e como OpenID Provider (OP), oferecendo autenticação às aplicações. Encaminhar a saída exige conformidade com as especificações nos dois papéis.
Como RP: validar a notificação de saída do provedor de origem e encerrar a sessão correspondente no Authrim.
Como OP: enviar notificações para que as aplicações conectadas encerrem as sessões correspondentes.
As certificações dos perfis de logout OP e RP fornecem evidências para esses dois papéis. O Authrim tem perfis certificados nos dois lados pelo processo de autocertificação da OpenID Foundation, com seus testes oficiais de conformidade.
A certificação significa que a versão submetida à avaliação passou nos testes de conformidade dos perfis declarados. Ela não garante o encerramento imediato de todas as sessões nas aplicações e na rede de um cliente.
O provedor de origem e cada aplicação precisam oferecer os métodos necessários, com endpoints de notificação e mapeamento de sessões configurados. Desativar uma conta de origem não dispara necessariamente uma notificação de saída. Falhas de entrega, novas tentativas e visibilidade dos erros também precisam ser verificadas na configuração em uso.
Depois de sair, onde ainda existe uma sessão ativa?
Essa é a pergunta ao entregar um terminal compartilhado à próxima pessoa ou encerrar o acesso de um ex-funcionário. O Authrim recebe e envia notificações para conectar o encerramento das sessões entre o provedor de origem e as aplicações. A certificação fornece evidências sobre a implementação; testar os sistemas conectados mostra se a saída alcança o escopo desejado.
As senhas já estão no Active Directory. Como oferecer um login moderno sem copiar hashes de senha nem publicar um novo endpoint de entrada para o conector?
Começar pelo que não pode mudar
As contas dos funcionários estão no Active Directory. As políticas de senha, os prazos de validade e a desativação de contas também. Esse sistema funciona assim há anos.
Você quer adicionar passkeys, organizar o MFA e ampliar o SSO para serviços SaaS. O objetivo é claro. A primeira pergunta continua sendo: onde a senha será verificada?
Algumas arquiteturas sincronizam hashes de senha com a nuvem; outras pedem ao diretório interno que verifique as credenciais. O importante é saber onde elas ficam, qual lado abre a conexão e quem opera esse caminho.
O WordWarden mantém a verificação no LDAP/AD e permite escolher o caminho. O Authrim Relay oferece uma conexão de saída para organizações que não querem publicar um novo endpoint de entrada.
O que o WordWarden faz
O Authrim WordWarden é um conector de diretório: um pequeno serviço instalado perto do LDAP/AD. Sua tarefa é bem definida: receber usuário e senha, consultar o diretório e devolver o resultado.
Interface de login, sessões, passkeys, códigos por e-mail, federação, correlação de auditoria e mapeamento de identidades ficam com o Authrim. O WordWarden faz apenas a verificação junto ao diretório.
A direção da conexão muda a configuração da rede e os componentes que você precisa operar.
Quem se conecta a quem?
O WordWarden oferece três formas de conexão. A diferença é se sua rede precisa publicar um ponto que aceite conexões externas.
As setas mostram qual lado abre a conexão. No Direct HTTPS, o Authrim se conecta a um endpoint publicado. Tunnel e Relay iniciam conexões de saída da sua rede: o Tunnel usa o processo separado cloudflared, enquanto o próprio WordWarden mantém a conexão com o Relay.
Qual opção combina com seu ambiente?
Se a nova implantação não deve acrescentar acesso de entrada, comece avaliando o Relay. Uma estrutura de publicação ou um túnel já existente também pode ser útil. Os exemplos abaixo são cenários de implantação, não relatos de clientes.
Authrim Relay: manter o AD interno, sem novo acesso de entrada
Pense em uma empresa com AD na sede que exige uma avaliação para cada novo servidor público, ou em uma universidade que não permite conexões de entrada na rede LDAP do campus. O WordWarden abre a conexão com o Authrim, sem precisar publicar uma nova porta de entrada nessa rede.
Não é necessário um novo endpoint público nem um processo separado de túnel. O tráfego WebSocket de saída precisa ser permitido, e o funcionamento do WordWarden e o estado da conexão ainda precisam ser monitorados. O Relay não atende uma rede que proíbe toda comunicação externa.
Cloudflare Tunnel: aproveitar um túnel já em uso
Uma organização que já publica ferramentas internas pelo Cloudflare Tunnel pode ter uma equipe responsável por atualizar o cloudflared e manter as rotas. O WordWarden pode aproveitar esses processos sem abrir uma nova porta de entrada.
Você configura o hostname e a rota pelos quais o Authrim alcança o conector e mantém o túnel. O host interno não precisa aceitar conexões diretas de entrada, mas as requisições chegam por uma rota no Cloudflare.
Direct HTTPS: usar uma plataforma de API já existente
Uma empresa, universidade ou instituição de pesquisa pode já ter uma equipe que opera uma DMZ e um proxy reverso para integrações externas. Um endpoint HTTPS acessível ao Authrim pode seguir os processos existentes de certificados, logs de acesso e monitoramento.
Não é preciso manter uma conexão separada de túnel ou Relay. Em troca, a organização permite a rota de entrada e assume a proteção e a manutenção do endpoint público. O que se publica é a interface HTTPS do conector, não a porta LDAP/AD diretamente na internet.
Em todas as opções, o WordWarden precisa ser operado em um local com acesso ao LDAP/AD. Ser uma instituição acadêmica não determina a escolha; a infraestrutura e a política de rede, sim.
Authrim Relay: a conexão começa dentro da rede
No modo Relay, o WordWarden se conecta ao Authrim por WebSocket a partir da sua rede. O WebSocket mantém uma conexão aberta pela qual os dois lados podem enviar mensagens.
O WordWarden mantém essa conexão aberta e aguarda. Quando alguém faz login, o Authrim usa o mesmo canal para pedir a verificação. O WordWarden consulta o diretório interno e devolve o resultado.
É como fazer uma ligação de dentro da organização e permanecer na linha: a outra pessoa também pode falar. Não é preciso abrir uma nova conexão de entrada a cada pedido.
Na prática, o lado do diretório não precisa publicar uma URL. Isso evita administrar hostname, certificado e WAF para um novo endpoint público. Ainda são necessários permissão de saída, manutenção do WordWarden e monitoramento da conexão.
Detalhe técnico: WebSocket e portas de entrada
A diferença é qual lado inicia a conexão. No Direct HTTPS, a organização oferece um endpoint ao qual o Authrim pode se conectar. No Relay, o WordWarden interno abre uma conexão WebSocket criptografada (wss) com o Relay do Authrim.
Um firewall com controle de estado ou um dispositivo NAT normalmente acompanha as conexões iniciadas de dentro e permite o tráfego de retorno. Assim, o WordWarden recebe pedidos de verificação sem publicar uma porta de entrada nem configurar redirecionamento de portas para novas conexões externas.
Isso não significa que nenhuma porta é usada. Uma conexão wss típica usa a porta TCP 443 no destino. O firewall ou proxy deve permitir a saída para o Relay e conexões WebSocket persistentes. Enquanto o canal estiver desconectado, as requisições não chegam por ele. Por isso, monitorar a conexão continua sendo necessário.
Reduzir os endpoints para novas conexões externas não elimina os pedidos recebidos pelo canal já aberto. Autenticar a outra ponta e validar as requisições continuam sendo necessários.
Uma conexão de saída também precisa de autenticação. O Relay combina a autenticação do conector com verificações do destino configurado.
Detalhe técnico: autenticação com HMAC
O WordWarden responde a um desafio de curta duração com um HMAC, assinando uma sequência de caracteres que contém o ID do desafio e o nonce. Ele também verifica se os IDs do tenant e do conector na URL de destino correspondem à sua configuração.
O HMAC é obrigatório nas três formas de conexão. O Relay reduz a exposição de entrada, mas não elimina a autenticação do conector nem a gestão de segredos.
O que realmente atravessa o limite
Aqui é importante ser preciso. Seria incorreto dizer que a senha nunca sai da sua rede.
A pessoa digita a senha na tela de login, e ela passa pelo Authrim. A afirmação correta é: “O Authrim e o WordWarden não armazenam a senha.”
A documentação é explícita: o Authrim não deve importar, gerar hashes, recalcular hashes nem persistir senhas. Isso inclui hashes de senha vindos de sistemas legados.
A resposta também é limitada
Quando a verificação tem sucesso, o Authrim recebe o resultado e os atributos solicitados, limitados pela lista local de permissões do conector. Quem pede não decide sozinho o que pode obter: o lado do diretório define o que será liberado.
Essa direção importa: uma alteração apenas no Authrim não pode ampliar o conjunto de dados que sai da sua rede.
A senha como etapa de transição
Essa integração existe, acima de tudo, para permitir uma transição.
O LDAP/AD continua responsável pelas senhas. As pessoas seguem entrando com a conta que já têm. As passkeys são cadastradas aos poucos. O código por e-mail permanece como caminho de recuperação. O acesso continua funcionando enquanto a forma de autenticar muda.
A documentação também é clara neste ponto: não exporte hashes de senha do LDAP/AD para o Authrim. Isso transformaria a conexão de transição em uma cópia das credenciais.
Em preparação para a beta pública. A primeira versão prevista é v0.1.0-beta.1.
Voltado a projetos-piloto: organizações capazes de operar um pequeno serviço perto do LDAP/AD e compreender os limites de responsabilidade do diretório, da rede, do TLS e da gestão de segredos. Não é um serviço de diretório gerenciado.
Exige Authrim 0.3.2 ou posterior, com Directory Authentication e Relay ativados. Na beta atual, mudanças de configuração exigem reiniciar o processo.
“Copiar credenciais para fora ou abrir acesso para dentro” não são as únicas opções.
Verifique junto ao diretório e inicie a conexão de dentro. Assim, é possível oferecer um login moderno sem copiar hashes de senha nem publicar um ponto de entrada na rede interna.
O destino é a adoção de passkeys. A integração com o diretório dá a base para essa migração acontecer sem impedir ninguém de entrar.
Mais usuários estão chegando. É uma boa notícia, mas traz uma pergunta: por quanto tempo o banco de dados atual vai comportar os dados? O Authrim prepara novos destinos antes que sejam necessários, para que crescer não comece com um projeto de migração.
Adicionar espaço antes de mover dados
O Cloudflare D1, usado pelo Authrim, tem um limite por banco de dados: 500 MB no plano Free e 10 GB no Paid. Conforme o número de usuários e o volume de dados aumentam, será necessário outro local de armazenamento.
O Authrim foi projetado para distribuir contas entre vários bancos desde o início. Assim, chegar a esse limite não exige mover todas as contas existentes. Cada uma dessas unidades de armazenamento é chamada de shard.
Manter as contas existentes onde estão e adicionar destinos para as novas. Essa é a ideia central da expansão do armazenamento de contas.
Dados diferentes crescem em ritmos diferentes
O Authrim armazena separadamente as configurações do tenant, como clientes OAuth e políticas; as contas e os dados pessoais; e os índices que localizam uma conta pelo e-mail.
Mais usuários não significam que todos os bancos precisam crescer juntos. O armazenamento de contas e os índices de busca têm quantidades de registros e ritmos diferentes. A capacidade é adicionada onde faz falta.
Uma nova conta é atribuída a um dos shards disponíveis para seu tenant. A preferência é por shards saudáveis com menor proporção entre contas alocadas e a meta configurada.
O sinal observado não é o uso de disco, mas quantas contas ainda podem ser recebidas dentro da meta configurada. Com uma meta de 100.000 contas, por exemplo, uma margem de 20.000 ajuda a decidir quando preparar o próximo destino.
Quando sobra pouca margem nos shards disponíveis, uma reserva já preparada é atribuída. Isso vale tanto para shards compartilhados por vários tenants quanto para os exclusivos de um único tenant.
Armazenamento compartilhado
Armazenamento exclusivo
Armazenamento compartilhado e exclusivo
Nas implantações compartilhadas, exclusivas e mistas, os novos shards recebem novas contas. O nível da água representa a quantidade de contas alocadas, não o uso de disco nem o momento exato do provisionamento. As divisões indicam o isolamento lógico entre tenants.
O que deixa de ser trabalho repetitivo
Depois de configurar o provisionamento automático, o operador não precisa criar um banco, preparar tabelas e conectar um novo destino a cada aumento de cadastros. Também não precisa elaborar um plano de migração das contas existentes a cada expansão.
O operador verifica se o provisionamento está avançando, se as falhas estão visíveis e se o uso e os custos seguem dentro do esperado. Problemas de permissão e limites dos serviços ainda exigem atenção. A preparação do próximo destino fica com o Authrim.
O espaço livre de hoje não conta toda a história
Com espaço para mais 20.000 contas, um serviço que recebe 100 novas contas por dia tem muito mais tempo para se preparar do que outro que recebe 10.000 por hora.
Por isso, o Authrim estima a capacidade futura com base nas alocações atuais e no ritmo recente de cadastros. A previsão cobre o armazenamento de contas e os índices de busca. Uma tarefa programada roda a cada minuto, e a previsão de contas também é atualizada após as alocações.
Os shards que já estão sendo criados entram na estimativa. O objetivo é evitar que processos que detectem a mesma falta de capacidade criem bancos adicionais desnecessariamente.
Da criação ao uso
Quando as reservas não bastam, o Authrim cria bancos D1 pela API de gerenciamento do Cloudflare. Ele cria as tabelas, configura o acesso dos Workers e distribui os novos locais de armazenamento. Um banco só passa a receber contas depois de concluir as verificações de leitura e escrita.
O provisionamento automático precisa estar ativado, com tokens de API separados para D1 e Workers. Quando a execução automática não está disponível, o operador continua o trabalho pela ferramenta de instalação.
O progresso é persistido durante a criação. Após uma falha temporária de conexão, a operação pode ser retomada a partir desse estado. Permissões ausentes ou limites de recursos exigem que o operador resolva a causa antes de continuar.
Se a preparação atrasar e acabarem os espaços para contas, novos cadastros podem precisar de outra tentativa. Preparar a capacidade com antecedência busca reduzir essa espera.
Quem opera decide quando mover os dados
Adicionar capacidade e mover dados existentes são operações diferentes. Ao transferir um tenant de um shard compartilhado para um exclusivo, por exemplo, é preciso copiar os dados existentes, além de preparar o novo destino.
O operador decide se a migração deve começar. Após a aprovação, o Authrim cuida da sincronização, da verificação e da troca para o novo armazenamento.
Após a aprovação, os dados são sincronizados e verificados antes da troca para o armazenamento exclusivo. Uma etapa da migração pausa as escritas por um breve período.
Atualmente, a mudança suportada é do armazenamento compartilhado para o exclusivo. O caminho de volta e a redistribuição automática e uniforme das contas existentes ainda não estão implementados.
Excluir um shard que deixou de ser usado também exige aprovação. O crescimento não dispara automaticamente a movimentação nem a exclusão dos dados existentes.
O que foi medido
Em um teste de julho de 2026 com 200.000 contas, Core usou cerca de 208 MB, PII cerca de 238 MB e Lookup cerca de 426 MB. Cada um ficou abaixo de 5% do limite de 10 GB por banco no plano Paid. O uso real depende dos atributos e índices armazenados.
A meta padrão é de 100.000 contas por shard. Isso deixa margem para preparar o próximo, em vez de preencher o banco até seu limite físico.
O Authrim ainda não chegou à versão 1.0, e a experiência de longo prazo em produção e em grande escala ainda está sendo construída. Medir o armazenamento de 200.000 contas de teste é diferente de operar um serviço usado diariamente por milhões de pessoas.
Crescer com menos planos de migração
Um serviço pequeno não precisa começar com uma infraestrutura grande. Pode usar poucos shards e adicionar destinos conforme os cadastros aumentam. O Authrim inclui a preparação e os procedimentos necessários para isso.
Quando os usuários começam a chegar, planejar uma mudança de banco não deveria ser a primeira tarefa da lista. Reduzir esse trabalho deixa mais tempo para desenvolver o próprio serviço.
Armazenamento medido em 30 de julho de 2026 com 200.000 contas de teste. MB usa unidades decimais. Os limites do D1 estão na documentação do Cloudflare.
Desempenho
Testado sob carga.
3.500RPSEndpoints de tokens
150logins / sFluxo completo de login OAuth
1–4msTempo típico de CPU
0% de errosNas execuções de teste
Os testes no K6 Cloud cobrem cargas OIDC representativas. A capacidade depende do tipo de carga, dos limites do plano Cloudflare, do armazenamento e da distribuição em shards.
O Authrim não cobra por usuário. O custo da infraestrutura depende das requisições, do tempo de CPU, do armazenamento e dos logs. Esta é uma estimativa de custos Cloudflare, não um orçamento para produção.
Usuários ativos por mês50.000
Tipo de serviço
PremissasLogin semanal, 10% ativos por dia, sessão de 7 dias
Grátis/ mês
Requisições~1M
Por usuárioGrátis
Workers: plano gratuito (100 mil/dia)(USD)
Com base nos preços do Cloudflare Workers com um multiplicador para KV, Durable Objects e D1, calculado a partir dos padrões de uso observados no Authrim.
Observação — Apenas infraestrutura. Não inclui conformidade, monitoramento, suporte, operação, revisão de segurança, bancos externos ou uso intenso de R2 e arquivos. O custo real varia conforme a implantação.
APIs pensadas para TypeScript, SDKs JavaScript e um processo de instalação para avaliar e desenvolver serviços de identidade na borda.
TypeScriptSDKsInstalação rápida
B
Empresas
Mantenha o controle da sua implantação com SAML, SCIM, logs de auditoria, isolamento entre tenants e controles de armazenamento e logs. A segurança e a confiabilidade para uso em produção continuam sendo aprimoradas.
SSOSCIMConformidade
C
Startups
Comece no Cloudflare sem pagar ao Authrim por usuário. Depois, amplie a infraestrutura com base no consumo medido de requisições, CPU, armazenamento e logs.
Conheça uma plataforma de identidade de código aberto para Cloudflare Workers. Os protocolos principais estão implementados; a segurança e a confiabilidade para uso em produção continuam sendo aprimoradas.
