DEV Community: authagonal

Ejecutamos todo un sistema de autenticación sobre almacenes que solo saben hacer get y put

authagonal — Fri, 10 Jul 2026 11:36:51 +0000

Un sistema de autenticación parece pedir a gritos una base de datos relacional. Usuarios, roles, sesiones, concesiones OAuth, refresh tokens, todo referenciado entre sí. El nuestro no usa ninguna. Corre sobre Azure Table Storage, un almacén que te da una partition key, una row key y casi nada más. Sin joins, sin secondary indexes que sirvan de algo, sin operador de incremento, sin transacciones multifila con la forma a la que estás acostumbrado. Fue una decisión. Esto es lo que compra esa decisión, los patrones que la hacen funcionar y la parte en la que SQL habría sido realmente más fácil.

La razón para hacerlo es el coste y la simplicidad operativa. Sin connection pool que agotar, sin instancia de base de datos que dimensionar, parchear o conmutar por error, con escalado por partición que obtienes gratis. Mantener una tabla no cuesta casi nada y no hay nada que se pueda agotar. El precio de eso es un almacén sin query planner, que solo rinde cuando tus patrones de acceso son tan predecibles como tonto es el almacén. Los de la autenticación lo son, así que todo el diseño se apoya en ello.

La clave hace el trabajo que haría un diseño de tabla. Sin joins, diseñas la clave para que la consulta sea la clave. Desnormalizas a propósito, eliges las particiones para que tus lecturas calientes sean point-gets, y codificas identidades compuestas directamente en la row key, por ejemplo "{pk}|{rk}" para entradas que necesitan una identidad compuesta en un almacén que ofrece un solo hueco de row key. La pregunta "cómo busco esto" hay que responderla al diseñar la clave, no en tiempo de consulta. Para la autenticación eso está bien, porque los patrones de acceso son conocidos y no cambian con el tiempo: obtener un usuario por id, obtener las concesiones de un usuario, consumir un código. No estás explorando los datos. Conoces cada pregunta de antemano.

Llevas tu propio change log. Cada fila lleva un Timestamp gestionado por el servidor, y es tentador construir el backup incremental sobre él: traer todo donde Timestamp gt watermark. Eso funciona en una demo y muere en producción, porque el almacén indexa la partition key y la row key y nada más. Timestamp no está en ningún índice, así que filtrar por él inspecciona cada fila de la tabla. Es un full scan disfrazado de consulta, y se vuelve más lento cada día que la tabla crece. Así que, en su lugar, el almacén escribe su propio change log. Cada mutación, cada upsert y cada borrado, agrega una fila a una tabla de change log indexada por el nombre lógico de la tabla, con el compuesto "{pk}|{rk}" como row key y un flag que indica si la fila se escribió o se borró. Ahora "qué cambió desde el watermark" es la lectura de una única partición pequeña e indexada en lugar de un escaneo de toda la tabla, y el backup hace point-read solo de las filas que de verdad se movieron. Reconstruyes change-data-capture a partir de escrituras ordinarias, y escala con el ritmo de cambios en lugar de con el tamaño de la tabla.

Concurrencia sin transacciones. Aquí no hay SELECT ... FOR UPDATE. Lo que obtienes en su lugar es una única primitiva atómica: la escritura condicional, que se te entrega como un ETag. Escribes una fila solo si la copia que leíste no ha cambiado por debajo de ti. Todo lo que necesita seguridad bajo acceso concurrente se expresa como optimistic concurrency más reintento en caso de conflicto. El ejemplo más claro es el contador de bloqueo de cuenta. AccessFailedCount necesita incrementarse de forma atómica, pero el almacén no tiene incremento. Así que lees la fila, subes el contador, la vuelves a escribir condicionada al ETag que leíste, y reintentas si alguien se te adelantó. Ese bucle es cómo haces atómico un contador en un almacén que no tiene contador. Lanza cincuenta contraseñas erróneas a la vez y cada una de ellas surte efecto, porque el conflicto se detecta y se reintenta en lugar de perderse.

Un borrado puede ser un bloqueo. El consumo de un solo uso, un código de autorización o un token de un solo uso que debe canjearse exactamente una vez, es un borrado condicional. Es un borrado condicional por ETag: si el borrado tiene éxito, ganaste la carrera y puedes continuar; si falla porque la fila ya no estaba, alguien lo consumió antes y te detienes. El borrado es el bloqueo. La misma idea sirve para la leader election, construida sobre un blob lease, un bloqueo hecho de una escritura atómica en lugar de un servicio de coordinación aparte. Casi nunca necesitas un servicio de bloqueos cuando la propia escritura es atómica.

Los borrados tienen que ser de primera clase, que es la mitad de la razón por la que existe el change log. Un almacén clave-valor no tiene marcador de borrado: una fila borrada simplemente desaparece, así que cualquier cosa que escaneara en busca de cambios ni siquiera podría ver que se fue. Un backup que se basara en los timestamps de las filas arrastraría en silencio al usuario borrado para siempre. El change log registra el borrado como un borrado, de modo que una restauración lo reproduce en lugar de resucitarlo. Ese modo de fallo, un backup que trae de vuelta fielmente a todos los que eliminaste, es toda una historia en sí misma y merece su propia entrada, pero el patrón pertenece a esta lista: en un almacén sin registro de borrados, el registro de borrados lo llevas tú.

Ahora el otro lado del balance, aquello a lo que renuncias. Renuncias a las consultas ad-hoc: un patrón de acceso genuinamente nuevo puede significar un nuevo diseño de clave o un full scan, porque no hay query planner que te salve. Renuncias a los joins, así que mantienes copias desnormalizadas a mano y te haces cargo de su consistencia. Renuncias a las transacciones multifila, así que diseñas cada invariante para que viva dentro de un único ítem, porque la atomicidad de un solo ítem es todo lo que se te da. Si tus datos son profundamente relacionales, o tus patrones de acceso son desconocidos y todavía cambiantes, esta es la herramienta equivocada y te va a doler.

Que es exactamente por lo que le viene bien a la autenticación. Una base de datos relacional se gana el sueldo respondiendo preguntas que aún no se te han ocurrido. Un sistema de autenticación no tiene esas preguntas. El conjunto de cosas que preguntas, obtener este usuario, consumir este código, elegir este líder, respaldar lo que cambió, es pequeño, conocido y estable. Renuncia al query planner que nunca ibas a usar y, a cambio, obtienes una capa de almacenamiento que no cuesta casi nada operar y que no tiene nada que conmutar por error. Para la mayoría del software es un mal trato. Para esto, es el correcto.

Estos patrones son el motor de almacenamiento que hay debajo de Authagonal: un diseño clave-valor que no cuesta casi nada operar, que es una gran parte de cómo ponemos cada funcionalidad en cada plan.

We run a whole auth system on stores that only know get and put

authagonal — Fri, 10 Jul 2026 11:30:36 +0000

An auth system looks like it wants a relational database. Users, roles, sessions, OAuth grants, refresh tokens, all cross-referenced. Ours does not use one. It runs on Azure Table Storage, a store that gives you a partition key, a row key, and almost nothing else. No joins, no meaningful secondary indexes, no increment operator, no multi-row transactions in the shape you are used to. That was a choice. Here is what the choice buys, the patterns that make it work, and the part where SQL would genuinely have been easier.

The reason to do this is cost and operational simplicity. No connection pool to exhaust, no database instance to size or patch or fail over, per-partition scaling you get for free. A table costs almost nothing to keep and there is nothing to run out of. The price of that is a store with no query planner, which only pays off when your access patterns are as predictable as the store is dumb. Auth's are, so the whole design leans into it.

The key does the work a table layout would. With no joins, you design the key so the query is the key. You denormalize on purpose, you pick partitions so your hot reads are point-gets, and you encode composite identities directly into the row key, for example "{pk}|{rk}" for entries that need a compound identity in a store that offers only one row-key slot. The question "how do I look this up" has to be answered when you design the key, not at query time. For auth that is fine, because the access patterns are known and they do not drift: get a user by id, get a user's grants, consume a code. You are not exploring the data. You know every question in advance.

