Os desenvolvedores do Auth Stack estão abandonando o Auth0 por

A identidade gerenciada pode parecer um atalho até a conta chegar. Serviços como Auth0 e Okta cobram por Usuário Ativo Mensal, então um produto que salta de 10.000 para 100.000 usuários pode ver os custos de autenticação dispararem de centenas para dezenas de milhares de dólares por mês. Para aplicativos B2C com tráfego irregular, esse medidor de Usuários Ativos Mensais se torna um imposto sobre o crescimento em vez de um item de linha previsível.

O bloqueio de fornecedores amplifica a dor. Uma vez que você conecta seus fluxos de login, regras e metadados de usuários a um mecanismo de regras proprietário, migrar para outra solução parece uma cirurgia de coração aberto. Ações personalizadas, tokens proprietários e páginas de login hospedadas levam as equipes a continuar pagando em vez de refatorar a lógica de autenticação central.

Ecossistemas rigidamente controlados prometem segurança, mas frequentemente oferecem rigidez. Muitos provedores obrigam você a passar por suas interfaces de usuário hospedadas, seus SDKs e seus fluxos opinionados, fazendo com que até mesmo personalizações simples—como adicionar uma nova etapa de verificação ou suportar um SSO legado peculiar—sejam vistas como uma luta contra a plataforma. Quando você precisa de uma jornada de login não padronizada, descobre o quão pouco espaço você realmente tem.

A propriedade dos dados adiciona outra camada de desconforto. Identidades de usuários, sessões e registros de auditoria estão na nuvem de outra pessoa, governadas por políticas internas opacas e limites de taxa. APIs de exportação existem, mas raramente oferecem controle de baixo nível sobre esquemas, índices ou quanto tempo os dados realmente persistem em backups.

Para startups em indústrias regulamentadas, essas restrições se confrontam rapidamente com a realidade. Regras rigorosas de residência de dados na UE, saúde ou fintech frequentemente exigem que tabelas de usuários estejam em uma região específica ou até mesmo em um cluster de banco de dados específico. Quando a resposta do seu fornecedor é "nosso roteiro" ou uma região exclusiva para empresas, sua equipe de conformidade começa a se perguntar por que a autenticação é terceirizada.

Os desenvolvedores estão respondendo exigindo mais controle, mais transparência e a capacidade de possuir toda a pilha. Sistemas de código aberto como o Ory Kratos invertem o modelo: você executa o servidor de identidade por conta própria, define seus próprios esquemas e mantém os dados dos usuários em seu próprio banco de dados. A autenticação gerenciada ainda tem seu lugar—mas as algemas de ouro estão começando a parecer bem mais apertadas.

Plataformas de autenticação gerenciadas querem ser tudo para você. Ory Kratos só quer ser seu motor de identidade. Ele é fornecido como um servidor de identidade focado em API e somente no backend, que funciona por trás de qualquer interface, framework ou dispositivo que você utilizar—Next.js, dispositivos móveis, SPAs, até mesmo monólitos legados—sem forçá-lo a usar um widget ou painel proprietário.

Kratos expõe todas as principais operações de autenticação por meio de APIs HTTP: registro, login, gerenciamento de perfil, recuperação e configurações. Seu frontend nunca precisa armazenar lógica de senhas ou criar links mágicos; ele apenas orquestra fluxos que o Kratos define e protege. Essa separação faz com que a autenticação pareça como qualquer outro microserviço interno, e não um produto SaaS de caixa-preta.

Fora da caixa, o Kratos lida com os fluxos essenciais que a maioria dos aplicativos acaba reconstruindo de forma inadequada. Você obtém registro de usuários com validação baseada em esquema, login baseado em senha e autenticação multifatorial (MFA) opcional para contas de maior risco. Ele também gerencia verificação de e-mail, ativação de conta e manipulação robusta de sessões, incluindo revogação e rotação de sessões.

