DEV Community: authagonal

Our service discovery caught its own failure and switched itself off

authagonal — Wed, 01 Jul 2026 23:13:01 +0000

We had a three-replica cluster that kept disagreeing with itself. Background jobs ran two and three times over. The answer wasn't in the logs; it was in our own code. The peer-discovery routine had a catch block, and the comment inside it said, more or less, "multicast failed, discovery disabled." Our service discovery was catching its own failure and quietly turning itself off, and it had been doing exactly that in production from day one.

This is the story of why a clustering protocol that's correct on a server in a rack is the wrong tool the moment you put it on a managed platform, and why the fix was to delete it rather than repair it.

What the cluster is actually for

An auth server runs as more than one replica for availability. The replicas are mostly independent: any of them can validate a token or check a password. But a few jobs must run once, not once per replica. The data-retention sweep that deletes expired records. The pass that fires customer webhooks. Anything that reaches out and has a side effect. For those you need two things the cluster has to agree on: who the members are, and which one of them is the leader that runs the singleton work.

Our original answer was the classic one: gossip. Each node chatters with its peers, membership is an emergent property of who's reachable, and the group elects a leader from the agreed set. It's a beautiful design. It also assumes the nodes can find each other, and the way the old code found them was multicast: shout on the local network segment and see who answers.

Why it broke, silently

Managed Kubernetes does not carry multicast. Neither does almost any cloud network you don't build yourself. The shout went out and nothing came back, every time. So discovery "failed," the catch block fired, and each node concluded it was alone in the world.

At one replica that's harmless. At three it's split-brain by construction: three nodes, each certain it's the only member, each electing itself leader, each running the singleton work. The retention sweep ran on all three. The webhook pass fired every customer's webhook three times. None of it threw an error, because from each lonely node's point of view everything was fine. The bug wasn't a crash; it was three programs each behaving perfectly correctly in a world they had wrong.

The fix was to stop discovering peers at all

Here's the reframe that made the whole thing collapse to a few lines: we were trying to rebuild, with a chatty protocol, a fact the platform already stores for us with strong consistency. We run on a cloud that hands us a strongly-consistent store. Leader election doesn't need consensus among peers if there's already one place everyone can agree on.

So leadership became a blob lease. One blob, one lease. Whoever holds the lease is the leader. The lease has a timeout, so a leader that dies stops renewing and the lease frees itself for the next taker. There is no peer discovery, no quorum math, no multicast, and no catch block waiting to disable it. Coordination and events ride a small table that acts as a bus between the nodes.

The property I didn't expect to love: you can open Storage Explorer and see the cluster's mind. Who holds the lease right now. What's queued on the bus. Membership stopped being something you infer from a protocol's behavior and became a row you can read. When the thing that decides who runs your destructive jobs is a value you can look at, debugging stops being archaeology.

The part where we deleted a clever thing on purpose

While we were in there, we deleted a distributed rate-limiter built on a conflict-free replicated data type, a CRDT that merged per-node counters into a global count without coordination. It was genuinely elegant. It was also solving a problem we'd moved. The global rate limit belongs at the edge, where requests arrive, not reconstructed inside the cluster with a data structure that needs a paragraph to explain. Out it came.

Deleting working code feels like a loss until you count what you stop maintaining. We removed the gossip layer, the multicast assumption, the self-disabling catch block, and the CRDT, and replaced all of it with a lease and a table. The line count went down and the number of states the system can be in went down with it.

The lesson, factored out

Gossip and multicast membership are the right tools on bare metal or a flat network you control. They are the wrong tools on a platform whose network won't carry the very mechanism they depend on, and the failure mode isn't a loud crash; it's a quiet fallback that looks like it's working. Before you port a distributed-systems pattern onto managed infrastructure, ask what it assumes about the network, and ask what the platform already gives you for free. Ours was already running a strongly-consistent store. A lease in that store was a simpler, more correct leader election than the protocol we'd been carrying, and it's one we can watch.

If you're running auth, the parts that hold your keys and decide who runs your destructive jobs should be the most boring and the most inspectable things you own. We made ours boring. It was an upgrade.

Importar usuários sem redefinição de senha

authagonal — Wed, 01 Jul 2026 23:12:22 +0000

Todo guia de migração de identidade acaba chegando ao mesmo parágrafo, e ele soa sempre um pouco constrangido: "os usuários precisarão redefinir suas senhas." Isso é tratado como uma lei da natureza. Não é. É uma escolha, quase sempre imposta por uma ferramenta que não quis fazer o mais difícil.

O mais difícil é verificar no lugar os hashes de senha existentes dos seus usuários, para que, depois da virada, eles entrem com exatamente as mesmas credenciais que tinham antes e nunca percebam que algo aconteceu. Se você consegue fazer isso ou não se resume a uma única pergunta: dá para obter os hashes antigos, e o novo sistema consegue verificá-los?

Hashes de senha são mais portáveis do que se imagina

Um hash de senha não é um algoritmo secreto. bcrypt é bcrypt. Um hash bcrypt carrega o próprio fator de custo e o próprio sal dentro da string, então qualquer coisa que implemente bcrypt pode verificar um hash produzido por qualquer outro sistema bcrypt. O mesmo vale para o formato PBKDF2 que o ASP.NET Identity usa: documentado, versionado, autodescritivo. Se você sabe o que tem em mãos, dá para conferir uma senha contra ele sem nunca conhecer a senha.

Portanto, uma migração que preserva os logins não precisa do texto puro (ninguém o tem) nem de re-hashear todo mundo de antemão. Ela precisa obter os hashes armazenados e verificá-los no login, elevando cada um ao próprio formato em silêncio na primeira vez que o usuário entra. Essa última parte é a migração preguiçosa: leve o hash antigo, verifique-o uma vez, substitua-o de forma transparente. Ao longo de algumas semanas de logins normais, sua tabela de usuários se re-hasheia sozinha e os formatos antigos vão sumindo, com zero redefinições e zero chamados de suporte.

A parte do caminho duplo

O detalhe é que fontes diferentes entregam formatos diferentes, e um bom importador verifica os dois:

De um Duende / ASP.NET Identity auto-hospedado: os hashes V3 PBKDF2 (e qualquer bcrypt legado) verificam de forma nativa e são re-hasheados no primeiro login. Esse é o caso fácil, porque é o mesmo esquema que o destino já usa. A maioria das equipes se surpreende com como é limpo.
Do Auth0: os hashes bcrypt verificam ao pé da letra. O problema não é o formato, é consegui-los.

Quando você realmente não consegue