You keep your own change log. Every row carries a server-managed Timestamp, and it is tempting to build incremental backup on it: pull everything where Timestamp gt watermark. That works in a demo and dies in production, because the store indexes the partition key and the row key and nothing else. Timestamp is not in any index, so filtering on it inspects every row in the table. It is a full scan wearing the costume of a query, and it gets slower every single day the table grows. So the store writes its own change log instead. Every mutation, every upsert and every delete, appends a row to a change-log table keyed by the logical table name, with the composite "{pk}|{rk}" as the row key and a flag for whether the row was written or deleted. Now "what changed since the watermark" is a read of one small, indexed partition instead of a scan of the whole table, and the backup point-reads only the rows that actually moved. You rebuild change-data-capture out of ordinary writes, and it scales with the churn instead of with the size of the table.

Concurrency without transactions. There is no SELECT ... FOR UPDATE here. What you get instead is one atomic primitive: the conditional write, handed to you as an ETag. You write a row only if the copy you read has not changed underneath you. Everything that needs safety under concurrent access is expressed as optimistic concurrency plus retry on conflict. The clearest example is the account-lockout counter. AccessFailedCount needs to increment atomically, but the store has no increment. So you read the row, bump the count, write it back conditional on the ETag you read, and retry if someone beat you to it. That loop is how you make a counter atomic on a store that has no counter. Fire fifty bad passwords at once and every one of them lands, because the conflict is detected and retried rather than lost.

A delete can be a lock. Single-use consumption, an authorization code or a one-time token that must be redeemed exactly once, is a conditional delete. It is an ETag conditional-delete: if the delete succeeds you won the race and may proceed; if it fails because the row was already gone, someone else consumed it first and you stop. The delete is the lock. The same idea does leader election, built on a blob lease, a lock made out of an atomic write rather than a separate coordination service. You almost never need a lock service when the write itself is atomic.

Deletes have to be first-class, which is half of why the change log exists. A key-value store has no delete marker: a deleted row simply vanishes, so anything that scanned for changes could never even see that it left. A backup that keyed off row timestamps would quietly carry the deleted user forward forever. The change log records the delete as a delete, so a restore replays it instead of resurrecting it. That failure mode, a backup that faithfully brings back everyone you removed, is a whole story on its own and deserves its own post, but the pattern belongs on this list: in a store with no delete log, you keep the delete log yourself.

Now the other side of the ledger, what you give up. You give up ad-hoc queries: a genuinely new access pattern can mean a new key design or a full scan, because there is no query planner to save you. You give up joins, so you maintain denormalized copies by hand and own the consistency of that. You give up multi-row transactions, so you design every invariant to live inside a single item, because single-item atomicity is all you are given. If your data is deeply relational, or your access patterns are unknown and still moving, this is the wrong tool and it will hurt.

Which is exactly why it fits auth. A relational database earns its keep by answering questions you have not thought of yet. An auth system does not have those questions. The set of things you ask, get this user, consume this code, elect this leader, back up what changed, is small, known, and stable. Give up the query planner you were never going to use, and in return you get a storage layer that costs almost nothing to operate and has nothing to fail over. For most software that is a bad trade. For this, it is the right one.

These patterns are the storage engine under Authagonal: a key-value design that costs almost nothing to operate, which is a big part of how we put every feature on every plan.

Your password-reset form is a free email cannon

authagonal — Thu, 09 Jul 2026 06:26:43 +0000

The password-reset form is probably the least interesting endpoint you own. It is also the only one an attacker can point at anyone. Ours had no per-email rate limit for a while, and the reason that matters is not the reason you would guess.

The reflex, when you hear "unauthenticated endpoint, no rate limit," is to think about brute force. But there is nothing to brute force on a reset request. You are not guessing a password. You submit an email address and the system sends a link. Hammering it does not get you into an account. So who gets hurt?

The victim is a third party. Type someone else's address, victim@example.com, hit send, repeat. Every request sends a real email to a real inbox you do not control. You have conscripted our reset form into a mailbomb aimed at somebody who never signed up for anything. And because the mail comes from us, the damage lands in two places at once. The victim's inbox fills up. And our sending reputation takes the hit, because a flood of unwanted mail from our domain is exactly what mailbox providers watch for. Enough of it and our legitimate mail, verification links, actual password resets, starts landing in spam for every real customer we have. An unauthenticated endpoint, with no credentials and no cost to the attacker, degrades a resource all of our users share.

So you rate-limit it. Per email address, so one target cannot be flooded. Easy. Except the obvious implementation quietly opens a different hole.

If you only apply the limit, or only do the work, when the address actually has an account, then the endpoint behaves differently for real accounts than for made-up ones. An attacker who can see that difference, in the response, the status code, or just the timing, now has an oracle for which email addresses are registered with you. Reset forms are a classic account-enumeration leak for exactly this reason: the naive fix for the mailbomb creates the enumeration bug.

The real fix has to do both things at once, and the two halves are separate. First, rate-limit on the normalized email address regardless of whether an account exists. The limit key is the address itself, lowercased and trimmed so Victim@ and victim@ share one bucket, and the counter is applied before you have looked anything up. That counter has to live in a durable, shared store, not in a single process's memory, or it evaporates on a restart and does nothing across multiple instances. Second, respond identically in every case: the same status, the same "if that address has an account, we have sent a link" message, the same timing shape, whether or not the address is one of yours. You still only actually send mail when there is an account behind it. But nothing an outsider can observe changes based on that secret. The rate limit protects the third party; the constant response protects the fact of who has an account.

The general lesson reaches past password resets. Any unauthenticated endpoint that causes a real-world side effect, sending an email, sending an SMS, calling a webhook, is not merely part of your attack surface. It is a weapon aimed at whoever is on the receiving end, and the bill for firing it lands on your reputation, not the attacker's. Rate-limit by the thing being acted on, which is the recipient, not the caller. And do it without letting the presence or absence of secret state change what an observer sees.

The password-reset form feels like plumbing. It is the one piece of plumbing that will happily spray anyone in the world on command. Meter it accordingly.

Metering an unauthenticated side-effect endpoint without leaking who has an account is fiddlier than it looks. Authagonal ships the reset flow already rate-limited and enumeration-safe, so your sender reputation is never one curl loop away from ruin.

We gave away every feature on the free tier, including the ones rivals reserve for enterprise

authagonal — Tue, 07 Jul 2026 23:15:54 +0000

Our free plan costs nothing, caps out at 250 monthly active users, and ships single sign-on, SAML, SCIM provisioning, multi-factor authentication, role-based access control, audit logs, and your own branding on your own domain. That feature list is deliberate. It is roughly the same list our competitors file under "Enterprise," or hide behind a "Contact sales" button, or bill per connection at a hundred-plus dollars a month.

The usual assumption is that this is a loss leader. A bait. Give away the good stuff, get your auth wired into someone's product, then squeeze once they are stuck. It is not that. Giving away every feature is the honest position, and it holds up against a spreadsheet. Here is the math, because the math is the entire argument.

Start with what a feature actually costs to provide. We made this case in the feature tax: SSO, MFA, SCIM and the rest are code written once that now runs for everyone on the platform. The bytes are the same bytes whether someone signs in with a password or a corporate identity provider. When a free tenant switches SAML on, our costs do not move. There is no per-feature meter spinning in a datacenter. The marginal cost of one more tenant using one more feature rounds to zero.

So if features are free to hand out, what is not? Two things, and only two.

Active users cost money. More monthly active users means more sessions, more tokens signed, more storage, more egress. That tracks real resource use, and we can measure it. Which is why the free tier has a hard number on it: 250 MAU. Not 250-features-minus-the-expensive-ones. 250 people. Cross that line and you move to a paid plan, because at that point you genuinely cost something to serve.

Support costs money. A human answering a gnarly integration question at 2am is a real, recurring expense. So is the AI that powers our multilingual support desk, which bills us for every message it translates. The free tier is community-only: docs, forums, a thread on GitHub. No support desk, no AI assist. That is the other thing we hold back, because it is the other thing with a bill attached.

Notice the shape of that. We gave away everything with a fixed cost and metered the two things with a variable cost. That is the whole model. The wall was never features. The wall is active users and support. A hobby project, an internal tool, a small business with 200 users can run production single sign-on, SCIM deprovisioning, MFA and a real audit trail, for free, indefinitely, and it costs us almost nothing to let them.