Os fluxos se comportam como máquinas de estado que você controla por meio de configurações. Você pode definir onde os usuários serão direcionados após o registro, quais campos eles devem preencher e como os links de recuperação ou verificação se comportam. Para a maioria dos aplicativos, isso significa que não há necessidade de código adicional personalizado para “esqueci a senha”, “verifique seu e-mail” ou “atualizar perfil”, além de conectar a interface do usuário.

Auto-hospedado por design, o Kratos roda em qualquer lugar onde o Docker roda: em um laptop, em um cluster Kubernetes ou em um servidor bare-metal em um armário. O guia rápido oficial utiliza um único arquivo `docker-compose`, mas a mesma imagem de contêiner se escala para implantações em múltiplos nós. Sem bloqueio regional, sem caminho de migração forçado, sem janelas de manutenção opacas.

O armazenamento permanece sob seu controle. Kratos suporta bancos de dados como SQLite para desenvolvimento local e PostgreSQL para produção, conectados por meio de um simples DSN em sua configuração YAML. Você possui a tabela de usuários, o registro de auditoria e os backups, o que é importante para o GDPR, SOC 2 e clientes que perguntam: “Onde exatamente meus dados estão armazenados?”

A auto-hospedagem também elimina a ansiedade relacionada ao preço baseado em MAU. Em vez de pagar Auth0 ou Okta toda vez que seu gráfico de usuários aumenta, você paga por CPU, RAM e disco. Se precisar de login social, OAuth2 ou permissões avançadas mais tarde, o Kratos se integra ao restante da pilha Ory sem forçar uma reescrita da plataforma.

A identidade gerenciada começa a parecer diferente quando você se aprofunda na implantação. Ory Kratos é fornecido como um serviço nativo do Docker que você executa onde quiser—no seu cluster Kubernetes, em um servidor bare-metal ou em um VPS barato. O Auth0, em contraste, opera principalmente como um SaaS totalmente gerenciado, com infraestrutura, escalabilidade e atualizações abstraídas por trás de seu painel e APIs.

Essa divisão é importante quando você precisa de controle. Com o Kratos, sua pilha de autenticação fica dentro do perímetro da sua rede, próxima ao seu aplicativo e bancos de dados, integrada à sua observabilidade e CI/CD existentes. O Auth0 oferece um console em nuvem polido e SLAs, mas você aceita suas regiões, cadência de implantação e ajustes de desempenho opacos em troca.

Os modelos de custo divergem com a mesma intensidade. O Auth0 cobra com base em Usuários Ativos Mensais, bloqueando recursos e locações atrás de níveis de assinatura que podem aumentar quando as inscrições disparam ou usuários inativos retornam temporariamente. O Kratos é de código aberto: você paga por computação, armazenamento e tempo de operações, não por aluguel por identidade.

Para produtos com tráfego irregular ou sazonal—como lançamentos de jogos, plataformas de bilhetagem ou ferramentas educacionais durante a época de exames—o preço por MAU se transforma em um imposto de volatilidade. Um cluster Kratos auto-hospedado pode operar tranquilamente com recursos mínimos e escalar horizontalmente quando necessário, sem uma fatura surpresa ligada ao comportamento do usuário. Você troca contas de infraestrutura previsíveis por contas de SaaS imprevisíveis.

A flexibilidade é onde o Kratos se apoia mais em seu design API-first. Cada fluxo—registro, login, recuperação, verificação, MFA—exponde APIs JSON que qualquer cliente pode chamar, seja uma SPA em Next.js, um aplicativo móvel nativo ou uma CLI. Os esquemas de identidade vivem na configuração, permitindo que você defina características como IDs de empresas, funções personalizadas ou flags de região sem esperar que um provedor valide seu caso de uso.

A Auth0 contrapõe-se com um enorme catálogo de integrações e regras pré-construídas, mas elas vêm com limitações. Você se conecta às suas páginas de "login universal", seus gatilhos de ação e seu modelo de inquilino. Fluxos profundamente não convencionais—progresso de perfis, B2B multi-inquilino com roteamento personalizado ou políticas complexas por organização—frequentemente exigem soluções alternativas ou código de ligação frágil.