A Management API do Auth0 nunca devolve hashes de senha. É uma política deliberada, não uma lacuna na ferramenta de ninguém, e você deveria desconfiar de qualquer "exportação do Auth0 em um clique" que afirme incluir senhas sem isso. O caminho suportado é uma exportação em massa assistida pelo suporte: um arquivo NDJSON com o hash bcrypt de cada usuário. Consiga esse arquivo e os hashes são importados ao pé da letra, migração preguiçosa inclusa, e a virada fica invisível.

Se você não pode esperar por isso, a alternativa é a versão honesta do parágrafo constrangido: os usuários definem uma senha nova no primeiro login. Nada foi perdido, porque não havia hash para levar. A diferença é que você escolheu isso de forma consciente, e não porque a ferramenta não dava conta de algo melhor.

Por que isso importa mais do que parece

Uma redefinição forçada é a coisa mais visível e mais alarmante que você pode fazer a uma base de usuários no meio de uma migração. Ela gera carga de suporte, acostuma os usuários a esperar um e-mail em formato de phishing do tipo "clique aqui para redefinir", e é o momento em que uma mudança silenciosa de infraestrutura vira problema de todo mundo. Evitar isso é boa parte do que faz uma migração parecer que nada aconteceu, que é exatamente como uma migração deveria parecer.

Então, antes de aceitar o "todo mundo redefine", faça as duas perguntas. Para a maioria das viradas, a resposta é sim para ambas, e o parágrafo constrangido nunca foi necessário.

Veja o que uma importação carregaria: a prévia é somente leitura e mostra tudo a você antes que qualquer coisa seja gravada.

Importar usuarios sin restablecer la contraseña

authagonal — Wed, 01 Jul 2026 23:12:08 +0000

Toda guía de migración de identidad acaba llegando al mismo párrafo, y siempre suena un poco a disculpa: "los usuarios tendrán que restablecer su contraseña." Se trata como si fuera una ley de la naturaleza. No lo es. Es una decisión, casi siempre impuesta por una herramienta que no quiso hacer lo más difícil.

Lo más difícil es verificar en su sitio los hashes de contraseña existentes de tus usuarios, para que tras el cambio inicien sesión con exactamente las mismas credenciales que tenían antes y nunca noten que pasó nada. Que puedas hacerlo se reduce a una sola pregunta: ¿puedes obtener los hashes antiguos y puede el sistema nuevo verificarlos?

Los hashes de contraseña son más portables de lo que la gente cree

Un hash de contraseña no es un algoritmo secreto. bcrypt es bcrypt. Un hash bcrypt lleva su propio factor de coste y su sal dentro de la propia cadena, así que cualquier cosa que implemente bcrypt puede verificar un hash producido por cualquier otro sistema bcrypt. Lo mismo ocurre con el formato PBKDF2 que usa ASP.NET Identity: documentado, versionado, autodescriptivo. Si sabes qué tienes entre manos, puedes comprobar una contraseña contra él sin llegar a conocer nunca la contraseña.

Así que una migración que conserva los inicios de sesión no necesita el texto plano (nadie lo tiene) ni rehashear a todo el mundo de antemano. Necesita obtener los hashes almacenados y verificarlos al iniciar sesión, elevando cada uno a su propio formato en silencio la primera vez que el usuario entra. Esa última parte es la migración perezosa: te llevas el hash antiguo, lo verificas una vez y lo sustituyes de forma transparente. A lo largo de unas semanas de inicios de sesión normales, tu tabla de usuarios se rehashea sola y los formatos heredados van desapareciendo, con cero restablecimientos y cero tickets de soporte.

La parte de la doble vía

El matiz es que las distintas fuentes te entregan distintos formatos, y un buen importador verifica ambos:

Desde un Duende / ASP.NET Identity autoalojado: los hashes V3 PBKDF2 (y cualquier bcrypt heredado) se verifican de forma nativa y se rehashean en el primer inicio de sesión. Este es el caso fácil, porque es el mismo esquema que el destino ya usa. A la mayoría de los equipos les sorprende que sea tan limpio.
Desde Auth0: los hashes bcrypt se verifican al pie de la letra. El problema no es el formato, sino conseguirlos.

Cuándo de verdad no puedes

La Management API de Auth0 nunca devuelve hashes de contraseña. Es una política deliberada, no un hueco en las herramientas de nadie, y deberías desconfiar de cualquier "exportación de Auth0 con un clic" que afirme incluir contraseñas sin ella. La vía soportada es una exportación masiva asistida por soporte: un archivo NDJSON con el hash bcrypt de cada usuario. Consigue ese archivo y los hashes se importan al pie de la letra, con migración perezosa incluida, y el cambio queda invisible.

Si no puedes esperar a ello, la alternativa es la versión honesta del párrafo de disculpa: los usuarios fijan una contraseña nueva en el primer inicio de sesión. No se perdió nada, porque no había hash que llevarse. La diferencia es que lo elegiste a sabiendas, y no porque la herramienta no supiera hacer nada mejor.

Por qué esto importa más de lo que parece

Un restablecimiento forzoso es lo más visible y más alarmante que puedes hacerle a una base de usuarios en mitad de una migración. Genera carga de soporte, acostumbra a los usuarios a esperar un correo con forma de phishing del tipo "haz clic aquí para restablecer", y es el momento en que un cambio de infraestructura silencioso se convierte en el problema de todos. Evitarlo es buena parte de lo que hace que una migración se sienta como que no pasó nada, que es como debería sentirse una migración.

Así que antes de aceptar el "todos restablecen", haz las dos preguntas. Para la mayoría de los cambios la respuesta es sí en ambas, y el párrafo de disculpa nunca fue necesario.

Mira qué se llevaría una importación: la vista previa es de solo lectura y te muestra todo antes de que se escriba nada.

La taxe sur les fonctionnalités : arrêtez de payer pour actionner des interrupteurs qui ne coûtent rien

authagonal — Wed, 01 Jul 2026 10:36:09 +0000

Quelque part sur la page tarifaire de votre fournisseur d'authentification se trouve une case à cocher qui coûte, par mois, plus cher que l'ordinateur portable d'un ingénieur, et dont la fourniture ne coûte rien. Ce texte parle de cette case.

Il existe un site appelé sso.tax. Il existe parce que tant d'éditeurs de logiciels facturent un tel supplément pour le Single Sign-on, une fonctionnalité dont l'exploitation ne leur coûte pratiquement rien, que quelqu'un a dû créer une liste publique de mise au pilori, simplement pour suivre le mouvement. SAML est un standard établi depuis deux décennies. Le code est écrit. Les octets sont les mêmes octets, qu'un utilisateur se connecte avec un mot de passe ou via un fournisseur d'identité d'entreprise. Et pourtant, « activer le SSO » est immanquablement la ligne qui double votre facture, ou celle qui finit par imposer le redouté appel au service commercial. Ce n'est pas un prix. C'est un péage sur une route déjà construite et déjà payée.