Now look at where the rest of the industry puts its wall. In front of the features. SSO lives three tiers up. MFA is an upgrade. Audit-log retention is sliced by plan. That gate is not recovering a cost, because there is no cost to recover. It is there because your security and compliance features are the ones you can least afford to refuse, which makes them the ones with the most leverage to charge for. A tollbooth on a road that was already built and paid for.

We would rather not run that experiment on the people using us. The ugly part of feature-gating is that it charges hardest for the responsible thing. You need SSO because your biggest prospect's procurement team insists. You need MFA because your own auditor does. Fencing those behind "Enterprise" is a tax on doing security properly, collected at the precise moment you have the least room to say no. Putting them on the free tier is that same principle from the feature tax followed all the way down: if it costs us nothing to provide, you should not pay for the privilege of turning it on.

The one real consequence is that a free tenant makes us no money, and that is fine. We make money the boring way, when people grow. A team that starts at 40 users on the free plan with full SSO is a team that, at 4,000 users, pays for scale. Not for switches they were always allowed to flip. By then they have had audit logs and SCIM running in production for a year, which is a far better reason to stay than a feature we finally deign to enable for a fee.

So yes: every feature, on the free tier, including the ones our competitors reserve for enterprise. Not out of generosity. Because features were never the thing that cost money, and pretending they were is exactly the tax we exist to undercut.

If you want to see where the line actually sits, here is the pricing. The free tier is the one up top that says $0 and still ships SAML.

O imposto de SSO, em dólares: quanto SAML custa de verdade na Auth0, WorkOS e Clerk

authagonal — Mon, 06 Jul 2026 22:59:53 +0000

Escrevemos uma vez sobre o imposto de funcionalidade: o truque de cobrar de você para acionar um booleano que já está escrito, sobre uma infraestrutura que já está rodando. Aquele texto era o argumento. Este é o recibo.

Porque "SSO custa a mais" é fácil de concordar com um aceno de cabeça e fácil de esquecer. Um número numa fatura é mais difícil de esquecer. Então vamos colocar a fatura inteira sobre a mesa, para três momentos pelos quais todo produto B2B passa: a base da plataforma (cobrada por usuários ativos mensais, o que todos cobram e que é justo: mais usuários custam de fato mais para atender), além das duas linhas que realmente medem SAML, a conexão SSO e o provisionamento SCIM que vem junto. Três colunas ao vivo, um total geral. Incluímos a base de propósito. O imposto de SSO não é o único lugar onde o dinheiro vaza; só a diferença no próprio preço da plataforma chega a milhares por ano, e omiti-la subestimaria o que o modelo de imposto de funcionalidade realmente custa a você. Todas as tarifas são os preços publicados por cada fornecedor em junho de 2026.

SSO nem é o único medidor, só o mais barulhento. Há um mais silencioso: o limite de clientes OAuth, os apps e serviços que você registra do seu lado. Ele nunca morde durante a avaliação; morde no meio da integração, na tarde em que você vai conectar mais uma ferramenta e descobre que acabou a cota, restando ou reutilizar um cliente que não deveria (sua mesa de suporte emitindo tokens para sua API principal não é uma frase que você queira ler para um auditor de SOC 2) ou pular de plano para adicionar uma única linha a uma tabela. Um cliente é uma linha e um segredo; não custa nada ao fornecedor, então não o medimos. Mas SSO é o imposto que vira manchete, então é ele que as tabelas abaixo precificam.

Cenário 1: seu primeiro contrato enterprise

~1.000 MAU. Seu primeiro logo de verdade acabou de assinar, com a condição de fazer login pelo próprio provedor de identidade, com os usuários provisionados automaticamente. Uma conexão SAML, com SCIM:

Fornecedor	Plano /mês	SSO /mês	SCIM /mês	Total /mês	Total /ano
Authagonal	$29	$0	$0	$29	$319
Clerk	$25	$0 (a primeira grátis)	$0	$25	$300
WorkOS	$0	$125	$125	$250	$3.000
Auth0	$0	incl.	incl.	$0	$0

Nesse tamanho, três dos quatro ficam perto de zero. A primeira conexão da Clerk é grátis (seu plano é $25). O nível Free da Auth0 agora inclui uma conexão enterprise, SSO autosserviço e SCIM por $0, até 25.000 MAU. Genuinamente grátis, e mérito por isso (a pegadinha vem mais abaixo). Nós, $29, tudo incluído. Só a WorkOS quebra a fila: já $3.000/ano, tudo isso o imposto de SSO-e-SCIM por conexão. Até aqui o imposto está em grande parte escondido: adicione um segundo cliente enterprise e veja-o vir à tona.

Cenário 2: um punhado de clientes enterprise

~10.000 MAU, o SSO agora faz parte do processo de vendas. Três conexões SAML, com SCIM:

Fornecedor	Plano /mês	SSO /mês	SCIM /mês	Total /mês	Total /ano
Authagonal	$149	$0	$0	$149	$1.639
Clerk	$25	$150 (1 grátis + 2×$75)	$0	$175	$2.100
WorkOS	$0	$375	$375	$750	$9.000
Auth0	orçamento	orçamento	orçamento	orçamento	orçamento

Agora somos a linha mais barata da tabela, não por cortar funcionalidades, mas porque a base é tudo o que você paga. Cada uma dessas três conexões é um cliente que paga, então o medidor por conexão acelera exatamente quando o SSO começa a fazer o seu trabalho. A linha SCIM separada da WorkOS já o dobrou para $9.000/ano; a nossa ainda é $1.639, SAML e SCIM incluídos.

Cenário 3: SSO agora é requisito básico

~50.000 MAU. Dez clientes enterprise, dez conexões SAML, com SCIM. Ninguém mais avalia você sem isso:

Fornecedor	Plano /mês	SSO /mês	SCIM /mês	Total /mês	Total /ano
Authagonal	$339	$0	$0	$339	$3.729
Clerk	$25	$675 (1 grátis + 9×$75)	$0	$700	$8.400
WorkOS	$0	$1.250	$1.250	$2.500	$30.000
Auth0	orçamento	orçamento	orçamento	orçamento	orçamento

Leia a linha de cima frente à de baixo. A fatura anual inteira da Authagonal (plataforma, SAML ilimitado, SCIM, MFA, auditoria, marca, tudo) é de $3.729. O imposto de SSO-e-SCIM da WorkOS sozinho é de $30.000: mais de oito vezes a nossa fatura inteira, antes de a WorkOS ter cobrado um único centavo pela plataforma em si, e nem precisa, porque o imposto é a plataforma. Essa diferença de ~$26.000 por ano é exatamente o que ficava sem menção quando mostrávamos só a linha do SSO. Os bytes são idênticos a um login por senha; o código foi escrito uma vez e entregue a todos. Você estaria pagando, todo ano, por vinte caixas de seleção e uma plataforma que poderia ter tido por cerca de um oitavo do preço.

Sobre os números. Plano é o preço da plataforma escalonado por MAU: a única coisa pela qual nós, e a maioria dos fornecedores, cobramos legitimamente mais à medida que você cresce. A WorkOS inclui gestão de usuários grátis até 1M de MAU, então toda a fatura dela é o imposto por conexão. O Clerk Pro é $25/mês com os MAU em grande parte incluídos nesses volumes (possível um excedente modesto a 50k); a primeira conexão SSO é grátis, depois cerca de $75 cada, e o SCIM vem grátis com uma conexão. A Auth0 mudou o modelo recentemente o bastante para merecer o próprio parágrafo, logo abaixo. Os valores anuais da Authagonal são o que de fato é cobrado: 11× o preço mensal, porque os planos anuais ganham um mês grátis (então $29/mês são $319/ano, não $348). Os anuais dos concorrentes são mensal × 12; se algum fornecedor der desconto na cobrança anual, não verificamos, então os totais reais deles podem cair um pouco, nem de longe o bastante para fechar a diferença.