Kratos se integra a uma pilha modular: combine-o com Hydra para OAuth2/OIDC, Keto para permissões, Oathkeeper como um proxy ciente de identidade e Ory Elements para componentes de interface prontos para uso. Auth0 reúne muitas dessas capacidades sob uma única marca, mas esse pacote também reforça o aprisionamento ao fornecedor. Para equipes dispostas a gerenciar sua própria infraestrutura, Ory Kratos - Documentação é menos como marketing de produto e mais como um plano para um sistema de autenticação que elas realmente controlam.

Kratos está no centro de algo maior: uma pilha Ory modular que tenta desconstruir o que plataformas como Auth0 e Okta vendem como uma caixa opaca. Em vez de um monólito, a Ory divide a identidade em serviços focados que você pode executar, escalar e trocar de forma independente. Kratos gerencia identidades e sessões, mas delega tokens, permissões e aplicação nas bordas para seus irmãos.

Para OAuth2 e OpenID Connect, Ory Hydra entra em cena. Hydra atua como seu servidor de autorização, emitindo tokens de acesso OAuth2 e tokens de ID OIDC que os clientes compatíveis com os padrões já entendem. Você conecta o Kratos como o provedor de login e deixa o Hydra gerenciar os fluxos de consentimento, a duração dos tokens e o registro de clientes em cargas de trabalho na web, em dispositivos móveis e entre máquinas.

A autorização detalhada vem do Ory Keto, que implementa um controle de acesso baseado em relacionamento no estilo do Google Zanzibar. Em vez de codificar funções na lógica do aplicativo, você modela relacionamentos como “o usuário X pode editar o documento Y” e solicita decisões ao Keto. Esse padrão se adapta desde RBAC simples até configurações complexas e multi-inquilino, onde milhares de permissões mudam a cada minuto.

Sentado na borda, Ory Oathkeeper atua como um proxy consciente da identidade na frente das suas APIs e serviços. O Oathkeeper valida tokens do Hydra, extrai características de identidade do Kratos e aplica regras de acesso que podem delegar ao Keto para a decisão final de sim/não. Você define as regras como configuração, não como código, permitindo que você atualize as políticas sem precisar redistribuir seu aplicativo.

Combine-os e você obtém uma alternativa full-stack para suítes empresariais: Kratos para identidades, Hydra para OAuth2/OIDC, Keto para autorização e Oathkeeper como o guardião. Cada um roda como um contêiner, comunica-se via HTTP/JSON e permanece como código aberto, permitindo que você implante em bare metal, Kubernetes ou em um único arquivo Docker Compose. Em vez de pagar por MAU, você paga pela infraestrutura e mantém cada parte do pipeline de autenticação sob seu controle.

Iniciar o Ory Kratos do zero começa com o Docker, não com um painel da web. Você cria uma pasta `kratos-demo`, acessa um subdiretório `docker` e configura um `docker-compose.yml` que puxa a imagem oficial do Ory Kratos, monta um arquivo `users.db` SQLite local e vincula um `config/kratos.yml` além de um `identity.schema.json`. Depois de um `docker compose up`, o Kratos inicializa em modo de desenvolvimento, expondo suas APIs públicas e administrativas em localhost.

O `docker-compose.yml` espelha em grande parte o oficial quickstart.yml, mas ajustado para um laptop. O arquivo define `KRATOS_PUBLIC_URL` e `KRATOS_BROWSER_URL` como `http://localhost:4433` e `http://localhost:4455`, monta o diretório de configuração e conecta um container de servidor de e-mail para e-mails de verificação. As portas permanecem nas configurações padrão—4433 para público, 4434 para admin—portanto, qualquer código de cliente de exemplo da documentação funciona sem alterações.

A configuração então passa para dois arquivos principais: `kratos.yml` e o JSON do esquema de identidade. O esquema de identidade, copiado de email-password/identity.schema.json, define um JSON Schema com atributos como `email`, `first_name` e `last_name`, além de credenciais de senha. Você pode estendê-lo com campos personalizados—IDs de empresa, papéis ou flags de recursos—sem alterar o núcleo do Kratos.