Voici la distinction que l'industrie préférerait que vous ne traciez jamais clairement. Il y a une différence entre facturer le coût et facturer la permission. Facturer le coût est honnête : si j'envoie plus de trafic, stocke plus de données ou maintiens plus d'utilisateurs actifs mensuels, me servir coûte réellement plus cher, et vous devriez le facturer. Facturer la permission est tout autre chose. C'est me faire payer pour basculer un booléen que vous avez déjà écrit, sur une infrastructure qui tourne déjà, pour une fonctionnalité dont le coût marginal, pour vous, avoisine zéro. La plupart des pages tarifaires d'authentification sont surtout la seconde chose déguisée en la première.

Une fois que vous le voyez, vous ne pouvez plus ne pas le voir. Le Single Sign-on enfermé derrière le palier « Enterprise », ou facturé par connexion à plus de cent dollars par mois chacune, et parfois facturé deux fois : une fois pour la connexion SSO, et encore une fois pour le provisioning SCIM qui emprunte exactement la même intégration. L'authentification multifacteur vendue comme une option payante, c'est-à-dire un supplément pour éviter que vos utilisateurs se fassent hameçonner. Les journaux d'audit découpés en fenêtres de rétention selon le palier, comme si une ligne du trimestre dernier coûtait plus cher à stocker qu'une de ce matin. Les jetons machine à machine plafonnés et facturés à l'usage, comme si signer un JWT était un minerai rare. Et la forme la plus pure de toutes : des fournisseurs qui dégroupent le SSO, le MFA et le provisioning des utilisateurs en trois produits distincts par siège, si bien que ce que vous pensiez acheter (la connexion) arrive en morceaux, chacun avec sa propre étiquette de prix.

Puis il y a l'autre variante : le droit d'entrée. Au moins un produit d'identité bien connu réclame plusieurs milliers de dollars par an avant que vous n'ayez authentifié un seul être humain. SAML est, par-dessus, une option payante, et même là, vous n'avez sous licence que la tuyauterie du protocole. Vous construisez toujours les écrans de connexion, l'interface d'administration, l'enrôlement MFA, la piste d'audit ; vous hébergez, corrigez et faites évoluer l'ensemble vous-même. La licence est le droit d'entrée. Le produit réel est laissé en exercice à votre équipe d'ingénierie.

Le nom poli de tout cela est « tarification à la valeur », et dans bien des activités, c'est une idée parfaitement juste. L'authentification en a une version plus laide, car les fonctionnalités verrouillées sont celles de sécurité et de conformité : précisément celles que vous êtes le moins en mesure de refuser. Vous pouvez vivre sans un tableau de bord plus joli. Vous ne pouvez pas vivre sans SSO quand le service achats de votre plus gros prospect l'exige, ni sans MFA quand votre propre auditeur SOC 2 le réclame. L'industrie a donc appris à placer précisément ces fonctionnalités derrière la porte à la plus forte marge. C'est une taxe sur le fait d'agir de façon responsable, prélevée à l'instant précis où vous avez le moins de marge pour dire non.

Alors, pour quoi devriez-vous payer un fournisseur d'authentification ? Pour les choses qui lui coûtent réellement de l'argent. L'échelle coûte de l'argent : plus d'utilisateurs actifs mensuels, c'est plus de sessions, plus de jetons, plus de stockage, plus de trafic sortant, des ressources réelles qui croissent à mesure que vous croissez. Le support coûte de l'argent : des humains qui répondent à des questions difficiles à 2 heures du matin, c'est une dépense réelle et récurrente. Payez pour cela, volontiers. C'est une facture honnête. Ce pour quoi vous ne devriez jamais payer, c'est le privilège d'activer du code déjà écrit et déjà déployé pour tous les autres sur la plateforme.

C'est toute la raison pour laquelle la tarification d'Authagonal est façonnée ainsi. Nous facturons l'échelle et le support, et la liste s'arrête là. Les formules diffèrent selon le nombre d'utilisateurs actifs mensuels que vous avez et le niveau d'accompagnement que vous souhaitez, car ce sont les seules choses qui nous coûtent réellement plus cher à mesure que vous utilisez davantage. Tout le reste est inclus à chaque palier, dès la formule d'entrée : connexions SSO et SAML illimitées, provisioning SCIM, MFA, contrôle d'accès basé sur les rôles, journaux d'audit, et personnalisation de marque sur votre propre domaine. Pas « inclus en Enterprise ». Inclus. La formule la moins chère et la plus grande font tourner le même ensemble de fonctionnalités ; la seule chose qui change, c'est la taille que vous avez le droit d'atteindre.

Car que SAML soit activé ou non pour votre locataire est une décision de tarification, pas d'ingénierie. Le travail est fait dans un cas comme dans l'autre. Vous facturer un supplément pour l'activer ne récupère aucun coût. Cela mesure combien vous tolérerez avant de partir. Nous préférons simplement ne pas mener cette expérience sur nos propres clients. Construire les fonctionnalités une fois, les livrer à tout le monde, et gagner de l'argent de la manière ennuyeuse et honnête : quand les gens qui vous utilisent grandissent.

On apprend beaucoup de la façon dont une entreprise fixe ses prix. La plupart des fournisseurs d'authentification facturent des choses qui ne leur coûtent presque rien ; chez nous, cela se résume à une ligne : payez pour la taille que vous atteignez, pas pour les interrupteurs que vous avez le droit d'actionner.

Si c'est la facture que vous préféreriez recevoir, voici exactement qui facture quoi. Le SSO est de notre côté de la table, sans supplément.

El impuesto sobre las funciones: deja de pagar por accionar interruptores que no cuestan nada

authagonal — Wed, 01 Jul 2026 03:43:54 +0000

En algún lugar de la página de precios de tu proveedor de autenticación hay una casilla que cuesta, al mes, más que el portátil de un ingeniero, y cuya provisión no cuesta nada. Este texto trata sobre esa casilla.

Existe un sitio web llamado sso.tax. Existe porque tantas empresas de software cobran un recargo tan alto por el inicio de sesión único, una función cuya operación no les cuesta prácticamente nada, que alguien tuvo que crear una lista pública de escarnio solo para llevar la cuenta. SAML es un estándar consolidado desde hace dos décadas. El código está escrito. Los bytes son los mismos bytes, tanto si un usuario inicia sesión con una contraseña como a través de un proveedor de identidad corporativo. Y aun así, «activar el SSO» es de forma fiable la línea que duplica tu factura, o la que finalmente obliga a la temida llamada a ventas. Eso no es un precio. Es un peaje en una carretera que ya estaba construida y pagada.