Mais uma sobre a Auth0, porque o modelo dela é o mais sutil. A Auth0 agora inclui uma conexão enterprise, SSO e SCIM no plano Free, grátis até 25.000 MAU. Com uma única conexão isso de fato não custa nada, e mérito por isso. Mas os níveis consumer pagos os retiram de novo; a nota de rodapé manda você "migrar para B2B" para manter o SSO. E o B2B custa várias vezes o preço consumer pelos mesmos usuários (o Essentials começa perto de $150/mês contra ~$35), então o verdadeiro imposto de SSO da Auth0 não é por conexão, é o prêmio B2B: um múltiplo do preço base pelo privilégio de vender para empresas. Essa base é precificada por controle deslizante de MAU e passa a personalizada acima de ~20k usuários, e é por isso que a Auth0 mostra quote nas nossas linhas de 10k e 50k em vez de um palpite interpolado.

(Mais dois fornecedores medem por um eixo diferente, então não estão nas tabelas: o mesmo imposto, outro chapéu. A **Okta* licencia o SSO por usuário, ~$2/usuário à la carte, escalando com as pessoas por trás de cada conexão em vez do número de conexões. O Duende IdentityServer vende SAML como um complemento fixo, ~$1.500/ano somados a uma licença de ~$5.750/ano, e aí você mesmo hospeda, aplica patches, escala e constrói a interface de admin, o MFA e a trilha de auditoria. Uma linha de aparência barata, uma fatura real enorme.)*

Perguntas frequentes

Por que tenho que pagar a mais por SSO?
Na maioria dos fornecedores, você não paga a mais porque o SSO custa mais a eles. Não custa. Você paga a mais porque os recursos de segurança e conformidade são os que você menos consegue recusar, então são os mais lucrativos para colocar atrás de um muro. SAML é um padrão consolidado, de vinte anos; o custo marginal de habilitá-lo para mais um inquilino arredonda para zero.

O que é o "imposto de SSO"?
A prática de cobrar um prêmio (normalmente por conexão, muitas vezes $75–$125/mês cada, ou forçando um upgrade para um nível Enterprise) para ligar o single sign-on. Há uma lista pública de infratores em sso.tax. É um imposto sobre fazer a coisa responsável, cobrado no momento em que você tem o menor poder de barganha para dizer não.

Quanto custa o SSO na Auth0, WorkOS e Clerk?
Pelas tarifas publicadas em junho de 2026: a WorkOS cobra cerca de $125/mês por conexão SSO (mais outros ~$125 por SCIM); a Clerk dá uma conexão grátis, depois cerca de $75/mês cada. A Auth0 é a exceção: inclui uma conexão enterprise e SCIM grátis até 25k MAU, depois remove o SSO dos planos pagos de autosserviço e encaminha o uso em produção ou multiconexão para uma trilha B2B apenas sob orçamento. Com dez clientes enterprise, WorkOS e Clerk somam cerca de $15k e $8,1k por ano só pelo SAML; a Auth0 não publica um número para isso. Os valores mudam, então confira a página de preços atual de cada fornecedor.

Existe um nível gratuito?
Sim. Grátis até 250 usuários ativos mensais, com todos os recursos incluídos, e (ao contrário de qualquer outro nível gratuito) conexões SSO/SAML ilimitadas, não só uma. O limite é apenas de escala: passe de 250 MAU e você migra para um plano pago. Sem cartão de crédito, sem SLA, suporte da comunidade.

Preciso fazer upgrade do meu plano para adicionar outro cliente OAuth ou aplicação?
Conosco não. Aplicações não são um eixo pago, então você registra uma por app ou serviço sem mudar de nível. Vários fornecedores limitam ou medem clientes (sobretudo os de máquina para máquina), o que é exatamente o que força a escolha entre reutilizar um cliente que não deveria e pagar pelo próximo nível.

Dá para saber muito sobre uma empresa pelo que ela cobra de você. A maioria dos fornecedores de autenticação cobra por coisas que não lhes custam nada: um flag SAML, um flag SCIM, uma linha para mais um cliente. O nosso se resume a uma única frase: pague pelo tamanho que você atinge, não pelos interruptores que você tem permissão de acionar.

Aqui está exatamente quem cobra pelo quê, fornecedor por fornecedor. O SSO está do nosso lado da mesa, sem custo adicional, e o mesmo vale para o décimo primeiro cliente que você não sabia que ia precisar. Veja o preço para os seus números.

An identity provider told us who you were, and we believed it

authagonal — Mon, 06 Jul 2026 22:59:23 +0000

Single sign-on has a quiet premise: when a user arrives from an identity provider, that provider has already vouched for them, so you can skip the password and just let them in. The whole point is to trust the IdP. The bug we're about to describe lived in the gap between "trust the IdP to authenticate its own users" and "trust whatever the IdP tells you about who its users are." Those are not the same sentence, and the difference was an account takeover.

Here's the setup. A tenant on our platform can configure federated connections: SAML to their corporate IdP, OIDC to another. A user signs in through one of those connections, the IdP posts back an assertion, and our server has to answer one question: which local account is this? Get that mapping wrong and you have either a stranger locked out of their own account or, far worse, a stranger walking into someone else's.

The join key was an email, and an email is just a claim

Our code answered "which account is this" the obvious way. The assertion carried an email, so we looked the user up by it: FindByEmailAsync(assertedEmail). If a matching account existed, the returning federated user was resolved onto it and signed in. Clean, simple, and exactly how a lot of SSO integrations are written.

The problem is what that email actually is. It is not a fact the IdP proved. It is a string in an assertion, and the assertion is only as trustworthy as the connection it came through. In a multi-tenant world you do not control every connection. Anyone who can stand up one (their own SAML IdP, their own OIDC provider) can put any string they like in the email field. So a connection you do not trust asserts email = ceo@othercorp.com, our lookup finds the real CEO's account, and the attacker is signed in as them. No password, no phishing, no flaw in the crypto. The signature on the assertion was perfectly valid. It just vouched for a claim we should never have treated as an identity.

The unsettling part is that every individual piece worked. The IdP authenticated its own user correctly. The signature verified. The account existed. The takeover wasn't a failure of any check; it was using the wrong field as the key.

Why more validation is not the fix

The tempting reaction is to validate the email harder. Require email_verified. Check the domain. Add a rule. But notice the shape of the trap: the attacker controls the assertion, so any property you read off the assertion is a property the attacker can set. Demanding email_verified = true from a connection the attacker owns is asking the fox to certify the henhouse. You cannot validate your way out of trusting the wrong source.

The email is fine as a convenience. It is a terrible primary key, because it is global (the same address can show up across many providers) and forgeable (it is whatever the asserting connection says it is). A join key has to be neither.

The fix was to change the key, not to add checks

The real fix was to stop joining on email at all and join on the one thing a connection cannot forge for a provider it does not own: the pair (provider, sub). The sub is the subject identifier the provider issues for that user, scoped to that provider. A returning user is resolved by looking up the local identity previously linked to this connection's (provider, sub). An attacker's connection has its own provider id; it can mint any sub it likes within its own namespace, but it cannot produce the (provider, sub) of someone else's connection. The namespace is the moat.

Email then drops to the role it should always have had: a hint for linking, never for resolving, and only when it is vouched. We match an asserted email to an existing account only when the email is verified by a source we actually trust for that domain: email_verified from a connection whose domain is in the tenant's AllowedDomains. Outside that, a new federated identity gets its own account, not someone else's.

The lesson, factored out

When you federate identity, separate two questions you're tempted to merge. "Did this provider authenticate this user?" is answered by the signature. "Who is this user in my system?" has to be answered by a key the asserting party cannot forge across boundaries, which means a per-provider subject, not a global attribute like email. Treat every field in an assertion as attacker-controlled unless the specific source of that field is one you trust for that specific claim. Email is the field people reach for first because it's human and unique-looking. It is exactly the wrong one.

We shipped this as part of a pre-launch security pass over our own auth server, before anyone trusted us with their logins. It's the kind of bug that passes every test, verifies every signature, and hands over the keys to whoever asks in the right format. The fix wasn't a better lock. It was realizing we'd been reading the wrong line of the ID.

Federating identity safely comes down to joining on a key the asserting party cannot forge, and getting it wrong is an account takeover that passes every test. Authagonal resolves federated users by their per-provider subject, never the email in the assertion.