O arquivo `kratos.yml` conecta tudo. Você aponta `selfservice.default_browser_return_url` e as origens permitidas para o seu aplicativo Next.js em `http://localhost:3000`, e lista os métodos HTTP e cabeçalhos CORS permitidos. Cada fluxo—`login`, `registro`, `recuperação`, `verificação`, `configurações`—recebe uma `ui_url` que mapeia diretamente para uma rota do frontend, como `/auth/login` ou `/auth/register`.

Segredos e configurações de e-mail vivem no mesmo YAML. As configurações de demonstração usam segredos de espaço reservado, mas as configurações de produção devem rotacionar chaves fortes para `secrets.cookie` e `secrets.cipher`. As credenciais SMTP configuram o servidor de e-mail para que o Kratos possa enviar links de verificação e recuperação, que depois redirecionam os usuários de volta para essas mesmas rotas `ui_url`.

No frontend, um aplicativo Next.js se conecta ao Kratos usando `@ory/nextjs` e Ory Elements. Variáveis de ambiente como `NEXT_PUBLIC_KRATOS_PUBLIC_URL=http://localhost:4433` e `KRATOS_BROWSER_URL=http://localhost:4455` vão para o arquivo `.env.local`, correspondendo às URLs do Docker. Um pequeno `ory.config.ts` conecta o SDK a esses endpoints.

O middleware do Next.js faz o trabalho pesado em tempo de execução. Um arquivo `middleware.ts` intercepta solicitações, chama a API de sessão do Kratos e, ou permite a passagem de usuários autenticados, ou redireciona visitantes anônimos para o fluxo de login gerenciado pelo Kratos. Com isso, você obtém telas de registro, login, verificação de e-mail e MFA totalmente integradas, rodando na sua própria infraestrutura, e não na do Okta ou Auth0.

Pilhas de identidade gerenciada geralmente desmoronam na parte frontal. Você ou se rende a uma caixa de login hospedada por um fornecedor, ou investe dias conectando o estado do formulário, validação e tratamento de erros para cada caso extremo de autenticação. Ory Elements existe especificamente para acabar com esse trabalho duro.

Em vez de enviar um único widget, o Elements é uma biblioteca completa de componentes de UI para React, Next.js (incluindo o App Router) e outros frameworks modernos. Você o instala como qualquer outro pacote npm, insere seus componentes nas suas rotas e os direciona para o seu endpoint público do Ory Kratos.

O truque: Elements não codifica rigidamente como um “formulário de login” deve ser. Kratos expõe cada fluxo—login, registro, recuperação, configurações, verificação—como um esquema JSON que descreve campos, métodos, tokens CSRF e mensagens. Elements lê esse esquema em tempo de execução e renderiza a interface certa automaticamente.

Acesse a rota de login no aplicativo de demonstração Next.js e o Elements busca o fluxo de login do Kratos, em seguida, constrói o formulário: campo de e-mail, campo de senha, botão de envio, mensagens de validação, além de quaisquer outros atributos que você definiu em seu esquema de identidade. Ative a autenticação multifator ou adicione um campo de nome de usuário no Kratos, e a interface renderizada se atualiza sem nenhuma reescrita no front-end.

Esse comportamento dinâmico se aplica a todos os fluxos. Fora da caixa, o Elements pode renderizar: - Login e registro - Configurações de conta e gerenciamento de perfil - Recuperação de senha e verificação de e-mail - Inscrição em MFA e telas de desafio

Os desenvolvedores têm controle total sobre a apresentação. Os componentes são enviados sem estilo ou com um estilo leve, para que você possa envolvê-los em seu próprio layout, aplicar Tailwind ou CSS Modules e personalizar cada tela sem reimplementar a lógica. Você mantém seu sistema de design enquanto terceiriza os detalhes complicados do protocolo.