Aquí está la distinción que la industria preferiría que nunca trazaras con claridad. Hay una diferencia entre cobrar el coste y cobrar el permiso. Cobrar el coste es honesto: si envío más tráfico, almaceno más datos o mantengo activos a más usuarios activos mensuales, atenderme cuesta realmente más, y deberías cobrarlo. Cobrar el permiso es algo completamente distinto. Es cobrarme por accionar un booleano que ya has escrito, sobre una infraestructura que ya está en marcha, por una función cuyo coste marginal, para ti, se redondea a cero. La mayoría de las páginas de precios de autenticación son sobre todo lo segundo disfrazado de lo primero.

Una vez que lo ves, no puedes dejar de verlo. El inicio de sesión único encerrado tras el nivel «Enterprise», o cobrado por conexión a más de cien dólares al mes cada una, y a veces cobrado dos veces: una por la conexión SSO y otra por el aprovisionamiento SCIM que viaja sobre esa misma integración. La autenticación multifactor vendida como una mejora de pago, es decir, un recargo por no dejar que tus usuarios caigan en el phishing. Los registros de auditoría troceados en ventanas de retención según el nivel, como si una fila del trimestre pasado costara más almacenar que una de esta mañana. Los tokens de máquina a máquina limitados y cobrados por uso, como si firmar un JWT fuera un mineral escaso. Y la forma más pura de todas: proveedores que desagregan el SSO, el MFA y el aprovisionamiento de usuarios en tres productos distintos por puesto, de modo que lo que creías comprar (el inicio de sesión) aparece a trozos, cada uno con su propia etiqueta de precio.

Luego está la otra variante: la entrada. Al menos un conocido producto de identidad pide varios miles de dólares al año antes de que hayas autenticado a un solo ser humano. SAML es, por encima de eso, un complemento de pago, e incluso entonces solo has licenciado la fontanería del protocolo. Sigues construyendo las pantallas de inicio de sesión, la interfaz de administración, el registro en MFA, el rastro de auditoría; sigues alojando, parcheando y escalando todo tú mismo. La licencia es la entrada. El producto real queda como ejercicio para tu equipo de ingeniería.

El nombre cortés de todo esto es «precios basados en el valor», y en muchos negocios es una idea perfectamente justa. La autenticación tiene una versión más fea, porque las funciones que se bloquean son las de seguridad y cumplimiento: precisamente las que menos puedes permitirte rechazar. Puedes vivir sin un panel más bonito. No puedes vivir sin SSO cuando el departamento de compras de tu mayor cliente potencial lo exige, ni sin MFA cuando lo exige tu propio auditor de SOC 2. Así que la industria aprendió a poner precisamente esas funciones tras la puerta de mayor margen. Es un impuesto sobre hacer lo responsable, cobrado en el momento exacto en que tienes menos margen para decir no.

Entonces, ¿por qué deberías pagar a un proveedor de autenticación? Por las cosas que realmente le cuestan dinero. La escala cuesta dinero: más usuarios activos mensuales significan más sesiones, más tokens, más almacenamiento, más salida de datos, recursos reales que crecen a medida que tú creces. El soporte cuesta dinero: personas que responden preguntas difíciles a las 2 de la madrugada son un gasto real y recurrente. Paga por eso, con gusto. Esa es una factura honesta. Por lo que nunca deberías pagar es por el privilegio de encender código que ya está escrito y ya desplegado para todos los demás en la plataforma.

Esta es toda la razón por la que los precios de Authagonal tienen la forma que tienen. Cobramos por la escala y por el soporte, y ahí acaba la lista. Los planes difieren según cuántos usuarios activos mensuales tengas y cuánto acompañamiento quieras, porque son las únicas cosas que de verdad nos cuestan más a medida que usas más. Todo lo demás está incluido en todos los niveles, desde el plan de entrada: conexiones SSO y SAML ilimitadas, aprovisionamiento SCIM, MFA, control de acceso basado en roles, registros de auditoría y personalización de marca en tu propio dominio. No «incluido en Enterprise». Incluido. El plan más barato y el más grande ejecutan el mismo conjunto de funciones; lo único que cambia es cuánto se te permite crecer.

Porque que SAML esté activado o no para tu inquilino es una decisión de precios, no de ingeniería. El trabajo está hecho de un modo u otro. Cobrarte un extra por habilitarlo no recupera ningún coste. Mide cuánto tolerarás antes de marcharte. Sencillamente preferimos no hacer ese experimento con nuestros propios clientes. Construir las funciones una vez, entregarlas a todos y ganar dinero de la forma aburrida y honesta: cuando crece la gente que te usa.

Se aprende mucho de cómo una empresa fija sus precios. La mayoría de los proveedores de autenticación cobran por cosas que no les cuestan casi nada; en nuestro caso, se reduce a una línea: paga por lo grande que llegues a ser, no por qué interruptores se te permite accionar.

Si esa es la factura que preferirías recibir, aquí está exactamente quién cobra por qué. El SSO está en nuestro lado de la mesa, sin coste adicional.

O imposto das funcionalidades: pare de pagar para acionar interruptores que não custam nada

authagonal — Wed, 01 Jul 2026 02:05:40 +0000

Em algum lugar da página de preços do seu fornecedor de autenticação há uma caixa de seleção que custa, por mês, mais do que o portátil de um engenheiro, e cuja disponibilização não custa nada. Este texto é sobre essa caixa.

Existe um site chamado sso.tax. Ele existe porque tantas empresas de software cobram um valor adicional tão alto pelo início de sessão único (Single Sign-on), uma funcionalidade cuja operação não lhes custa praticamente nada, que alguém teve de criar uma lista pública de exposição apenas para conseguir acompanhar. O SAML é um padrão consolidado há duas décadas. O código está escrito. Os bytes são os mesmos bytes, quer um utilizador entre com uma palavra-passe quer através de um fornecedor de identidade corporativo. E, ainda assim, "ativar o SSO" é, de forma fiável, a linha que duplica a sua fatura, ou aquela que finalmente obriga ao temido telefonema para o setor comercial. Isso não é um preço. É uma portagem numa estrada que já estava construída e paga.

Aqui está a distinção que o setor preferia que você nunca traçasse com clareza. Há uma diferença entre cobrar pelo custo e cobrar pela permissão. Cobrar pelo custo é honesto: se eu gero mais tráfego, armazeno mais dados ou mantenho mais utilizadores ativos mensais, atender-me custa realmente mais, e você deve cobrar por isso. Cobrar pela permissão é algo completamente diferente. É cobrar-me para acionar um booleano que você já escreveu, numa infraestrutura que já está a funcionar, por uma funcionalidade cujo custo marginal, para você, se aproxima de zero. A maioria das páginas de preços de autenticação é, sobretudo, a segunda coisa vestida com a roupa da primeira.