El scale-to-zero no sabe contar hasta uno

authagonal — Mon, 06 Jul 2026 00:08:27 +0000

El consejo siempre tuvo la misma forma. Tu tráfico de autenticación llega en picos. Tu clúster de Kubernetes está mayormente en silencio. Azure Container Apps escala a cero y te cobra por lo que usas. Estás pagando las 24 horas del día por un clúster que pasa la mayor parte de su vida esperando.

Lo tomamos en serio hasta el punto de calcular correctamente el costo de la migración. Luego la descartamos. No por el precio de la transición, ni por los arranques en frío, aunque los arranques en frío solos deberían haber sido suficientes. La descartamos porque al vocabulario de la plataforma le falta un número, y es el único número que realmente le importa a nuestro núcleo de autenticación.

Serverless cuenta hasta cero y hasta N

Los runtimes de scale-to-zero conocen dos números. Cero, cuando nadie llama. N, cuando lo hacen, con N flotando según la demanda. Para el manejo de solicitudes sin estado, ese vocabulario es perfecto, razón por la cual el consejo suena tan bien. La mayoría de los backends web realmente tienen esa forma: cada solicitud independiente, cada instancia desechable, cero tráfico mereciendo una factura de cero.

La cara pública de un sistema de autenticación se ve así también. Puntos finales de tokens, páginas de inicio de sesión, JWKS. Sin estado, con picos, amigable con la caché.

Debajo hay una capa que no es nada de eso.

El número es uno

Bajo los puntos finales, nuestra backplane ejecuta una capa de coordinación. En cualquier momento, exactamente una réplica tiene el arrendamiento de liderazgo del clúster (un arrendamiento de blob hoy en día, ya no gossip, que es una historia para otra publicación) y ejecuta los trabajos singleton: el barrido de retención, el pase de entrega de webhooks, el trabajo donde dos ejecutores concurrentes significan efectos secundarios disparados por duplicado y cero ejecutores significa que las cosas, silenciosamente, no suceden nunca.

El número que esa capa necesita es uno. No cero cuando todo está tranquilo. No N bajo carga. Uno, mantenido continuamente, con una transferencia verificable cuando el titular muere. El scale-to-zero no tiene forma de decir "uno, siempre". Puede decir "al menos uno mientras haya tráfico", lo cual es una promesa diferente, y la diferencia entre esas dos promesas es exactamente el modo de fallo que una elección de líder existe precisamente para prevenir.

Por eso el gráfico de utilización nos estaba mintiendo. Un clúster de autenticación tranquilo no está de brazos cruzados. Está manteniendo un arrendamiento, manteniendo las claves de firma calientes y listo para responder a la siguiente validación de token en milisegundos de un solo dígito. Silencioso e inactivo son estados diferentes, y los paneles de facturación solo te muestran uno de ellos.

Puedes fingirlo, y eso es peor

Puedes forzar "exactamente uno" en un runtime serverless. Fija las réplicas mínimas en uno y has comprado un servidor siempre activo en una plataforma cuyo instinto completo es quitarte las instancias silenciosas. Cada evento de escalado, cada reinicio iniciado por la plataforma, cada cambio de revisión se convierte en una cuestión de liderazgo cuyo momento no controlas. Estaríamos luchando contra el comportamiento central del runtime para preservar el nuestro, para siempre, y pagando por el privilegio.

Y el fallo recae sobre la peor persona posible. La solicitud que paga un arranque en frío es un humano tratando de iniciar sesión. "Tu inicio de sesión fue lento porque nuestro servicio de autenticación estaba dormido" no es una frase que nadie debería llegar a publicar.

La factura tuvo una solución aburrida

¿Y el dinero con el que empezó todo esto? Bastaron un planificador y una SKU. El clúster de desarrollo ahora se desasigna cuando nadie lo está usando, y el grupo de nodos pasó a una SKU más barata. Un párrafo es todo lo que eso merece, y ese es el punto: "dejar de pagar por inactividad" es un objetivo, no una arquitectura, y la mayor parte del objetivo era alcanzable con un cambio de configuración en lugar de un cambio de plataforma.

La prueba de forma

La regla que nos quedamos: hacer coincidir el runtime con la forma real de la carga de trabajo, no con su gráfico de tráfico. Serverless recompensa lo que es sin estado y a ráfagas. Castiga cualquier cosa que deba mantener un rol continuo y exclusivo, y un núcleo de autenticación que protege las claves de firma y elige quién ejecuta los trabajos destructivos es el ejemplo más puro de ese segundo tipo que conocemos.

No estamos en contra del serverless. Gran parte de nuestra superficie sin estado viviría felizmente en él. Pero la capa que tiene que contar exactamente hasta uno se queda en una infraestructura aburrida, siempre activa e inspeccionable.

Esa capa es también precisamente lo que dejas de operar cuando ejecutas la autenticación en Authagonal en lugar de ejecutar la backplane tú mismo.

Scale-to-zero can't count to one

authagonal — Mon, 06 Jul 2026 00:04:26 +0000

The advice always had the same shape. Your auth traffic is spiky. Your Kubernetes cluster sits mostly quiet. Azure Container Apps scales to zero and bills you for what you use. You are paying around the clock for a cluster that spends most of its life waiting.

We took it seriously enough to cost the migration properly. Then we killed it. Not because of the price of the cutover, and not because of cold starts, although cold starts alone should have been enough. We killed it because the platform's vocabulary is missing a number, and it's the only number our auth core actually cares about.

Serverless counts to zero and to N

Scale-to-zero runtimes know two numbers. Zero, when nobody is calling. N, when they are, with N floating on demand. For stateless request handling that vocabulary is perfect, which is why the advice sounds so right. Most web backends really are that shape: every request independent, every instance disposable, zero traffic deserving a zero bill.

An auth system's public face looks like that too. Token endpoints, login pages, JWKS. Stateless, spiky, cache-friendly.

Underneath it is a layer that is none of those things.

The number is one

Below the endpoints, our backplane runs a coordination layer. At any moment exactly one replica holds the cluster leadership lease (a blob lease these days, not gossip, which is a story for another post) and runs the singleton jobs: the retention sweep, the webhook delivery pass, the work where two concurrent runners means double-fired side effects and zero runners means things silently never happen.

The number that layer needs is one. Not zero when things are quiet. Not N under load. One, held continuously, with a verifiable handover when the holder dies. Scale-to-zero has no way to say "one, always". It can say "at least one while there's traffic", which is a different promise, and the difference between those two promises is exactly the failure mode a leader election exists to prevent.

This is why the utilization graph was lying to us. A quiet auth cluster is not doing nothing. It is holding a lease, keeping signing keys hot, and standing ready to answer the next token validation in single-digit milliseconds. Quiet and idle are different states, and billing dashboards only show you one of them.

You can fake it, and that's worse

You can force "exactly one" onto a serverless runtime. Pin minimum replicas to one and you have bought an always-on server on a platform whose whole instinct is to take quiet instances away from you. Every scale event, every platform-initiated restart, every revision swap becomes a leadership question you don't control the timing of. We would be fighting the runtime's core behavior to preserve ours, forever, and paying for the privilege.

And the failure lands on the worst possible person. The request that pays a cold start is a human trying to log in. "Your sign-in was slow because our auth service was asleep" is not a sentence anyone should ship.

The bill had a boring fix

What about the money that started all this? It fell to a scheduler and a SKU. The dev cluster now deallocates when nobody is using it, and the node pool moved to a cheaper SKU. One paragraph is all that deserves, and that's the point: "stop paying for idle" is a goal, not an architecture, and most of the goal was reachable with a config change instead of a re-platform.

The shape test

The rule we kept: match the runtime to the workload's actual shape, not to its traffic graph. Serverless rewards stateless and bursty. It punishes anything that must hold a continuous, exclusive role, and an auth core that guards signing keys and elects who runs the destructive jobs is the purest example of that second kind we know.

We're not against serverless. Plenty of our stateless surface would live happily on it. But the layer that has to count to exactly one is staying on boring, always-on, inspectable infrastructure.

That layer is also precisely what you stop operating when you run auth on Authagonal instead of running the backplane yourself.