As economias de tempo se acumulam rapidamente. Uma equipe típica pode passar de 1 a 2 semanas construindo e refinando formulários de autenticação, além de mais tempo mantendo-os à medida que os requisitos mudam. Com o Elements, a maior parte disso se resume a conectar algumas rotas e variáveis de ambiente, como mostra a demonstração da Better Stack.

Para personalização mais profunda—como mudar traços de identidade, fluxos ou políticas de segurança—você ajusta o Kratos em si. A documentação oficial do Ory Kratos orienta sobre como essas mudanças no backend fluem automaticamente para a sua interface de usuário alimentada pelo Elements.

A segurança está no centro do Ory Kratos, e não adicionada como um pensamento posterior. Desde o primeiro uso, o Kratos verifica todas as senhas no vasto repositório de vazamentos do Have I Been Pwned, rejeitando credenciais que já apareceram em vazamentos reais. Essa verificação sozinha elimina silenciosamente toda uma classe de tentativas de tomada de conta que prosperam no uso reutilizado de senhas.

Kratos também incorpora limitação de taxa, reforço de sessão e proteção contra CSRF, para que você não precise reinventá-los em middleware. As políticas de senha, a duração das sessões e a autenticação multifatorial estão na configuração, e não dispersas entre controladores e plugins. Você obtém uma postura de segurança consistente em clientes web, móveis e de API, porque tudo flui através do mesmo motor primeiro API.

Em vez de “melhores práticas” ad hoc, o Kratos segue as diretrizes do NIST, do IETF e de grandes grupos de pesquisa da Microsoft e do Google. Isso significa suporte para algoritmos modernos de hash, padrões de segurança de transporte que favorecem TLS em todos os lugares e fluxos de login que evitam anti-padrões, como regras arbitrárias de complexidade de senhas. Os mantenedores do projeto citam explicitamente o trabalho de Troy Hunt e outros sobre segurança utilizável, de modo que as configurações padrão tendem a ser “seguras e humanizadas”, em vez de “seguras e hostis”.

As equipes de conformidade se importam menos com palavras da moda e mais com controle, e o Kratos auto-hospedado oferece isso por design. Identidades de usuários, sessões e trilhas de auditoria vivem em seu próprio banco de dados, em sua própria região, sob suas próprias regras de retenção. Você escolhe a nuvem, a criptografia em repouso, a estratégia de backup e a história de residência de dados que se alinha ao seu regulador, e não a um cluster SaaS compartilhado de um fornecedor.

Para o GDPR, esse controle se traduz em ganhos práticos. Os contratos de processamento de dados se tornam mais simples quando você é o processador, não apenas um inquilino no silo de autorização de outra pessoa. O direito à exclusão, a exportação de dados e a limitação de propósito se tornam detalhes de implementação em sua própria infraestrutura, em vez de solicitações de suporte com um terceiro.

Auth0 e Okta podem ser configurados para atender a padrões semelhantes, mas você sempre opera dentro dos limites que eles impõem. Com o Ory Kratos, esses limites são suas próprias políticas, expressas como código e configurações, e auditadas juntamente com o resto da sua infraestrutura.

A autenticação multifatorial geralmente envolve a gestão de SDKs, bibliotecas de QR code e uma interface personalizada de configurações. Com Ory Kratos, você apenas altera algumas configurações em um arquivo YAML e, de repente, seu aplicativo fala TOTP como um produto de segurança experiente. O Kratos expõe todo o fluxo de 2FA através de sua API, permitindo que seu backend permaneça limpo e seu frontend não precise de uma infraestrutura de segurança sob medida.

Ative o TOTP na configuração do Kratos e o servidor adiciona imediatamente uma nova seção "2FA" aos fluxos de identidade. Quando um usuário opta por participar, o Kratos gera um segredo, o codifica como um URI `otpauth://`, e retorna uma carga útil de código QR pronta para renderização. Seu aplicativo não toca diretamente no segredo; o Kratos o armazena e o criptografa, em seguida, aplica a verificação em cada login subsequente.

