Saindo do Auth0: o que realmente migra, e a única coisa que eles não vão entregar

A maioria das equipes não abandona o Auth0 por não gostar dele. Elas saem porque a conta disparou, ou porque SAML e SCIM acabaram ficando atrás de um nível corporativo cobrado por conexão, e o link de SSO de cada novo cliente faz o contador girar. Depois consideram migrar de verdade seu provedor de identidade, concluem que parece aterrorizante e ficam mais um ano.

É menos aterrorizante do que aparenta. Eis o que uma migração real do Auth0 envolve (as partes chatas, as partes complicadas e a única parte genuinamente difícil) para que você julgue por conta própria.

O que há no seu locatário do Auth0

Um punhado de coisas precisa pousar em algum lugar novo:

• Aplicações → clientes OAuth/OIDC. Callbacks, URLs de logout, origens permitidas, tipos de concessão e o segredo de cliente. Mecânico.
• APIs (servidores de recursos) + scopes → audiences e scopes, ligados aos clientes que os usam (o Auth0 registra isso como «client grants»).
• Papéis e suas atribuições → papéis + vínculos de papel por usuário.
• Conexões → conexões corporativas (OIDC/SAML), sociais e de banco de dados. O OIDC corporativo mapeia de forma limpa para um provedor federado; o resto você reconfigura.
• Usuários → perfis, metadados e identidades sociais/corporativas vinculadas.

Nada disso é difícil em princípio. O nervosismo vem de três coisas específicas.

As três coisas que deixam as pessoas nervosas

1. Manter as identidades estáveis. Seus usuários são referenciados pelo sub deles (e suas aplicações pelo client_id) por toda parte: refresh tokens em poder de aplicações a jusante, linhas SCIM nos IdP dos seus clientes, IDs de usuário armazenados no seu próprio banco de dados. Se uma migração cunhar novos IDs, tudo isso quebra silenciosamente. A solução é simples de enunciar e essencial de acertar: preservar o user_id do Auth0 como sub e manter o client_id idêntico. Aí nada a jusante percebe.

2. As senhas, a parte genuinamente difícil. A Management API do Auth0 nunca devolve os hashes de senhas. É uma política deliberada do Auth0, não uma lacuna da sua ferramenta. Você tem dois caminhos honestos:

• Solicitar a exportação em massa assistida pelo suporte do Auth0, que lhe entrega um arquivo NDJSON com o hash bcrypt de cada usuário. bcrypt é portável: qualquer coisa que verifique bcrypt consegue receber esses hashes idênticos, e seus usuários não redefinem nada.
• Ou pular os hashes por completo e fazer com que os usuários definam uma nova senha no primeiro login. Nada se «perde» (não havia hash a carregar) mas é um passo visível para seus usuários.

Não existe nenhuma API de autoatendimento para os hashes. Quem lhe disser que uma exportação do Auth0 com um clique inclui as senhas sem esse arquivo do suporte está enrolando.

3. O teto de 1.000 usuários. A API de listagem de usuários do Auth0 retorna no máximo 1.000 usuários. Para um locatário maior, o arquivo de exportação em massa (o mesmo que carrega os hashes) é a fonte real e completa de usuários, e não a API ao vivo.

Transformando isso em um clique

Foi isto que construímos no Authagonal. Você aponta o importador para uma aplicação machine-to-machine do Auth0 (apenas scopes de leitura), e ele:

• Executa primeiro uma prévia somente leitura: conta cada aplicação, API, papel, conexão e usuário que vai importar e sinaliza tudo que precisa de atenção. Nada é gravado até você confirmar.
• Traz as aplicações, os scopes/audiences de API, os papéis + atribuições, os usuários + metadados e as conexões OIDC corporativas, preservando sub e client_id para que os tokens e referências existentes continuem resolvendo.
• Refaz o hash dos segredos de cliente do Auth0 (legíveis em texto puro) para que suas aplicações continuem se autenticando sem rotação.
• Importa os hashes de senha bcrypt idênticos se você fornecer o arquivo de exportação, e esse arquivo também levanta o teto de 1.000 usuários. Sem exportação? Os usuários definem uma senha no primeiro login.

E como os recursos corporativos (SAML, SCIM, MFA, logs de auditoria, domínios personalizados) estão incluídos em todos os planos em vez de cobrados por conexão, aquilo que o empurrou para a saída não está à sua espera do outro lado.

Um adendo sobre testar migrações

Testamos o importador contra um banco de dados real e pré-povoado, não contra mocks, e isso valeu a pena. O ASP.NET Identity armazena LockoutEnd como um datetimeoffset, e lê-lo com GetDateTime() lança exceção nesse tipo. Um único usuário bloqueado teria feito uma importação inteira falhar. Você só pega isso rodando o importador real contra dados reais. Se você está avaliando alguma ferramenta de migração, pergunte como ela é testada: «mockamos a API de origem» não é a mesma coisa que «rodamos contra um locatário povoado».

Se você está de olho na saída

A migração é mais chata do que você teme (faça a prévia, mantenha seus IDs, decida seu caminho de senhas) sendo a única restrição real a exportação de hashes do Auth0. Se quiser ver o que viria do seu locatário, a prévia é somente leitura e mostra tudo antes de você confirmar.

→ Migrar do Auth0