El impuesto al SSO, en dólares: lo que SAML cuesta de verdad en Auth0, WorkOS y Clerk

authagonal — Fri, 03 Jul 2026 01:34:50 +0000

Escribimos una vez sobre el impuesto a las funciones: el truco de cobrarte por activar un booleano que ya está escrito, sobre una infraestructura que ya está en marcha. Aquel artículo era el argumento. Este es el recibo.

Porque «el SSO cuesta extra» es fácil de aceptar con un gesto y fácil de olvidar. Una cifra en una factura cuesta más de olvidar. Así que pongamos toda la factura sobre la mesa, para tres momentos que atraviesa todo producto B2B: la base de la plataforma (facturada por usuarios activos mensuales, lo que todos cobran y es justo: más usuarios cuestan de verdad más de atender), más las dos líneas que realmente miden SAML, la conexión SSO y el aprovisionamiento SCIM que la acompaña. Tres columnas en vivo, un total global. Incluimos la base a propósito. El impuesto al SSO no es el único lugar donde se escapa el dinero; la brecha en el precio de la plataforma misma asciende a miles al año, y omitirla subestimaría lo que el modelo del impuesto a las funciones te cuesta de verdad. Todas las tarifas corresponden a los precios publicados por cada proveedor en junio de 2026.

El SSO ni siquiera es el único medidor, solo el más ruidoso. Hay uno más silencioso: el límite de clientes OAuth, las apps y servicios que registras de tu lado. Nunca muerde durante la evaluación; muerde a mitad de la integración, la tarde en que vas a conectar una herramienta más y descubres que te has quedado sin cupo, con la única opción de reutilizar un cliente que no deberías (que tu mesa de soporte emita tokens para tu API principal no es una frase que quieras leerle a un auditor de SOC 2) o saltar de nivel para añadir una sola fila a una tabla. Un cliente es una fila y un secreto; no le cuesta nada al proveedor, así que no lo medimos. Pero el SSO es el impuesto que da titulares, así que es eso lo que calculan las tablas de abajo.

Escenario 1: tu primer acuerdo enterprise

~1.000 MAU. Tu primer logo de verdad acaba de firmar, con la condición de iniciar sesión a través de su propio proveedor de identidad, con sus usuarios aprovisionados automáticamente. Una conexión SAML, con SCIM:

Proveedor	Plan /mes	SSO /mes	SCIM /mes	Total /mes	Total /año
Authagonal	$29	$0	$0	$29	$319
Clerk	$25	$0 (la primera gratis)	$0	$25	$300
WorkOS	$0	$125	$125	$250	$3.000
Auth0	$0	incl.	incl.	$0	$0

A este tamaño, tres de los cuatro rondan el cero. La primera conexión de Clerk es gratis (su plan cuesta $25). El nivel Free de Auth0 ahora incluye una conexión enterprise, SSO autoservicio y SCIM por $0, hasta 25.000 MAU. Gratis de verdad, y mérito por ello (la trampa viene más abajo). Nosotros, $29, todo incluido. Solo WorkOS se sale de la fila: $3.000/año ya, todo ello el impuesto al SSO-y-SCIM por conexión. Hasta ahora el impuesto se esconde en buena medida: añade un segundo cliente enterprise y míralo salir a la superficie.

Escenario 2: un puñado de clientes enterprise

~10.000 MAU, el SSO ya forma parte del proceso de venta. Tres conexiones SAML, con SCIM:

Proveedor	Plan /mes	SSO /mes	SCIM /mes	Total /mes	Total /año
Authagonal	$149	$0	$0	$149	$1.639
Clerk	$25	$150 (1 gratis + 2×$75)	$0	$175	$2.100
WorkOS	$0	$375	$375	$750	$9.000
Auth0	presupuesto	presupuesto	presupuesto	presupuesto	presupuesto

Ahora somos la línea más barata de la tabla, no por recortar funciones, sino porque la base es todo lo que pagas. Cada una de esas tres conexiones es un cliente que paga, así que el medidor por conexión se acelera justo cuando el SSO empieza a hacer su trabajo. La línea SCIM aparte de WorkOS ya lo ha duplicado a $9.000/año; la nuestra sigue en $1.639, SAML y SCIM incluidos.

Escenario 3: el SSO ya es requisito básico

~50.000 MAU. Diez clientes enterprise, diez conexiones SAML, con SCIM. Ya nadie te evalúa sin ello:

Proveedor	Plan /mes	SSO /mes	SCIM /mes	Total /mes	Total /año
Authagonal	$339	$0	$0	$339	$3.729
Clerk	$25	$675 (1 gratis + 9×$75)	$0	$700	$8.400
WorkOS	$0	$1.250	$1.250	$2.500	$30.000
Auth0	presupuesto	presupuesto	presupuesto	presupuesto	presupuesto

Lee la fila de arriba frente a la de abajo. La factura anual entera de Authagonal (plataforma, SAML ilimitado, SCIM, MFA, auditoría, marca, todo) es de $3.729. El impuesto al SSO-y-SCIM de WorkOS por sí solo es de $30.000: más de ocho veces nuestra factura entera, antes de que WorkOS haya cobrado un solo centavo por la plataforma en sí, y no le hace falta, porque el impuesto es la plataforma. Esa brecha de ~$26.000 al año es exactamente lo que quedaba sin mencionar cuando solo mostrábamos la línea del SSO. Los bytes son idénticos a un inicio de sesión con contraseña; el código se escribió una vez y se entregó a todos. Estarías pagando, cada año, por veinte casillas de verificación y una plataforma que podrías haber tenido por aproximadamente la octava parte del precio.

Sobre las cifras. Plan es el precio de la plataforma escalonado por MAU: lo único por lo que nosotros, y la mayoría de proveedores, cobramos legítimamente más a medida que creces. WorkOS incluye la gestión de usuarios gratis hasta 1M de MAU, así que toda su factura es el impuesto por conexión. Clerk Pro cuesta $25/mes con los MAU mayormente incluidos a estos volúmenes (posible un modesto exceso a 50k); su primera conexión SSO es gratis, luego unos $75 cada una, y SCIM viene gratis con una conexión. Auth0 cambió su modelo hace poco lo suficiente como para merecer su propio párrafo, justo debajo. Las cifras anuales de Authagonal son lo que de verdad se factura: 11× el precio mensual, porque los planes anuales regalan un mes (así que $29/mes son $319/año, no $348). Los precios anuales de la competencia son mensual × 12; si algún proveedor descuenta la facturación anual no lo hemos verificado, así que sus totales reales podrían bajar un poco, ni de lejos lo suficiente para cerrar la brecha.

Una cosa más sobre Auth0, porque su modelo es el más sutil. Auth0 ahora incluye una conexión enterprise, SSO y SCIM en su plan Free, gratis hasta 25.000 MAU. Con una sola conexión eso no cuesta nada de verdad, y mérito por ello. Pero sus niveles consumer de pago los vuelven a quitar; la nota al pie te dice que «pases a B2B» para conservar el SSO. Y B2B cuesta varias veces el precio consumer por los mismos usuarios (Essentials arranca cerca de $150/mes frente a ~$35), así que el verdadero impuesto al SSO de Auth0 no es por conexión, es la prima B2B: un múltiplo del precio base por el privilegio de venderles a empresas. Esa base se tarifica con deslizador por MAU y pasa a personalizada por encima de ~20k usuarios, razón por la cual Auth0 muestra quote en nuestras filas de 10k y 50k en lugar de una estimación interpolada.

(Otros dos proveedores miden sobre un eje distinto, así que no están en las tablas: mismo impuesto, otro sombrero. **Okta* licencia el SSO por usuario, ~$2/usuario a la carta, escalando con los humanos detrás de cada conexión en lugar del número de conexiones. Duende IdentityServer vende SAML como un complemento plano, ~$1.500/año además de una licencia de ~$5.750/año, y luego tú alojas, parcheas, escalas y construyes tú mismo la interfaz de administración, el MFA y el registro de auditoría. Una línea de aspecto barato, una factura real enorme.)*

Preguntas frecuentes