Depois de ver, você não consegue mais deixar de ver. O início de sessão único trancado atrás do nível "Enterprise", ou cobrado por ligação a mais de cem dólares por mês cada uma, e por vezes cobrado duas vezes: uma pela ligação SSO e outra pelo aprovisionamento SCIM que percorre exatamente a mesma integração. A autenticação multifator vendida como uma atualização paga, ou seja, uma sobretaxa por não deixar que os seus utilizadores sejam vítimas de phishing. Os registos de auditoria fatiados em janelas de retenção por nível, como se uma linha do trimestre passado custasse mais a armazenar do que uma desta manhã. Os tokens de máquina para máquina limitados e cobrados por utilização, como se assinar um JWT fosse um mineral raro. E a forma mais pura de todas: fornecedores que separam o SSO, o MFA e o aprovisionamento de utilizadores em três produtos distintos por lugar, de modo que aquilo que você pensava estar a comprar (o início de sessão) aparece aos pedaços, cada um com a sua própria etiqueta de preço.

Depois há a outra variante: a entrada. Pelo menos um conhecido produto de identidade pede vários milhares de dólares por ano antes de você ter autenticado um único ser humano. O SAML é, por cima disso, um extra pago, e mesmo assim você só licenciou a canalização do protocolo. Você continua a construir os ecrãs de início de sessão, a interface de administração, a inscrição no MFA, o rasto de auditoria; continua a alojar, corrigir e escalar tudo sozinho. A licença é a entrada. O produto real fica como exercício para a sua equipa de engenharia.

O nome educado para tudo isto é "preços baseados no valor" e, em muitos neg��cios, é uma ideia perfeitamente justa. A autenticação tem uma versão mais feia, porque as funcionalidades bloqueadas são as de segurança e conformidade: precisamente aquelas que você tem menos capacidade de recusar. Você consegue viver sem um painel mais bonito. Não consegue viver sem SSO quando o departamento de compras do seu maior potencial cliente o exige, nem sem MFA quando o seu próprio auditor de SOC 2 o exige. Então o setor aprendeu a colocar exatamente essas funcionalidades atrás da porta de maior margem. É um imposto sobre fazer a coisa responsável, cobrado no momento exato em que você tem menos margem para dizer não.

Então, pelo que é que você deveria pagar a um fornecedor de autenticação? Pelas coisas que realmente lhe custam dinheiro. A escala custa dinheiro: mais utilizadores ativos mensais significam mais sessões, mais tokens, mais armazenamento, mais tráfego de saída, recursos reais que crescem à medida que você cresce. O suporte custa dinheiro: pessoas a responder a perguntas difíceis às 2 da manhã são uma despesa real e recorrente. Pague por isso, de bom grado. Essa é uma fatura honesta. Aquilo pelo que você nunca deveria pagar é o privilégio de ligar código que já está escrito e já implementado para todos os outros na plataforma.

É esta toda a razão pela qual os preços da Authagonal têm a forma que têm. Cobramos pela escala e pelo suporte, e a lista acaba aí. Os planos diferem conforme o número de utilizadores ativos mensais que você tem e o nível de acompanhamento que pretende, porque essas são as únicas coisas que realmente nos custam mais à medida que você usa mais. Tudo o resto está incluído em todos os níveis, logo a partir do plano de entrada: ligações SSO e SAML ilimitadas, aprovisionamento SCIM, MFA, controlo de acesso baseado em funções, registos de auditoria e personalização de marca no seu próprio domínio. Não "incluído no Enterprise". Incluído. O plano mais barato e o maior plano executam o mesmo conjunto de funcionalidades; a única coisa que muda é o tamanho que você tem permissão para atingir.

Porque se o SAML está ligado ou não para o seu inquilino é uma decisão de preços, não de engenharia. O trabalho está feito de qualquer maneira. Cobrar-lhe um extra para o ativar não recupera nenhum custo. Mede quanto você tolerará antes de ir embora. Simplesmente preferimos não fazer essa experiência com os nossos próprios clientes. Construir as funcionalidades uma vez, entregá-las a todos e ganhar dinheiro da forma aborrecida e honesta: quando as pessoas que o usam crescem.

Dá para perceber muito a partir da forma como uma empresa define os seus preços. A maioria dos fornecedores de autenticação cobra por coisas que quase não lhes custam nada; no nosso caso, resume-se a uma linha: pague pelo tamanho que atinge, não pelos interruptores que tem permissão para acionar.

Se é essa a fatura que preferia receber, aqui está exatamente quem cobra pelo quê. O SSO está do nosso lado da mesa, sem custo adicional.

Build vs buy auth: the bill you don't see coming

authagonal — Tue, 30 Jun 2026 23:41:56 +0000

Authentication is the feature every engineer is sure they can build in a weekend, and they are right. You can build a login form, a users table, and a password-reset email by Sunday night. The weekend is real. The weekend is also not the cost. The cost is everything that arrives after it, on a schedule you do not set, for a system you can never turn off.

The part you think the job is

Email and password. A sessions table. A "forgot password" link that emails a token. Social login if you are feeling thorough. This genuinely is a weekend, and if that were the whole job, you should absolutely build it. It is not the whole job, and you know it is not, which is why you are reading a build-versus-buy article instead of just building it.

The bill you don't see coming

You now own a security surface, permanently. Password hashing, and re-hashing every user the day you realize your bcrypt cost factor was tuned for 2019 hardware. Rate limiting and account lockout. Credential stuffing, because your login endpoint joins every breach-replay list within a month of launch. And the big one: liability. The day you store credentials you become a target, and a breach stops being an abstract risk in someone else's pricing deck. It is your incident, your disclosure email, your customers' trust, and possibly your regulator.

The protocol work lands the moment you sell to anyone serious. Enterprise SSO means SAML, and SAML means XML signature verification, which is its own genre of CVE (you really do not want to meet signature wrapping in production; more on that here). SCIM means building provisioning and deprovisioning, and deprovisioning is a security control: get it wrong and a fired employee keeps their access. MFA means enrollment, recovery codes, and the support queue when someone loses their phone. Audit logs mean retention and tamper-evidence, because the customer's SOC 2 auditor will ask, and "we log to a file somewhere" is not an answer.

The operational tail never ends. Key rotation and JWKS. Session invalidation that actually works across devices. Token revocation. And on-call, for the one system in your stack that, when it is down, takes everything with it: nobody logs in, no API call authenticates, your whole product is a 500 page. Auth is tier zero. You are signing up to keep a tier-zero security system running forever, with the same headcount you were going to spend on your actual product.