A demonstração em vídeo do Next.js mostra como Ory Elements transforma essa capacidade de backend em uma tela de configurações totalmente gerenciada. Basta adicionar os componentes do Elements em uma rota `/settings`, apontá-los para sua URL pública do Kratos e você terá um painel de usuários ao vivo sem máquinas de estado React adicionais. Os usuários podem:

• 1Atualizar características do perfil (e-mail, primeiro nome, sobrenome)
• 2Mude a senha deles
• 3Ativar ou desativar a 2FA baseada em TOTP.

Tudo isso é enviado do Elements como componentes pré-construídos e acessíveis que se comunicam com o Kratos usando seus fluxos tipados. Você não está conectando formulários personalizados a pontos finais aleatórios; você está renderizando um modelo de formulário declarativo que o Kratos define em tempo de execução. Quando o Kratos adiciona ou muda um campo, a interface do usuário é atualizada automaticamente.

Durante a configuração do 2FA, o Kratos guia o usuário na digitalização do código QR e na verificação do primeiro código. O servidor valida o TOTP em relação ao seu segredo armazenado, lida com o desvio de tempo e marca o segundo fator como ativo no registro de identidade. Quando os usuários fazem login novamente, o Kratos atualiza a sessão de fator único para multi-fator somente após um TOTP válido, e seu aplicativo apenas lê o estado da sessão resultante.

Essa separação de responsabilidades é o ponto: Kratos é responsável pela geração de QR, armazenamento seguro e verificação TOTP; Ory Elements cuida da experiência do usuário. Seu aplicativo simplesmente consome um pipeline MFA seguro e totalmente gerenciado que você pode implementar em minutos em vez de semanas.

Plataformas de identidade gerenciada continuam atraindo desenvolvedores no Hacker News, e Ory Kratos aparece nesses tópicos como a opção “eu gostaria de ter começado com isso”. Os comentaristas destacam consistentemente seu design primeiro com API, fluxos HTTP limpos e o fato de que você pode executá-lo em qualquer lugar onde o Docker roda, desde um VPS de $5 até Kubernetes. Para startups enfrentando orçamentos do Auth0 ou Okta que escalam com MAUs, o apelo é claro: custos de infraestrutura previsíveis, sem taxas por usuário e sem um mecanismo de regras proprietário para desfazer depois.

Kratos se encaixa melhor quando a autenticação é uma parte central do produto, não apenas uma simples opção. Equipes que estão construindo SaaS multi-tenant, aplicativos sensíveis à privacidade ou cargas de trabalho regulamentadas têm total controle sobre os dados de identidade, esquemas e ciclo de vida. Você possui o banco de dados, define o esquema de identidade em JSON e decide como integrar os fluxos em seus clientes React, Next.js ou nativos por meio do Ory Elements ou da sua própria interface.

Projetos ideais geralmente compartilham algumas características: - Necessidade de personalização profunda dos fluxos de registro, recuperação e configurações - Requisitos em torno da residência de dados, GDPR ou auditoria interna - Plano de longo prazo para adicionar OAuth2, SSO e permissões detalhadas usando Ory Hydra, Keto e Oathkeeper

Essa arquitetura modular é exatamente o que conquista desenvolvedores cansados das plataformas de “um único produto de identidade”. Você pode começar com e-mail/senha mais TOTP e, em seguida, adicionar login social ou SSO empresarial mais tarde sem precisar reescrever tudo. O Centro de Documentação Ory explora isso, com guias discretos para cada serviço, em vez de um assistente de configuração monolítico.

Os trade-offs são reais, e os tópicos do Hacker News não os encobrem. Executar o Kratos significa gerenciar imagens Docker, configuração, migrações, SMTP, monitoramento e resposta a incidentes. Você substitui uma fatura de SaaS por sobrecarga operacional: módulos Terraform, pipelines de CI, agregação de logs e turnos de plantão.

Organizações lideradas por engenharia tendem a ver isso como um comércio justo. Se você já utiliza PostgreSQL, Redis e uma malha de serviços, adicionar mais um serviço em Go é apenas ruído, não caos. No entanto, para uma equipe de duas pessoas que está lançando um site de marketing com login, um serviço totalmente gerenciado ainda pode ser mais rápido, mesmo que a fatura do Auth0 cause um certo desconforto mais tarde.