¿Por qué tengo que pagar extra por el SSO?
En la mayoría de proveedores, no pagas extra porque el SSO les cueste más. No es así. Pagas extra porque las funciones de seguridad y cumplimiento son las que menos puedes rechazar, así que son las más rentables de poner tras un muro. SAML es un estándar asentado, de veinte años; el costo marginal de habilitarlo para un inquilino más se redondea a cero.

¿Qué es el «impuesto al SSO»?
La práctica de cobrar una prima (normalmente por conexión, a menudo $75–$125/mes cada una, o forzando una subida a un nivel Enterprise) para activar el inicio de sesión único. Hay una lista pública de infractores en sso.tax. Es un impuesto por hacer lo responsable, cobrado en el momento en que menos margen tienes para decir que no.

¿Cuánto cuesta el SSO en Auth0, WorkOS y Clerk?
Según sus tarifas publicadas en junio de 2026: WorkOS cobra unos $125/mes por conexión SSO (más otros ~$125 por SCIM); Clerk te da una conexión gratis, luego unos $75/mes cada una. Auth0 es el que se sale de la norma: incluye una conexión enterprise y SCIM gratis hasta 25k MAU, luego retira el SSO de sus planes de pago de autoservicio y deriva el uso en producción o multiconexión a una vía B2B solo bajo presupuesto. Con diez clientes enterprise, WorkOS y Clerk rondan los $15k y $8,1k al año solo por SAML; Auth0 no publica una cifra para ello. Las cifras cambian, así que consulta la página de precios actual de cada proveedor.

¿Hay un nivel gratuito?
Sí. Gratis hasta 250 usuarios activos mensuales, con todas las funciones incluidas, y (a diferencia de cualquier otro nivel gratuito) conexiones SSO/SAML ilimitadas, no solo una. El tope es únicamente de escala: supera los 250 MAU y pasas a un plan de pago. Sin tarjeta de crédito, sin SLA, soporte de la comunidad.

¿Tengo que subir de plan para añadir otro cliente OAuth o aplicación?
Con nosotros no. Las aplicaciones no son un eje de pago, así que registras una por app o servicio sin cambiar de nivel. Varios proveedores sí limitan o miden los clientes (sobre todo los de máquina a máquina), que es lo que fuerza la elección entre reutilizar un cliente que no deberías y pagar por el siguiente nivel.

Se puede saber mucho de una empresa por aquello que te cobra. La mayoría de los proveedores de autenticación cobran por cosas que a ellos no les cuestan nada: un flag SAML, un flag SCIM, una fila para un cliente más. El nuestro se reduce a una sola línea: paga por lo grande que llegues a ser, no por qué interruptores se te permite activar.

Aquí tienes exactamente quién cobra por qué, proveedor por proveedor. El SSO está en nuestro lado de la mesa, sin recargo, y lo mismo vale para el undécimo cliente que no sabías que ibas a necesitar. Míralo con el precio para tus cifras.

The SSO tax, in dollars: what SAML actually costs at Auth0, WorkOS, and Clerk

authagonal — Fri, 03 Jul 2026 01:34:10 +0000

We wrote once about the feature tax: the trick of charging you to flip a boolean that's already written, on infrastructure that's already running. That piece was the argument. This one is the receipt.

Because "SSO costs extra" is easy to nod along to and easy to forget. A number on an invoice is harder to forget. So let's put the whole invoice on the table for three moments every B2B product passes through: the platform base (priced by monthly active users, which everyone charges and which is fair: more users genuinely cost more to serve), plus the two line items that actually meter SAML, the SSO connection and the SCIM provisioning that rides it. Three live columns, one all-in total. We include the base on purpose. The SSO tax isn't the only place money leaks; the gap in the platform price itself runs to thousands a year, and leaving it out would understate what the feature-tax model really costs you. All rates are each vendor's published June 2026 pricing.

SSO isn't even the only meter, just the loudest. There's a quieter one: the cap on OAuth clients, the apps and services you register on your own side. It never bites during evaluation; it bites mid-integration, the afternoon you go to wire up one more tool and find you're out, left to either reuse a client you shouldn't (your support desk minting tokens for your core API is not a sentence you want to read to a SOC 2 auditor) or jump a tier to add one row to a table. A client is a row and a secret; it costs the vendor nothing, so we don't meter it. But SSO is the headline tax, so that's what the tables below price.

Scenario 1: your first enterprise deal

~1,000 MAU. Your first real logo just signed, on the condition they log in through their own identity provider, with their users provisioned automatically. One SAML connection, with SCIM:

Vendor	Plan /mo	SSO /mo	SCIM /mo	All-in /mo	All-in /yr
Authagonal	$29	$0	$0	$29	$319
Clerk	$25	$0 (first free)	$0	$25	$300
WorkOS	$0	$125	$125	$250	$3,000
Auth0	$0	incl.	incl.	$0	$0

At this size, three of the four sit near zero. Clerk's first connection is free (its plan is $25). Auth0's Free tier now bundles one enterprise connection, self-service SSO, and SCIM for $0, up to 25,000 MAU. Genuinely free, and credit for it (the catch is further down). We're $29, all-in. Only WorkOS breaks ranks: $3,000/yr already, all of it the per-connection SSO-and-SCIM tax. So far the tax is mostly hiding: add a second enterprise customer and watch it surface.

Scenario 2: a handful of enterprise customers

~10,000 MAU, SSO now part of the sales motion. Three SAML connections, with SCIM:

Vendor	Plan /mo	SSO /mo	SCIM /mo	All-in /mo	All-in /yr
Authagonal	$149	$0	$0	$149	$1,639
Clerk	$25	$150 (1 free + 2×$75)	$0	$175	$2,100
WorkOS	$0	$375	$375	$750	$9,000
Auth0	quote	quote	quote	quote	quote

Now we're the cheapest line in the table, not by trimming features but because the base is all you pay. Every one of those three connections is a paying customer, so the per-connection meter speeds up exactly as SSO starts doing its job. WorkOS's separate SCIM line has already doubled it to $9,000/yr; ours is still $1,639, SAML and SCIM included.

Scenario 3: SSO is now table stakes

~50,000 MAU. Ten enterprise customers, ten SAML connections, with SCIM. Nobody evaluates you without it anymore:

Vendor	Plan /mo	SSO /mo	SCIM /mo	All-in /mo	All-in /yr
Authagonal	$339	$0	$0	$339	$3,729
Clerk	$25	$675 (1 free + 9×$75)	$0	$700	$8,400
WorkOS	$0	$1,250	$1,250	$2,500	$30,000
Auth0	quote	quote	quote	quote	quote

Read the top row against the bottom one. Authagonal's entire annual bill (platform, unlimited SAML, SCIM, MFA, audit, branding, the lot) is $3,729. WorkOS's SSO-and-SCIM tax alone is $30,000: more than eight times our whole invoice, before WorkOS has charged a cent for the platform itself, and it doesn't need to, because the tax is the platform. That ~$26,000-a-year gap is exactly what was going unmentioned when we only showed the SSO line. The bytes are identical to a password login; the code was written once and shipped to everyone. You'd be paying, every year, for twenty checkboxes and a platform you could have had for roughly an eighth of the price.

On the numbers. Plan is the MAU-tiered platform price: the one thing we, and most vendors, legitimately charge more for as you grow. WorkOS includes user management free to 1M MAU, so its whole bill is the per-connection tax. Clerk Pro is $25/mo with MAU largely included at these volumes (modest overage possible at 50k); its first SSO connection is free, then ~$75 each, and SCIM comes free with a connection. Auth0 changed its model recently enough that it needs its own paragraph, just below. Authagonal's annual figures are what it actually bills: 11× the monthly price, because annual plans get a month free (so $29/mo is $319/yr, not $348). Competitor annuals are monthly × 12; if a vendor discounts annual billing we haven't vetted it, so their real totals may dip a little, nowhere near enough to close the gap.