The compliance tail is annual. SOC 2, ISO 27001, a prospect's security questionnaire: each one asks, in detail, about every item above. Auditors are not charmed by "we rolled our own." Buying auth lets you point at a vendor's controls; building it makes those controls yours to document, prove, and defend, every year.

When building is actually the right call

This is not a "buy, always" pitch, because that would be dishonest and you would see straight through it. Build your own auth when:

It is a small internal tool behind a VPN, a handful of users, no compliance surface. The weekend really is the whole job.
Auth is your product. If you are building an identity company, build identity. It is your differentiator, not your overhead.
You have genuinely unusual requirements no provider fits, and a dedicated security team that will own the result for its entire life. Note both halves of that sentence. The team is the expensive half.

Outside those cases the math is simpler than it looks. The cost of "build" was never the first weekend. It is the perpetual ownership of a security-critical system that does not make your product any better, only more yours.

The honest reframe

Building auth does not make your product more valuable to a single customer. No one ever bought your software because you hand-rolled the SAML signature check. It just converts auth from someone else's problem into yours, forever, and spends the engineering you could have put into the thing people actually pay for.

The usual objection to buying, that auth vendors charge a fortune to switch on the enterprise features, is real. But that is an argument about which vendor, not about build versus buy. A lot of that bill is a feature tax you don't have to pay. Buy auth that includes SSO, SCIM, MFA, and audit logs without the per-connection tollbooth, and the build-versus-buy question mostly answers itself.

Before you spend a sprint on a login system, it is worth seeing exactly what enterprise customers will demand from it. Here's what's included, on every plan.

OIDC or SAML: which one you actually need

authagonal — Mon, 29 Jun 2026 11:56:45 +0000

Every team building B2B software hits the same fork the first time a serious customer says "we need SSO." Two acronyms, OIDC and SAML, both claiming to be the answer, and an internet full of comparison tables that tell you SAML is "enterprise" and OIDC is "modern" and leave you exactly as stuck as before. Here's the version that actually helps you ship.

What they are

SAML is from 2005 and it is XML. An identity provider signs an assertion ("this is alice@bigco.com, here are her groups") and posts it to your app, which checks the signature and logs her in. It was built for the browser and for workforce identity, in an era when "the enterprise" meant on-prem Active Directory and a SOAP stack. It is verbose, it is old, and it is absolutely everywhere inside large organizations, which is the one fact about it that matters to you.

OIDC is from 2014 and it is JSON and JWTs, sitting on top of OAuth 2.0. An identity provider issues an ID token your app validates. It was built for the modern web: SPAs, mobile apps, APIs, social login. It is cleaner, better specified for the things you actually build today, and the protocol most greenfield identity now speaks.

When each wins

The honest answer to "which should I build" is that you almost never get to choose. You build the one your customer's IT department picked, and they picked it long before they had heard of you.

A customer on Okta, Entra ID, or Google Workspace can usually do either, and OIDC is the nicer path.
A customer on an older ADFS, a legacy on-prem IdP, or a procurement checklist written in 2016 will hand you a chunk of SAML metadata and a calendar invite, and that is the end of the discussion.
Your own first-party apps, your dashboard and your mobile client, want OIDC, full stop. You would never reach for SAML to log a user into your own React app.

So the field splits cleanly: OIDC for the modern and the first-party, SAML for "because the enterprise said so." Sell to enough enterprises and you will be asked for both. Not eventually. Repeatedly.

The gotchas, which is where building it yourself gets expensive

SAML's problem is that it is a signed-XML protocol, and signed XML is one of the most reliably dangerous things in applied cryptography. The ways to get SAML signature verification wrong are many and famous:

Signature wrapping (XSW): an attacker moves the signed element and slips an unsigned, forged assertion where your parser actually reads. If you check the signature and read the assertion as two separate steps, you are probably vulnerable, and almost every first implementation does exactly that.
Canonicalization and comment injection: the 2018 class of bugs where user@company.com.evil.com canonicalizes one way for the signature check and another way for the string your code reads, so you cheerfully authenticate the wrong person. Real CVEs, multiple major libraries.
The quieter ones: signing the response but not the assertion, accepting unsigned assertions, trusting the IdP-supplied issuer without pinning it, getting the assertion validity window wrong. Each is its own footgun, and each has been shipped to production by people who knew what they were doing.

OIDC is meaningfully saner, but it is not free of sharp edges. You still have to validate the right claims (iss, aud, exp, the nonce), use PKCE, refuse the long-dead implicit flow, and rotate and cache JWKS without rejecting a token signed by a key you have not fetched yet. The difference is that OIDC's traps are documented, JSON-shaped, and handled correctly by default in most libraries. SAML's traps are XML-shaped and have eaten security teams far better resourced than yours.

The real answer

"OIDC or SAML" is the wrong question, because the right answer for a B2B product is "yes." Your modern customers and your own apps want OIDC. Your enterprise customers will mandate SAML on a timeline you do not control. Build for one, and the third sales call breaks it.

What you actually need is a way to accept whichever protocol each customer brings, without standing up two stacks, two sets of metadata plumbing, and two independent chances to get signature verification wrong. The implementation is the cost. The choosing was never the hard part.

That is the part Authagonal takes off your plate. Every tenant gets SAML 2.0 with one-click metadata import and OIDC federation with the providers your customers already run, on the same login, with no per-connection fee for either. You do not implement XML signature verification, you do not babysit a JWKS cache, and you do not rebuild any of it when the next customer shows up speaking the other protocol. See what's included.

One hyphen, two tenants, one signing key

authagonal — Fri, 26 Jun 2026 13:00:00 +0000

Two of our tenants were the same tenant. They had different names, different signups, and different billing rows. They also shared a database and a token-signing key, and none of the three of us, the two tenants or us, had any idea. This is the story of the one-line function that merged them, why every layer of the system looked perfectly correct while it happened, and why a pre-launch audit is the cheapest insurance you will ever buy.

Multi-tenant auth has exactly one job it cannot get wrong: keep tenants apart. Acme's users, Acme's sessions, and above all Acme's signing key must never be reachable by anyone else. The signing key is the crown jewel. Whoever can sign with Acme's key can mint a token that Acme's own auth server will accept as genuine, for any user, with any role, no password required. So every per-tenant resource we create, every storage table and every key, is namespaced by the tenant's slug. Get that namespacing right and tenants are islands. Get it subtly wrong and they quietly become the same place.

The one-line bug

Here is the function that turns a tenant slug into the prefix we name its storage and keys with. Read the doc comment. It documents the bug as if it were a feature.