Kratos é uma escolha consciente. Você compra liberdade do bloqueio do fornecedor ao custo de operar sua própria estrutura de identidade—e para uma parcela crescente de desenvolvedores, esse acordo finalmente parece atraente.

O controle define a infraestrutura moderna, e Ory Kratos é o que o controle sobre a identidade realmente significa. Em vez de alugar sua caixa de login do Auth0 ou Okta e torcer para que os preços não aumentem com seu próximo aumento de tráfego, você executa seu próprio servidor de identidade, o envia em Docker e o conecta a qualquer stack—Next.js, React, Go, você escolhe. A autenticação deixa de ser uma caixa preta e volta a ser um código de aplicativo comum.

Kratos inverte o jogo sobre a dependência de SaaS. Você obtém um motor primeiro API que gerencia registro, login, recuperação, verificação de e-mail e MFA, enquanto se mantém agnóstico em relação a frameworks de UI e frontend. Precisa de OAuth2, permissões granular ou um proxy ciente de identidade? Você conecta Hydra, Keto ou Oathkeeper quando realmente precisa deles, em vez de comprar uma plataforma tudo ou nada.

As mudanças na estrutura de custos também são relevantes. As cobranças de autenticação são geridas por usuários ativos mensais (MAUs) e recursos; um salto repentino de 10.000 para 100.000 usuários pode se transformar em uma surpresa de cinco dígitos. O Kratos é de código aberto, então seus principais custos são com computação, armazenamento e tempo de operação, e você pode auto-hospedar em qualquer lugar, desde um VPS de $5 até Kubernetes em várias regiões.

A experiência do desenvolvedor continua sendo de primeira classe. Ory Elements oferece componentes pré-construídos para React/Next.js, permitindo que você tenha fluxos de login, registro e configurações funcionando em horas, e não em semanas. O arquivo Docker Compose de início rápido, o esquema de identidade de exemplo e o aplicativo de exemplo em Next.js significam que você pode passar de zero a um stack em funcionamento com verificação de e-mail e 2FA baseado em TOTP em uma tarde.

Então, isso é menos sobre trocar um provedor de autenticação por outro e mais sobre decidir quem possui a sua camada de identidade. Se você está começando um novo SaaS, refatorando um monólito, ou tentando escapar do choque de preços do Auth0, reserve um dia e configure o Kratos. Audite sua autenticação atual: preços, dependência, caminhos de exportação e flexibilidade. Então, decida se seu próximo projeto deve seguir o roadmap de outra pessoa — ou o seu próprio.

O que é Ory Kratos?

Ory Kratos é um servidor de gerenciamento de identidade e usuários de código aberto, com foco em API. Ele gerencia os fluxos de autenticação principais, como registro, login, MFA e recuperação de conta, permitindo que os desenvolvedores hospedem e mantenham controle total sobre sua pilha de autenticação.

O Ory Kratos é totalmente gratuito?

Sim, o software central Ory Kratos é de código aberto e gratuito para auto-hospedagem. A Ory também oferece uma licença empresarial paga e um serviço de nuvem gerenciado (Ory Network) que fornecem recursos adicionais, como alta disponibilidade, SLAs e suporte dedicado.

Como o Ory Kratos se compara ao Auth0?

Kratos oferece maior flexibilidade, controle e custo-benefício por meio de seu modelo de código aberto auto-hospedado. O Auth0 é um serviço totalmente gerenciado que proporciona configuração mais rápida e extensas integrações pré-construídas, mas vem com a desvantagem de aprisionamento do fornecedor e custos potencialmente mais altos.

Posso migrar meus usuários existentes do Auth0 para o Ory Kratos?

Sim, a Ory oferece documentação e guias sobre como migrar uma base de usuários existente de plataformas como Auth0 para o Kratos, permitindo uma transição mais suave.