One more on Auth0, because its model is the subtlest. Auth0 now bundles one enterprise connection, SSO, and SCIM into its Free plan, free up to 25,000 MAU. At a single connection that genuinely costs nothing, and credit for it. But its paid consumer tiers strip them back out; the footnote tells you to "upgrade to B2B" to keep SSO. And B2B runs several times the consumer price for the same users (Essentials starts near $150/mo against ~$35), so Auth0's real SSO tax isn't per-connection, it's the B2B premium: a multiple on the base price for the privilege of selling to businesses. That base is slider-priced by MAU and goes custom above ~20k users, which is why Auth0 reads quote in our 10k and 50k rows instead of an interpolated guess.

(Two more vendors meter on a different axis, so they're not in the tables: same tax, different hat. **Okta* licenses SSO per user, ~$2/user à la carte, scaling with the humans behind each connection rather than the connection count. Duende IdentityServer sells SAML as a flat add-on, ~$1,500/yr on top of a ~$5,750/yr license, and then you host, patch, scale, and build the admin UI, MFA, and audit trail yourself. Cheap-looking line item, enormous real bill.)*

Frequently asked

Why do I have to pay extra for SSO?
For most vendors, you don't pay extra because SSO costs them more. It doesn't. You pay extra because security and compliance features are the ones you're least able to refuse, so they're the most profitable to gate. SAML is a settled, twenty-year-old standard; the marginal cost of enabling it for one more tenant rounds to zero.

What is the "SSO tax"?
The practice of charging a premium (usually per connection, often $75–$125/mo each, or by forcing an Enterprise-tier upgrade) to turn on single sign-on. There's a public list of offenders at sso.tax. It's a tax on doing the responsible thing, collected at the moment you have the least leverage to say no.

How much does SSO cost at Auth0, WorkOS, and Clerk?
On their published June 2026 rates: WorkOS bills about $125/mo per SSO connection (plus another ~$125 for SCIM); Clerk gives you one free connection, then about $75/mo each after. Auth0 is the odd one out: it includes one enterprise connection and SCIM free up to 25k MAU, then removes SSO from its paid self-serve plans and routes production or multi-connection use to a quote-only B2B track. At ten enterprise customers, WorkOS and Clerk run roughly $15k and $8.1k a year for SAML alone; Auth0 won't publish a number for it. Figures change, so check each vendor's current pricing page.

Is there a free tier?
Yes. Free up to 250 monthly active users, every feature included, and (unlike every other free tier) unlimited SSO/SAML connections, not just one. It's capped only on scale: cross 250 MAU and you move onto a paid plan. No credit card, no SLA, community support.

Do I have to upgrade my plan to add another OAuth client or application?
Not with us. Applications aren't a paywalled axis, so you register one per app or service without changing tiers. Several providers do cap or meter clients (especially machine-to-machine ones), which is what forces the choice between reusing a client you shouldn't and paying for the next tier.

You can tell a lot about a company from what it charges you for. Most auth vendors charge for things that cost them nothing: a SAML flag, a SCIM flag, a row for one more client. Ours comes down to a single line: pay for how big you get, not for which switches you're allowed to flip.

Here's exactly who charges for what, vendor by vendor. SSO's on our side of the table, at no extra charge, and so is the eleventh client you didn't know you'd need. See it priced for your numbers.

Quitter Duende auto-hébergé : ce qui migre, et ce que vous cessez d'exploiter

authagonal — Thu, 02 Jul 2026 10:03:02 +0000

Duende IdentityServer est un logiciel vraiment excellent : si vous voulez posséder votre couche d'identité de bout en bout, c'est la référence en .NET. Mais cette « possession », c'est justement tout le coût : vous l'hébergez, vous la patchez, vous la mettez à l'échelle et vous construisez tout ce qui gravite autour, l'interface d'administration, le MFA, les journaux d'audit, l'image de marque, une page de statut, la gestion des utilisateurs et des rôles. À un moment donné, une équipe décide qu'elle préfère ne pas exploiter d'IdP, et la seule question qui compte est de savoir à quel point la migration est douloureuse. Voici ce qui migre réellement.

Ce que vous exploitez vraiment

Auto-héberger Duende vous rend responsable de bien plus que des points de terminaison de tokens :

L'IdP lui-même : hébergement, mise à l'échelle, patching et la licence (le SAML est un module payant en supplément).
Tout ce qui l'entoure et que vous avez construit vous-même : portail d'administration, enrôlement MFA, journalisation d'audit, image de marque personnalisée, une page de statut, gestion des utilisateurs et des rôles.

C'est généralement cette deuxième liste qui consomme le plus de temps.

Ce qui migre, et c'est essentiellement mécanique

Duende conserve sa configuration dans SQL (la ConfigurationDb) et ses utilisateurs dans ASP.NET Identity. Une migration lit les deux :

Clients → clients OAuth, y compris les URI de redirection et de déconnexion, les origines CORS, les types d'autorisation, la sémantique d'usage et d'expiration des refresh tokens, et les durées de vie des device codes. Les clients désactivés sont importés désactivés ; les secrets expirés sont ignorés avec un avertissement.
Scopes → les ApiScopes et IdentityResources se mappent directement. La couche intermédiaire ApiResource de Duende (une audience plus une liste de claims partagée) s'aplatit sur le modèle plus simple : le nom de la ressource devient une audience sur chaque client qui utilise un scope membre, et ses claims fusionnent avec ces scopes.
Utilisateurs → la bonne nouvelle : les hachages de mot de passe d'ASP.NET Identity V3 (et le bcrypt hérité) se vérifient nativement et sont rehachés à la première connexion. Aucune réinitialisation de mot de passe, aucun ticket de support, rien que vos utilisateurs ne remarquent. (C'est la partie réellement difficile quand on quitte Auth0 : avec Duende, ça fonctionne tout simplement, parce que c'est le même hachage que celui que votre application utilise déjà.)
Les rôles et affectations, les connexions externes et les fournisseurs d'identité OIDC sont tous repris. Les fournisseurs SAML sont signalés pour que vous les reconfiguriez de l'autre côté.

L'aspect stabilité de l'identité

Comme pour tout changement d'IdP, ce qu'il faut bien gérer, c'est de ne pas changer le sub de l'utilisateur ni le client_id : les refresh tokens en aval, les lignes SCIM dans les IdP des clients et les identifiants d'utilisateur stockés dans votre propre base de données y font tous référence. L'importateur préserve les deux. Et si l'un de vos propriétaires de portail existe aussi comme utilisateur Duende sous un identifiant différent, il les réconcilie (en basculant vers le sub Duende) par étapes échelonnées et réversibles, plutôt que de laisser un propriétaire à moitié migré incapable de se connecter.

Une parenthèse sur le test des migrations (un piège .NET)

Nous testons l'importateur contre une vraie base de données Duende alimentée en données, pas contre des mocks, et ça a porté ses fruits. ASP.NET Identity stocke AspNetUsers.LockoutEnd sous forme de datetimeoffset, et le lire avec reader.GetDateTime() lève une InvalidCastException sur ce type. Ainsi, un seul utilisateur verrouillé aurait fait échouer l'import de la totalité des utilisateurs. On ne le découvre qu'en exécutant l'importateur contre des données réelles contenant un utilisateur verrouillé. Si vous évaluez un outil de migration, voilà la question qui mérite d'être posée : est-il testé contre une base de données peuplée, ou simplement mocké contre l'API source ?

Ce que vous cessez de faire

L'intérêt de la migration, ce n'est pas la migration elle-même : c'est tout ce qui vient après. SAML, SCIM, MFA, journaux d'audit, domaines personnalisés et image de marque sont inclus au lieu d'être des choses que vous construisez et exploitez, et le patching et la mise à l'échelle de l'IdP cessent d'être votre problème. Si l'auto-hébergement de Duende était une décision délibérée (« nous voulons un contrôle total ») et qu'elle l'est toujours, restez : c'est un choix parfaitement valable. Ceci s'adresse au moment où exploiter un IdP n'est plus là où vous voulez passer votre temps.

Si vous l'envisagez

La migration est essentiellement mécanique, les mots de passe sont repris sans réinitialisation, et l'aperçu est en lecture seule : pointez-le vers votre base de données Duende et il vous montre exactement ce qui serait importé avant que quoi que ce soit ne soit écrit.

→ Migrer depuis Duende

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.

And if you would rather not run a clustering protocol at all, that is the pitch: Authagonal keeps this boring so you never have to debug your own split-brain.