/// Derive the table name prefix from a tenant slug by stripping hyphens.
/// E.g. "acme-corp" → "acmecorp".
public static string GetTablePrefix(string tenantSlug)
{
    return tenantSlug.Replace("-", "");
}

Replace("-", ""). It strips hyphens. The intent was housekeeping: slugs flow into Azure Table names and Vault key names, which have their own character rules, so we sanitized them. The trouble is that stripping characters is a lossy transform, and a lossy transform on an identifier is not injective. acme-corp and acmecorp both come out as acmecorp. So do ac-me-corp and acme--corp. Distinct slugs, one namespace.

That namespace is everything downstream. The user table is {prefix}-Users. And the per-tenant signing key is, verbatim, this:

private string GetKeyName() => $"signing-{ShardRouter.GetTablePrefix(_tenantContext.Slug)}";

So acme-corp and acmecorp do not merely share a user list. They sign their tokens with the same signing-acmecorp key in Vault. A token minted for one is, byte for byte, a validly signed token for the other. If you can register a slug that collapses to the same prefix as an existing tenant, you can issue yourself tokens their auth server trusts completely. Cross-tenant account takeover, and the exploit is "sign up with a hyphen."

Why nothing caught it

The unsettling part is how ordinary every layer looked. Signup validated the slug and saw a fresh, unused string. Provisioning created a tenant record keyed by the full slug, acme-corp, which is genuinely distinct from acmecorp in the control plane. Token validation derived the key from the slug and verified happily. Every component did its job correctly on its own input.

Nothing in the system ever compared two slugs' prefixes, because no single component owned the invariant "a slug maps to exactly one namespace." The collision lived in the gap between a slug, which the control plane keys on, and a prefix, which storage and Vault key on. Nobody was standing in that gap. This is the signature of the most dangerous class of bug: not a check anyone forgot, but an assumption nobody knew they were making.

The second collision, for free

The same lossy transform had a second victim. Our internal system tenants are named by suffix: {slug}-admin holds a tenant's portal team, {slug}-sandbox holds its test environment. Run those through the same de-hyphenator and acme-admin becomes acmeadmin. Which means a customer who registered the slug acmeadmin would collapse onto the prefix of Acme's admin tenant, the one place that is supposed to be more privileged than the customer, not shared with one.

One stripping function, two different isolation boundaries at risk: tenant to tenant, and tenant to its own control plane. When a single line threatens two unrelated boundaries, that is the tell of a root-cause bug rather than a surface one. The fix has to land on the transform, not on either symptom.

The fix: injective by construction

The instinct is to make the prefix function smarter. Escape the hyphens, hash the slug, base32-encode it. Every one of those is still a transform you have to prove injective forever, against every future change, by someone who may not know why it matters. The cheaper and far more durable fix is to remove the transform's freedom entirely: constrain the input so the transform is the identity.

// Lowercase alphanumeric ONLY, no hyphens. Forbidding hyphens makes prefix == slug,
// so distinct slugs can never share a data store or signing key.
if (!slug.All(c => (c >= 'a' && c <= 'z') || (c >= '0' && c <= '9')))
    return false;

Slugs are now lowercase letters and digits, nothing else. With no hyphens to strip, GetTablePrefix has nothing to do, prefix == slug holds by construction, and two distinct slugs can never share a namespace again. We also reject the reserved names and any slug ending in admin or sandbox, which closes the system-tenant collision in the same line. The validity check is the narrow point where a slug first becomes a namespace, so that is exactly where the one-to-one guarantee belongs.

We then re-assert the same rule one more time, at the provisioning chokepoint. There are two doors a slug can enter through, self-service signup and admin-driven provisioning, and a security invariant defended at only one of two doors is defended at neither.

Why we are telling you

We found this in a pre-launch security audit of our own product, before a single paying customer existed, which is the only acceptable time to find it. No tenant was ever merged in production. But it is a humbling bug, because it is not a missing check or a weak algorithm. It is a helper that does something entirely reasonable, sanitize a string, in a place where "reasonable" and "injective" turn out to be different words.

The lesson outlived the fix. Any function that turns user-controlled input into the name of a security boundary, a table, a key, a namespace, a path, must be injective, and you should enforce that at the narrowest point where the mapping is created, not hope it survives every layer downstream. A normalize step, lowercase, trim, strip, collapse, is precisely where two identities quietly become one.

It is the same principle the whole product is built on. Security is not a tier you graduate into; it is the floor. Every isolation guarantee, every signing key, and every security feature we ship, SSO and SAML, SCIM, MFA, audit export, is on at every plan, because the alternative is the kind of thing you find at 2am instead of in an audit. See what's included.

Support that speaks your language. Without making you ask.

authagonal — Fri, 26 Jun 2026 09:02:43 +0000

Most support tooling forces a choice. Either it's a clean little widget that can't do anything, or it's a powerful platform that looks like it was designed in 2011 and never recovered. Pick your poison.

We didn't want the poison.

So the Authagonal support system is the boring-sounding thing that's quietly hard to pull off: simple, good-looking, and actually capable. Here's the part we're a little smug about.

Messages land in real time.

No refresh button. No "checking for new replies" spinner that quietly lies to you. A message is sent and it's just there, live in the UI. The conversation moves at the speed of an actual conversation, which is the whole point of a conversation.

It translates both ways, and it shows its work.

A customer writes in Arabic. We read it in English. We reply in English. They read it in Arabic. Nobody installs anything, nobody picks a language, nobody pastes a thread into Google Translate and prays.

The bit we care about: it's transparent. The translation isn't hidden behind the curtain, pretending a human polyglot is on shift. The user can see the AI translation happening, and they can see the original. Transparency isn't the downgrade here. It's the reason people trust it.

What you see.

What we see — the same thread, the same moment.

It pins the language from message one.

No dropdown. No "select your preferred language." No little flag icons. The first message a customer sends sets their language, and it stays pinned for the whole conversation. They write how they write, and everything after just works.

(If you've ever watched a support tool ask a confused, frustrated user to go hunt for a language selector before they can even ask for help, you know exactly why we skipped that.)

It survives email.

This is where most systems quietly give up. The moment a conversation moves to email, every clever feature evaporates: plain text, original language, good luck.

Ours doesn't. Email is fully two-way, and the translation rides along with it. A reply that lands in someone's inbox is still translated, both directions, exactly like the in-app thread. Real-time in the app, intact over email. The channel changes. The experience doesn't.

That's it. That's the brag.

Simplicity meets functionality, in a package that doesn't make your eyes hurt. Live messaging, no refresh. Two-way automatic translation you can actually see happening. Language pinned from the first word. Email that keeps every bit of it intact.

We built the support system we wanted to use. Now it's the one you get when you need us.

Green unit tests don't mean you can go live

authagonal — Thu, 25 Jun 2026 01:51:49 +0000

We sell authentication, which makes our scariest question a simple one: when a customer wires their app to us and switches everything on, does it actually work, end to end, on the real thing? Not "do the unit tests pass," but does a brand-new tenant sign up, configure SSO and SCIM and MFA and custom claims and branding, point a real application at it, and log a real user in with the right claims in the token, through a real browser. We answer that the only way we trust: with one end-to-end test that becomes a customer.

It's a single Playwright run, deliberately serial and stateful, and it walks the whole life of a tenant from birth to deletion. One tenant signs up, gets configured to the teeth, serves a real login to a real consumer app, gets backed up and restored, then deletes itself. If any link in that chain breaks, the run goes red, and we don't ship.

It configures everything, not a happy-path slice

The middle of the test is thorough on purpose. It doesn't log in and call it a day; it walks every screen a real implementer touches and exercises it for real: a custom OIDC client with its redirect URIs and token settings, a custom scope that emits user claims, roles and a role assignment, an end user with a custom attribute, a group with real membership and a group-to-role mapping, SAML and OIDC enterprise connections, a SCIM provisioning token, a custom domain, an outbound provisioning app, a teammate invited and re-roled, billing through a real checkout, the audit log with filters and a CSV export, a sandbox environment, and the security, webhook, and email settings (each flipped, then reverted to a safe state). Every one of those is created, verified, and where it makes sense deleted, in the same run.

The point isn't to tick boxes. A customer never uses one feature in isolation; they use a combination, and combinations are where things quietly break. A custom claim only matters if it shows up in the issued token. A group-to-role mapping only matters if the role lands at the exact moment the token is minted. The only way to know is to build the whole thing and then go use it.

The credential dance

Here is the part that makes an end-to-end test of an auth product genuinely awkward: the credentials don't exist when the test starts. You can't hardcode a client secret or a SCIM token, because the entire point is that the tenant mints them, fresh, during the run.

So the test does exactly what a real implementer does, only faster. It creates the OIDC client in the portal and reads back the client id and secret. It mints a Portal API credential in one click and captures it. It generates a SCIM token. Then it feeds each of those freshly-minted secrets into the sample consumer application standing by, rewrites that app's configuration with the new values, rolls it out, and only then drives the actual login. Credentials born in one step get injected into the app under test in the next, and the browser completes a real OIDC redirect against them. The integration is a moving target the test keeps re-aiming at itself as it takes shape.

That consumer is a real deployment, not a mock. When the test verifies a login, a real application really redirected to the tenant's issuer, really got a code back, really exchanged it, and the test decodes the resulting token to confirm the custom claim and the mapped role are genuinely in it. Then it drives the harder edges: a custom-branded login page behind its enable gate, and an enforced webhook that has to block a login the policy denies. A green test on that last one means the deny path works, which is the result you most want to be certain of.

Multi-factor, for real

A password login proves little on its own. The run enrolls and then uses a TOTP authenticator and a WebAuthn credential through a virtual authenticator, so the second factor is exercised the way a real user's is, not stubbed out.

The half everyone skips: getting it back

Most end-to-end tests stop at "it works." Ours keeps going into the parts you only think about at 2am. It takes a backup, deletes the tenant's data out from under itself, restores from that backup, and verifies the configuration and users came back intact. Then it runs a clean self-service delete of the whole tenant. A run leaves nothing behind, which is also how we know that deprovisioning actually deprovisions.

Why this is the test we trust

A wall of green unit tests tells you your functions are correct. This tells you a customer can walk in, build the integration they actually want, with the security features they actually need, and that we can lose their data and hand it back. That is the difference between "the code is correct" and "we can go live."

Every feature this run exercises (SSO and SAML, SCIM, MFA, custom claims and scopes, branding, enforced webhooks, audit export) is in the product at every tier, not gated behind an enterprise upsell. See what's included.

Importing users without a password reset

authagonal — Wed, 24 Jun 2026 00:25:36 +0000

Every identity migration guide eventually reaches the same paragraph, and it's always a little apologetic: "users will need to reset their passwords." It gets treated like a law of nature. It isn't. It's a choice, usually forced by a tool that didn't want to do the harder thing.

The harder thing is verifying your users' existing password hashes in place, so they sign in after the move with exactly the credentials they had before and never notice anything happened. Whether you can do it comes down to one question: can you get the old hashes, and can the new system verify them?

Password hashes are more portable than people think

A password hash isn't a secret algorithm. bcrypt is bcrypt. A bcrypt hash carries its own cost factor and salt inside the string, so anything that implements bcrypt can verify a hash any other bcrypt system produced. The same is true of the PBKDF2 format ASP.NET Identity uses: documented, versioned, self-describing. If you know what you're holding, you can check a password against it without ever knowing the password.

So a migration that preserves logins doesn't need the plaintext (nobody has it) and doesn't need to re-hash everyone up front. It needs to obtain the stored hashes and verify against them on sign-in, upgrading each one to its own format quietly the first time a user logs in. That last part is lazy migration: carry the old hash, verify it once, replace it transparently. Over a few weeks of normal logins your user table re-hashes itself and the legacy formats age out, with zero resets and zero support tickets.

The dual-path bit

The wrinkle is that different sources hand you different formats, and a good importer verifies both:

From self-hosted Duende / ASP.NET Identity: the V3 PBKDF2 hashes (and any legacy bcrypt) verify natively and rehash on first sign-in. This is the easy case, because it's the same scheme the destination already uses. Most teams are surprised it's that clean.
From Auth0: bcrypt hashes verify verbatim. The catch isn't the format, it's getting them.

When you genuinely can't

Auth0's Management API never returns password hashes. That's a deliberate policy, not a gap in anyone's tooling, and you should be suspicious of any "one-click Auth0 export" that claims to include passwords without it. The supported path is a support-assisted bulk export: an NDJSON file with each user's bcrypt hash. Get that file and the hashes import verbatim, lazy migration and all, and the move is invisible.

If you can't wait on it, the fallback is the honest version of the apologetic paragraph: users set a new password on first sign-in. Nothing was lost, because there was no hash to carry. The difference is you chose it knowingly, rather than because the tool couldn't do better.

Why this matters more than it sounds

A forced reset is the single most visible, most alarming thing you can do to a user base mid-migration. It generates support load, it trains users to expect a phishing-shaped "click here to reset" email, and it's the moment a quiet infrastructure change becomes everyone's problem. Avoiding it is most of what makes a migration feel like nothing happened, which is how a migration should feel.

So before you accept "everyone resets," ask the two questions. For most moves the answer is yes on both, and the apologetic paragraph was never necessary.

See what an import would carry across — the preview is read-only and shows you everything before anything is written.