DEV Community: authagonal

Un BFF para muchos inquilinos, y la única petición que llega sin cookie

authagonal — Fri, 31 Jul 2026 12:51:23 +0000

A las aplicaciones de página única se les enseñó a guardar sus propios tokens. La aplicación ejecuta el flujo de OAuth en el navegador, recibe un token de acceso y normalmente también un token de actualización, los guarda en algún lugar de JavaScript y los adjunta a cada llamada a la API. Está bien documentado, es lo que muestran la mayoría de los tutoriales, y coloca tu credencial más longeva en el único sitio que no puedes defender: un entorno de ejecución que ejecuta de buena gana cualquier cosa que consiga llegar a la página. Una inyección exitosa, una dependencia comprometida en algún punto de tu build, y ya nadie necesita hacer phishing a nadie. Leen el token y se marchan, y sigue funcionando hasta que caduca.

El patrón backend-for-frontend pone la credencial fuera de alcance. El navegador habla con un pequeño servidor que pertenece a tu aplicación, y ese servidor es el cliente confidencial de OAuth. Ejecuta el intercambio de código, guarda los tokens de acceso y de actualización, y no entrega al navegador más que una cookie opaca. Esto es una descripción de cómo construimos el nuestro, y de la única parte que resultó ser genuinamente interesante: hacer que sirviera a más de un inquilino.

Con qué se queda el navegador

Una cookie llamada __Host-agbff, marcada como HttpOnly, SameSite=Lax, con alcance a toda la ruta y sin caducidad, de modo que muere con la sesión del navegador. Su valor son 256 bits de aleatoriedad y nada más. No es un token, no se decodifica en nada, y robarla del cable no es algo que puedas hacerle a una cookie __Host- sobre TLS.

Todo lo real reside en el lado del servidor, en un registro de sesión dentro de una caché distribuida: el token de acceso, el token de actualización, el token de identidad, cuándo caduca el token de acceso y a qué inquilino pertenece la sesión. El inicio de sesión en sí es un flujo de código de autorización corriente con PKCE, ejecutado por un cliente confidencial que se autentica ante el endpoint de tokens con su secreto. El token de identidad se valida como es debido a la vuelta: emisor, audiencia, firma contra las claves publicadas, tiempo de vida, y luego una comparación en tiempo constante del nonce con el valor guardado antes de la redirección. Solo después de todo eso existe una sesión y se establece una cookie.

Una cabecera de la que se comprueba su existencia, y nada más

El navegador llama al BFF para obtener su propia información de usuario y para alcanzar la API que hace de proxy, y esas llamadas llevan una cabecera personalizada, x-authagonal-bff. Su valor es irrelevante. Su presencia es toda la comprobación.

Parece perezoso pero no lo es. Toda la clase de falsificación de petición entre sitios se apoya en el envío de un formulario, una etiqueta de imagen o una navegación que otro origen puede desencadenar mientras tu cookie va de acompañante, y ninguna de esas cosas puede establecer una cabecera personalizada. En el momento en que un JavaScript atacante intenta añadir una, deja de ser una petición simple y pasa a ser una con verificación previa, que tu política de CORS rechaza. La cabecera no es un secreto que haya que adivinar, es la prueba de que la petición vino de código y no de marcado.

Se exige en las llamadas hechas por script y deliberadamente no en las que por naturaleza son navegaciones de nivel superior: iniciar un inicio de sesión, volver del proveedor de identidad, seguir un enlace de cierre de sesión. Exigir una cabecera personalizada en una navegación del navegador no haría más que romper la navegación.

Actualizar, exactamente una vez

Cada petición que pasa por el proxy puede descubrir que el token de acceso está a punto de caducar, y una página con mucha actividad hace varias peticiones a la vez. Actualízalas todas de forma ingenua y obtienes un pequeño desastre: varias actualizaciones simultáneas con un token de actualización rotatorio, cada una invalidando a las demás, terminando con el usuario desconectado por su propio tráfico.

Por eso la actualización es de vuelo único, por sesión. La primera petición que pasa toma una compuerta indexada por el id de sesión, y todas las demás esperan. La parte sutil es lo que hacen las que esperan cuando por fin entran: releen la sesión desde el almacén antes de decidir nada, porque la petición que sostuvo la compuerta primero muy probablemente ya ha actualizado, y el valor que sostenían al ponerse en cola está obsoleto. Actualiza una vez, y luego todos usan el resultado.

También es consciente de la rotación, en el sentido aburrido y necesario. Si el endpoint de tokens devuelve un nuevo token de actualización, este reemplaza al almacenado. Si la actualización falla con un error de token, la sesión se elimina y el usuario queda desconectado, porque un token de actualización que ha sido rechazado no va a ser aceptado en el siguiente intento, y reintentar no es más que una manera más lenta de quedar desconectado.

Un BFF, muchos inquilinos

Un BFF de un solo inquilino lo resuelve todo a partir de la configuración al arrancar: una autoridad, un id de cliente, un secreto. Servir a muchos inquilinos desde un mismo despliegue rompe eso, porque ahora el BFF tiene que averiguar a qué emisor pertenece un inicio de sesión, y tiene que hacerlo antes de que exista sesión alguna.

La selección ocurre en el endpoint de inicio de sesión, mediante un parámetro de consulta que tú decides cómo llamar, así que puede ser ?slug= o ?org= o como ya llame tu producto a un cliente. Un resolvedor convierte esa clave en una configuración de inquilino: autoridad, id de cliente, secreto, ámbitos. Si no resuelve a nada, el inicio de sesión se rechaza en el acto.

Luego la clave tiene que sobrevivir a un viaje de ida y vuelta hasta un proveedor de identidad que no sabe nada de ella, y regresar. Todavía no hay sesión que la conserve, así que viaja en la cookie de correlación, esa cookie cifrada de corta vida que ya lleva, por exactamente esta razón, el verificador PKCE, el estado y el nonce. Quince minutos, una por intento de inicio de sesión. A la vuelta la cookie se descifra, el inquilino se resuelve de nuevo a partir de la clave que contiene, y el código se intercambia contra el endpoint de tokens de ese inquilino. Solo entonces la clave de inquilino se escribe en la sesión, donde se convierte en la respuesta duradera.

A partir de ahí, cada ruta vuelve a resolver desde la sesión en vez de desde cualquier cosa que dijera el navegador: actualización, cierre de sesión, el proxy. Y cuando un inquilino deja de resolver, porque fue eliminado o deshabilitado, la sesión se destruye en lugar de recurrir en silencio a algún inquilino por defecto. Un inquilino irresoluble es un cierre de sesión, no un encogimiento de hombros.

La petición que llega sin cookie

El cierre de sesión back-channel es donde este diseño se gana el sueldo. El proveedor de identidad envía por POST un token de cierre de sesión directamente a tu servidor cuando una sesión termina en otro sitio. Sin cookie. Sin sesión. Sin navegador de por medio en absoluto. En un BFF de un solo inquilino esto no tiene nada de particular, ya que solo hay un emisor del que podría provenir. En uno multiinquilino tienes que responder «¿para qué inquilino es esto?» antes de poder responder «¿es siquiera auténtico?», y el único material disponible es el propio token, que no has verificado y por tanto no puedes confiar en él.

El orden que hace esto seguro merece enunciarse con precisión. Lee el claim de emisor del token no verificado y úsalo para exactamente una cosa: elegir qué configuración de inquilino cargar. Luego verifica la firma del token contra las claves publicadas de ese inquilino y su id de cliente como audiencia. Un emisor falsificado elige el inquilino que finge ser, y luego falla la verificación contra las claves de ese inquilino, porque el atacante no las tiene. Nunca se aceptó nada sobre la base del claim no confiable. El claim solo decidió quién puede juzgarlo, y el juez es un ancla de confianza que ya teníamos.

Después vienen las comprobaciones que hacen de un token de cierre de sesión un verdadero token de cierre de sesión: no debe llevar nonce, ya que no está autenticando a nadie; debe llevar el evento de cierre de sesión back-channel; y debe identificar o bien una sesión concreta, o bien un sujeto. Un id de sesión mata una sesión. Un sujeto mata todas las sesiones que tiene ese usuario, que es la forma que emitimos, porque «ciérrame la sesión en todas partes» es lo que la gente realmente quiere decir cuando pulsa cerrar sesión en todas partes. Por eso el almacén de sesiones mantiene un índice por id de sesión y otro por sujeto, en vez de solo por valor de cookie.

Un solo inquilino sigue siendo aburrido

Todo esto permanece inerte en el caso común. El resolvedor por defecto devuelve la misma configuración sin importar qué clave se le entregue, y su resolución por emisor devuelve esa configuración sin condiciones, porque solo hay una. Un BFF de un solo inquilino se comporta exactamente igual que antes de que la costura existiera: ningún parámetro de inquilino, nada extra en la cookie, ningún modo de fallo nuevo. La maquinaria multiinquilino es opcional e invisible hasta que nombras un parámetro de consulta.

Separa la selección de la confianza

Cuando conviertes algo en multiinquilino, el ejercicio que vale la pena hacer es enumerar cada punto de entrada y preguntar qué identifica al inquilino en cada uno. Las navegaciones del navegador llevan una cookie que tú emitiste y controlas. Las devoluciones de llamada de redirección llevan un estado que tú firmaste. Las devoluciones de llamada de servidor a servidor solo llevan lo que quien llama decidió enviar, y quien llama podría estar mintiendo.

El punto de entrada incómodo, el que no lleva nada digno de confianza, es aquel cuyo diseño decide si todo el sistema es sólido, y suele ser el que nadie tiene en cuenta hasta tarde. El patrón que nos sacó adelante se generaliza: separa la selección de la confianza. No hay problema en enrutar según datos no confiables mientras el enrutamiento solo elija qué ancla de confianza tiene permitido tomar la decisión final, y la decisión final la tome algo que el atacante no puede falsificar.

Si prefieres no escribir todo eso por tu cuenta, Authagonal incluye el BFF para .NET y para Node, y el portal aprovisionará el cliente confidencial que necesita, URI de redirección, endpoint de cierre de sesión back-channel y todo lo demás, en un solo clic.

We proved every alert could fire. Most of them couldn't.

authagonal — Fri, 31 Jul 2026 12:51:09 +0000

Monitoring has a property that makes it uniquely dangerous: it is the code that only runs during a disaster. Every other part of your system runs constantly, in front of users, throwing errors you notice. Your alerting runs the day the database fills up, and not before, and if it is broken you find out at the exact moment you were relying on it and in the exact way that guarantees nobody was watching. A silent alert is worse than no alert, because no alert you know you do not have, and a silent one you believe you do.

So we stopped trusting that our alerts worked because we had written them, and built a harness to prove it. For every alert rule we deploy, the harness drives a real signal that should trip it, and then it does the thing that actually matters: it waits for the notification to physically arrive in a capture relay, a small service standing in for the phone that would otherwise buzz. Firing in the monitoring tool's own UI does not count. Delivery counts. The full path from signal to a message in hand, or it is a failure.

The first real run failed most of the rules. Here is what was hiding behind green dashboards.

The flagship alert was dead

The most important rule we own is the one that fires when the error rate climbs: too many HTTP 500s, page somebody. The harness drove four hundred and fifty real server errors at it, verified that at least ninety percent of them genuinely returned 500, and waited. Nothing arrived. The single alert we would most want to trust had never once fired, and would not have fired in a real incident.

The cause was a name. Our metrics come out of OpenTelemetry, where names are dotted, like http.server.request.duration. Somewhere between reading a tutorial and writing the query, we had assumed the monitoring backend would normalise those dots to underscores, the way a lot of Prometheus tooling does, and written the alert query against the underscore form. The backend does not normalise. It keeps the dotted names exactly as sent. So the alert queried a metric that did not exist, matched nothing, computed an error rate of zero forever, and sat there calm and green while the real metric, under its real dotted name, recorded every one of those five hundreds. The query was not wrong in a way that errors. It was wrong in a way that silently returns the empty set, which arithmetic then turns into a perfectly plausible zero.

The one that took every log alert down with it

That was the bad one. The next one was worse, and the harness only caught it because it insists on delivery rather than on the rule looking correct.

A whole category of our alerts is log-based: match a line in the logs, fire. Every single one of them was evaluating against nothing, and the reason had nothing to do with the alert rules. It was a retention setting.

We reconcile our log retention through the backend's settings API. That API had moved to a new version with a new request shape, and we were still sending the old shape. The old body was not rejected. The decoder on the other end silently ignores fields it does not recognise, so it read our now-unknown fields as absent, took the default for the retention it could not find, and that default was zero. The call returned a cheerful 200. And a retention of zero days means instant expiry: newly written log data was being stamped to expire immediately, so the store the log alerts query was, for practical purposes, always empty. Ingestion looked completely healthy the whole time, because logs were arriving. They were just aging out the instant they landed.

Two systems each did something defensible. The settings API accepted a request it partly did not understand rather than failing, which is a common and often reasonable choice. Our deploy sent a body that had gone stale against a version bump. Neither raised anything. The result was that the single most consequential number in our log pipeline, how long a log lives, had been quietly set to zero, and the only visible symptom was every log alert being permanently, healthily silent. If we had been testing that the rules looked right, they looked perfect. Only testing that a real logged event produces a delivered page could surface it, because only that test actually reads back out of the store that had been emptied.

The alerts that fired forever, which is the same as never

A third failure ran in the opposite direction, and it is the subtle one. A handful of audit alerts were firing constantly. That sounds like the opposite of a silent alert, but it has the identical effect, and understanding why is worth the detour.

When one of these alerts fired, the monitoring backend wrote a log line about the evaluation, a breadcrumb, and that line contained the alert's own filter expression as text. That breadcrumb was itself ingested as a log, like anything else. So the next time the rule evaluated, it found a matching line: its own footprint from last time. The rule had become self-sustaining. It matched its own shadow, every evaluation, forever.

An alert that is always firing never transitions from not-firing to firing, and that transition is the thing that sends a notification. So the alerting layer, seeing a condition that was already true and stayed true, suppressed further notifications, exactly as designed, to spare you a page every minute about a thing you have already been told. The consequence is that a real event, a genuine audit action worth paging about, arrived into a rule that was already stuck on and therefore said nothing. An alert pinned permanently on is as mute as one pinned permanently off. The fix was to scope those rules to log lines emitted by our own services, so they stop matching the backend's chatter about themselves, with one deliberate exception whose real signal genuinely comes from outside our services.

The rule that treated a pod's first breath as normal

The last one is a small, sharp lesson about rate calculations. An alert built on the rate of change of a metric cannot compute a rate from a series' very first sample, because there is nothing before it to compare against. So when a fresh pod emitted its first burst of errors, that burst became the baseline rather than a spike, and the rule that should have caught it saw only a starting point. We fixed it in the harness by driving such signals in two waves, a small one to establish the series and a real one after it, which is also a fair description of what production traffic does on its own and what a synthetic test has to imitate deliberately.

Every failure hid in a seam you can only find by exercising it

Every one of these was invisible to inspection. The queries read correctly. The rules were deployed. The dashboards were green. Ingestion was healthy. Each failure lived in a seam between two things that were each individually fine: a metric name and an assumption about normalisation, a request body and a version bump, an alert and the log its own firing produces, a rate function and a series that has just begun. You cannot read a seam. You have to exercise it.

So treat monitoring like what it is, which is code, and specifically code whose only production run is the emergency. Code that only runs in the emergency needs its tests to run every other day, because there is no gentle first failure to warn you. Drive a real signal end to end, and assert on the artifact at the very end of the chain, the delivered notification, not on the rule looking healthy in the middle. Anything short of that is testing that you wrote an alert, which you already knew, rather than testing that it fires, which is the only thing you actually wanted.

If you would rather your identity provider was already watching itself this way, Authagonal runs its own alerting through exactly this harness, so the day something breaks, the page that should fire actually does.

Die SCIM-Steuer: Provisioning ist Infrastruktur, kein Premium-Feature

authagonal — Thu, 30 Jul 2026 01:39:09 +0000

SCIM ist das unglamouröseste Protokoll der Identity-Welt. Es ist eine REST-API für Benutzerdatensätze: anlegen, aktualisieren, deaktivieren, standardisiert als RFC 7644, damit Verzeichnisse und Anwendungen sie nur ein einziges Mal bauen müssen. Wenn das IT-Team Ihres Kunden sein Entra- oder Okta-Verzeichnis mit Ihrem Produkt verbindet, sorgt SCIM dafür, dass neue Mitarbeiter am ersten Tag in Ihrer App auftauchen und Abgänger an ihrem letzten Tag verschwinden. Es ist Infrastruktur im buchstäblichsten Sinn: läuft unbeaufsichtigt, bleibt unsichtbar und fällt erst auf, wenn sie fehlt.

Der übliche Preis für diese Infrastruktur ist bemerkenswert. WorkOS verlangt $125 im Monat pro Directory-Sync-Verbindung, zusätzlich zu den $125 im Monat pro SSO-Verbindung. Ein SaaS mit zehn Enterprise-Kunden, die jeweils das Standardpaar wollen, Login plus Provisioning, zahlt $2.500 im Monat, bevor sich auch nur einer ihrer Benutzer anmeldet. Auth0 spielt den anderen Klassiker: Der Free-Tarif enthält technisch gesehen eine Enterprise-Verbindung, aber die bezahlten Consumer-Tarife entfernen die Enterprise-Features wieder und lenken jeden, der sie wirklich braucht, auf B2B-Pläne, wo Verbindungen als Add-ons rund $100 pro Stück kosten. Egal in welcher Form, die Botschaft ist dieselbe: Provisioning lebt hinter dem Enterprise-Gatter, neben SAML, bepreist pro Verbindung.

Es lohnt sich also zu fragen, was eine SCIM-Verbindung den Anbieter im Betrieb kostet. Auf Anbieterseite ist eine Verbindung ein Bearer-Token und eine Basis-URL. Der Traffic ist ein Rinnsal: eine HTTP-Anfrage, wenn jemand anfängt, eine, wenn er das Team oder den Namen wechselt, eine, wenn er geht. Kein Fan-out, keine nennenswerte Rechenlast, keine Storage-Geschichte. Die Spezifikation existiert genau deshalb, damit die Implementierung eine einmalige Investition ist: Wer /Users und /Groups mit PATCH-Semantik einmal gebaut hat, für den kostet Verbindung Nummer zweihundert exakt dasselbe wie Verbindung Nummer zwei, nämlich eine Zeile in einer Tabelle. $125 im Monat pro Verbindung ist keine Kostendeckung. Es ist ein Segmentierungszaun, aufgestellt dort, wo die Enterprise-Käufer stehen, weil Enterprise-Käufer zahlen können. Wir haben diese Rechnung für SSO bereits in Dollar aufgemacht; SCIM ist dieselbe Steuer, kassiert an einer zweiten Mautstelle.

Aber SCIM ist nicht SSO, und der Unterschied liegt darin, was passiert, wenn man nicht zahlt. Wer die SSO-Gebühr ablehnt, bekommt schlechtere Logins: mehr Passwörter, mehr Phishing-Angriffsfläche, eine genervte IT-Abteilung. Lästig, aber überlebbar. Wer die SCIM-Gebühr ablehnt, bei dem bricht das Offboarding. Die wichtigste Nachricht, die SCIM je überbringt, ist die, die sagt: Diese Person hat das Unternehmen verlassen, deaktiviert sie überall, sofort. Ohne sie besteht Deprovisioning darin, dass ein Mensch daran denken muss, sich am Tag, an dem jemand hinausbegleitet wird, durch die Admin-Konsole jedes einzelnen SaaS-Produkts der Firma zu klicken, ohne einen Schritt zu vergessen. In der Praxis heißt das: Ehemalige behalten tagelang funktionierende Konten, manchmal monatelang. Auditoren fragen in jedem SOC-2- und ISO-27001-Review aus gutem Grund nach zeitnahem Deprovisioning: Das schlafende Konto eines ausgeschiedenen Mitarbeiters, Passwort unverändert, ist eines der ältesten Einfallstore für Sicherheitsvorfälle überhaupt.

Deprovisioning ist also kein Komfort-Feature. Es ist eine Sicherheitskontrolle, und eine Gebühr pro Verbindung auf SCIM ist ein Preisschild auf dieser Kontrolle. Und man beachte, wohin das Risiko wandert, wenn ein Käufer die Gebühr ablehnt: nirgendwohin auf Anbieterseite. Der Anbieter liefert exakt dasselbe Produkt. Die Lücke öffnet sich beim Kunden, in der Offboarding-Checkliste, die jetzt von Gedächtnis statt von Automatisierung abhängt. Für SCIM Geld zu verlangen heißt, Geld für das Schloss an einer Tür zu verlangen, die man bereits verkauft hat.

Es gibt eine einfache Art, die Preisliste jedes Anbieters zu lesen: Was echtes Geld im Betrieb kostet, wird nach Nutzung bepreist, und was nichts kostet, wird danach bepreist, was man ablehnen kann. Preise pro Benutzer oder pro MAU folgen den tatsächlichen Kosten. Eine Gebühr pro Verbindung auf ein standardisiertes Protokoll folgt dem Hebel, und SCIM trägt den größten Hebel von allen, weil Enterprise-Sicherheitsfragebögen es vorschreiben. Der Käufer kann nicht Nein sagen, und der Preis ist entsprechend gesetzt. Das ist die SCIM-Steuer: keine Gebühr für eine Leistung, sondern ein Wegezoll auf eine Compliance-Anforderung.

Wir halten die Mautstelle für das falsche Geschäftsmodell. Authagonal enthält SCIM in jedem Tarif, den Free-Tarif eingeschlossen, mit unbegrenzten Verbindungen, genau wie SSO. Provisioning ist Infrastruktur. Wir berechnen das, was uns tatsächlich etwas kostet, nämlich aktive Benutzer, und der Schalter, der das Konto eines Abgängers überall abschaltet, ist kein Premium. Er ist der Job.

La taxe SCIM : le provisionnement, c'est de la plomberie, pas du premium

authagonal — Thu, 30 Jul 2026 01:39:05 +0000

SCIM est le protocole le moins glamour de l'identité. C'est une API REST pour les fiches utilisateurs : créer, mettre à jour, désactiver, standardisée sous le nom de RFC 7644 pour que les annuaires et les applications n'aient à la construire qu'une seule fois. Quand l'équipe IT de votre client connecte son annuaire Entra ou Okta à votre produit, c'est SCIM qui fait apparaître les nouvelles recrues dans votre application dès le premier jour et disparaître les partants le jour de leur départ. C'est de la plomberie au sens le plus littéral : sans surveillance, invisible, et remarquée seulement quand elle manque.

Le tarif en vigueur pour cette plomberie est remarquable. WorkOS facture 125 $ par mois et par connexion Directory Sync, en plus des 125 $ par mois facturés par connexion SSO. Un SaaS avec dix clients entreprise qui veulent chacun la paire standard, connexion plus provisionnement, paie 2 500 $ par mois avant même qu'un seul de leurs utilisateurs ne se connecte. Auth0 joue l'autre grand classique : l'offre gratuite inclut techniquement une connexion entreprise, mais les offres grand public payantes retirent les fonctionnalités entreprise, poussant quiconque en a réellement besoin vers des plans B2B où les connexions sont des options à environ 100 $ pièce. Quelle que soit la forme, le message est le même : le provisionnement vit derrière la barrière entreprise, à côté de SAML, facturé à la connexion.

Il vaut donc la peine de se demander ce qu'une connexion SCIM coûte au fournisseur. Côté fournisseur, une connexion, c'est un jeton bearer et une URL de base. Le trafic est un filet d'eau : une requête HTTP quand quelqu'un arrive, une quand il change d'équipe ou de nom, une quand il part. Pas de fan-out, pas de calcul digne d'être mentionné, pas d'enjeu de stockage. La spécification existe précisément pour que l'implémentation soit un coût unique : une fois que vous avez construit /Users et /Groups avec la sémantique PATCH, la connexion numéro deux cents coûte exactement ce qu'a coûté la connexion numéro deux, c'est-à-dire une ligne dans une table. 125 $ par mois et par connexion, ce n'est pas de la couverture de coûts. C'est une clôture de segmentation, placée là où se tiennent les acheteurs entreprise parce que les acheteurs entreprise peuvent payer. Nous avons déjà chiffré cette facture en dollars pour le SSO ; SCIM est la même taxe, collectée à un deuxième péage.

Mais SCIM n'est pas SSO, et la différence, c'est ce qui se passe quand vous ne payez pas. Refusez les frais SSO et les connexions se dégradent : plus de mots de passe, plus de surface de phishing, un service informatique agacé. Gênant, mais survivable. Refusez les frais SCIM et l'offboarding casse. Le message le plus important que SCIM transporte est celui qui dit : cette personne a quitté l'entreprise, désactivez-la partout, maintenant. Sans lui, le déprovisionnement, c'est un humain qui doit penser à cliquer dans la console d'administration de chaque produit SaaS utilisé par l'entreprise, le jour où quelqu'un est raccompagné à la porte, sans oublier une seule étape. En pratique, cela veut dire que des ex-salariés gardent des comptes actifs pendant des jours, parfois des mois. Si les auditeurs posent la question du déprovisionnement rapide dans chaque revue SOC 2 et ISO 27001, ce n'est pas pour rien : le compte dormant d'un salarié parti, mot de passe inchangé, est l'un des plus vieux points d'entrée de compromission qui soient.

Ce qui veut dire que le déprovisionnement n'est pas une fonctionnalité de confort. C'est un contrôle de sécurité, et des frais par connexion sur SCIM, c'est une étiquette de prix sur ce contrôle. Regardez où va le risque quand un acheteur refuse de payer : nulle part côté fournisseur. Le fournisseur sert exactement le même produit. Le trou s'ouvre côté client, dans la checklist d'offboarding qui dépend désormais de la mémoire au lieu de l'automatisation. Faire payer SCIM, c'est faire payer le verrou d'une porte que vous avez déjà vendue.

Il existe une façon simple de lire la grille tarifaire de n'importe quel fournisseur : ce qui coûte vraiment de l'argent à servir est facturé à l'usage, et ce qui ne coûte rien est facturé selon ce que vous pouvez refuser. La tarification par utilisateur ou par MAU suit le coût réel. Des frais par connexion sur un protocole standardisé suivent le rapport de force, et SCIM porte le plus grand rapport de force de tous, parce que les questionnaires de sécurité des entreprises l'exigent. L'acheteur ne peut pas dire non, et le prix est fixé en conséquence. C'est ça, la taxe SCIM : pas le prix d'un service, mais un péage sur une exigence de conformité.

Nous pensons que le péage n'est pas le bon métier. Authagonal inclut SCIM dans chaque offre, y compris l'offre gratuite, avec des connexions illimitées, comme pour le SSO. Le provisionnement, c'est de la plomberie. Nous facturons ce qui nous coûte réellement quelque chose, à savoir les utilisateurs actifs, et l'interrupteur qui désactive partout le compte d'un partant n'est pas du premium. C'est le travail.

We moved our images to a CDN and the origin kept serving them

authagonal — Thu, 30 Jul 2026 01:24:51 +0000

Our documentation is heavy with screenshots. Every portal feature, captured in light and dark, at two widths, across ten locales, which adds up to something north of a hundred megabytes of images. All of it was sitting in the app's own static bundle, served from the origin, which is the wrong place for a hundred megabytes of pictures that never change. So we moved it to Cloudflare R2 and put a CDN in front, one per environment: cdn.authagonal.io for production and a matching CDN host for our dev site.

The app picks the right CDN host at runtime by looking at the hostname it is being served from. If the page is on authagonal.io, images come from cdn.authagonal.io. Simple, no build-time configuration, one image reference that resolves correctly on either environment. We shipped it, watched the browser pull every image cleanly from the CDN, and then looked at the origin's traffic. The origin was still serving the images. Every one, on first load, exactly as before.

The page a crawler sees is not the page a browser builds

To explain why, I have to explain what our marketing pages actually are. They are a single-page app, but a single-page app is a blank shell until JavaScript runs, and a blank shell is bad for search engines and bad for the time it takes the first meaningful thing to appear. So at build time we prerender: we start the site, open each page in a headless browser, let it render fully, and save the resulting HTML. That prerendered HTML is what we serve first. It already has the content in it, the crawler sees a real page, the user sees text and images immediately, and then the JavaScript takes over.

Here is the problem hiding in that description. The prerender runs the site on 127.0.0.1, a loopback address on the build machine. So when the app asks "what hostname am I on, so I can pick a CDN," the answer during prerender is "a local IP address," which matches neither authagonal.io nor the dev host. The runtime host-derivation, the clever part, quietly falls through to its only remaining option: the origin-relative path. And that origin path is what gets frozen into the prerendered HTML.

So every visitor received HTML with origin image URLs baked in, and the browser did the obvious thing: it fetched them, from the origin, on first paint. A moment later the JavaScript re-rendered the page, re-derived the hostname, this time getting the real one, and swapped the images to the CDN. Two fetches for every image, the first one hitting exactly the server we were trying to spare, and completely invisible unless you were watching the origin's logs, because the page looked and worked perfectly.

The fix that made things worse for eleven minutes

The first fix was the tempting one. If the problem is that a wrong URL gets frozen into the prerendered HTML, then emit no URL during prerender at all. Leave the image source blank in the snapshot, and let the JavaScript fill in the correct CDN URL once it runs and knows the real hostname. No wrong URL, no origin fetch.

It shipped, and it was wrong, and we replaced it about eleven minutes later. Blanking the image source in the prerendered HTML defeats the entire reason we prerender. The crawler that reads the static page now sees no image, and the browser has nothing to show until JavaScript has run, which is the slow path we build the prerendered HTML specifically to avoid. We had removed the double fetch by removing the image from the one version of the page that exists before JavaScript. That trades a traffic problem for a search-and-first-paint problem, which is a worse trade.

The lesson from those eleven minutes: the prerendered HTML has to carry a real, working image reference. The bug was never that a URL was present. It was that the wrong URL was present, and blanking it just swaps one defect for another. What we actually needed was for the correct URL to be knowable at prerender time, and it is not, because at prerender time nobody knows which environment will serve the page.

Deciding at the last possible moment

The correct URL depends on the request host, and the request host is not known until there is a request. Prerender happens once, at build, and produces one file that is served on both environments. So the environment-specific part of the URL cannot be decided at build. It has to be decided per request, and the only thing in the stack that sees every request and its host is the web server at the edge.

So the prerender no longer writes a URL or a blank. It writes a placeholder, a literal sentinel string, __ASSET_CDN__, in place of the CDN host. The prerendered HTML that leaves the build says __ASSET_CDN__/screenshots/whatever.webp, which is neither an origin URL nor an empty source. It is a URL with a hole in it.

nginx fills the hole on the way out. It maps the request's host to the right CDN base, the non-production host to its own dev CDN, authagonal.io to https://cdn.authagonal.io, anything else to empty so the URL collapses back to origin-relative as a safe local fallback. Then a single directive rewrites the sentinel to that value as the HTML streams to the client:

map $host $asset_cdn_base {
    default              "";
    "~*example\.dev$"    "https://cdn.example.dev";
    "~*authagonal\.io$"  "https://cdn.authagonal.io";
}

sub_filter '__ASSET_CDN__' $asset_cdn_base;

The static HTML now leaves the origin already carrying real CDN URLs, correct for whichever host asked. The browser fetches straight from the CDN on first paint. There is no wrong first fetch to undo, because there is no wrong URL, and there was never a blank one either. The crawler sees a complete page with real image links. One file serves both environments, and neither one needs a separate build.

There is a small elegance to which parts of the response get rewritten. The rewrite is scoped to HTML only, which is nginx's default. That matters because the same sentinel string appears in the JavaScript bundle too, as the fallback branch of the host-derivation code. On the client that branch is dead code, since the browser has a real hostname and never emits the sentinel, so we specifically do not want nginx touching the bundle. Leaving the rewrite at its HTML-only default gets that for free. We learned, incidentally, that writing the default out explicitly is worse than leaving it off, because a redundant declaration makes nginx warn about a duplicate.

Why not just rewrite the file once on startup

The obvious objection is that this is a lot of per-request work for a value that only has two possibilities. Why not rewrite the HTML once when the container boots, bake in the right host, and serve a static file with no filter?

Because the container cannot write to itself. The static site runs in nginx as a non-root user with a read-only root filesystem and every Linux capability dropped, with a single small writable scratch directory for nginx's own temp files. That is a deliberate hardening posture: a web server that serves untrusted traffic should not be able to modify the files it serves, so that an attacker who finds a foothold finds nothing to rewrite. A boot-time rewrite of the HTML would need exactly the write access we took away on purpose. The read-only filesystem is not an obstacle to work around, it is a property we want, and it rules out the boot-time rewrite cleanly. The per-request rewrite touches no files at all, which is why it is compatible with a server that owns nothing it can change.

We also did not want to bake the CDN host in at build and produce two different image bundles, one per environment, because that reintroduces the environment-specific build we had just gotten rid of. The point of host-derivation was one artifact for both environments. The sentinel keeps that promise: one build, one file, the environment resolved at the edge at the last possible moment.

Prerendering freezes environment values, so resolve them at the edge

Prerendering freezes a moment. Anything your app decides by looking at its environment gets decided, at prerender time, against the build's environment, which is a loopback address and nobody's real host. So a value that is correct at runtime becomes wrong the instant it is snapshotted, and it fails silently, because the prerendered page still renders, just pointing at the wrong place.

The general fix is to not resolve environment-specific values during prerender at all. Emit a placeholder, carry it through the static artifact intact, and resolve it at the layer that actually sees the environment, which for a per-request value is the edge. It is late binding, applied to a string in an HTML file: leave the hole open through every stage that does not know the answer, and fill it at the one stage that does.

If you would rather your identity provider's own documentation and assets were already served correctly off the edge, that is one of the many small things Authagonal has already argued out so you can spend the argument on your own product instead.

A BFF for many tenants, and the one request that arrives with no cookie

authagonal — Tue, 28 Jul 2026 10:05:53 +0000

Single-page apps were taught to hold their own tokens. The app runs the OAuth flow in the browser, gets an access token and usually a refresh token back, keeps them somewhere in JavaScript, and attaches them to every API call. It is well documented, it is what most tutorials show, and it puts your longest-lived credential in the one place you cannot defend: a runtime that will cheerfully execute anything that finds its way onto the page. One successful injection, one compromised dependency somewhere in your build, and nobody needs to phish anybody. They read the token and leave, and it keeps working until it expires.

The backend-for-frontend pattern moves the credential out of reach. The browser talks to a small server that belongs to your app, and that server is the confidential OAuth client. It runs the code exchange, it holds the access and refresh tokens, and it hands the browser nothing but an opaque cookie. This is a description of how we built ours, and of the one part that turned out to be genuinely interesting: making it serve more than one tenant.

What the browser ends up with

A cookie called __Host-agbff, marked HttpOnly, SameSite=Lax, scoped to the whole path, with no expiry so it dies with the browser session. Its value is 256 bits of randomness and nothing else. It is not a token, it does not decode into anything, and stealing it off the wire is not a thing you can do to a __Host- cookie over TLS.

Everything real sits server-side, in a session record in a distributed cache: the access token, the refresh token, the id token, when the access token expires, and which tenant the session belongs to. The login itself is an ordinary authorization code flow with PKCE, run by a confidential client that authenticates to the token endpoint with its secret. The id token is validated properly on the way back in, issuer, audience, signature against the published keys, lifetime, and then a constant-time comparison of the nonce against the value stashed before the redirect. Only after all of that does a session exist and a cookie get set.

A header that is checked for existence, and nothing else

The browser calls the BFF for its own user info and to reach the proxied API, and those calls carry a custom header, x-authagonal-bff. Its value is irrelevant. Presence is the whole check.

That looks lazy and is not. The entire class of cross-site request forgery relies on a form post, an image tag, or a navigation that another origin can trigger while your cookie rides along, and none of those can set a custom header. The moment attacking JavaScript tries to add one it stops being a simple request and becomes a preflighted one, which your CORS policy declines. The header is not a secret to be guessed, it is proof that the request came from code rather than from markup.

It is required on the scripted calls and deliberately not on the ones that are top-level navigations by nature: starting a login, coming back from the identity provider, following a logout link. Demanding a custom header on a browser navigation would just break the navigation.

Refresh, exactly once

Every proxied request may discover that the access token is about to expire, and a busy page makes several requests at once. Refresh them all naively and you get a small disaster: several concurrent refreshes with a rotating refresh token, each one invalidating the others, ending with the user logged out by their own traffic.

So refresh is single-flight, per session. The first request through takes a gate keyed by the session id and everyone else waits. The subtle part is what the waiters do when they get in: they re-read the session from the store before deciding anything, because the request that held the gate first has very likely already refreshed, and the value they were holding when they queued is stale. Refresh once, then everybody uses the result.

It is also rotation-aware in the boring, necessary sense. If the token endpoint hands back a new refresh token, it replaces the stored one. If refresh fails with a token error, the session is deleted and the user is logged out, because a refresh token that has been rejected is not going to be accepted on the next attempt, and retrying is just a slower way to be logged out.

One BFF, many tenants

A single-tenant BFF resolves everything from configuration at startup: one authority, one client id, one secret. Serving many tenants from one deployment breaks that, because now the BFF has to work out which issuer a login belongs to, and it has to do so before any session exists.

Selection happens at the login endpoint, through a query parameter you get to name, so it can be ?slug= or ?org= or whatever your product already calls a customer. A resolver turns that key into a tenant config: authority, client id, secret, scopes. If it resolves to nothing, the login is refused there and then.

Then the key has to survive a round trip to an identity provider that knows nothing about it, and come back. There is no session yet to hold it, so it rides in the correlation cookie, the short-lived encrypted cookie that already carries the PKCE verifier, the state, and the nonce for exactly this reason. Fifteen minutes, one per login attempt. On the way back the cookie is decrypted, the tenant is resolved again from the key inside it, and the code is exchanged against that tenant's token endpoint. Only then is the tenant key written into the session, where it becomes the durable answer.

From that point every path re-resolves from the session rather than from anything the browser said: refresh, logout, the proxy. And when a tenant stops resolving, because it was deleted or disabled, the session is destroyed rather than quietly falling back to some default tenant. An unresolvable tenant is a logout, not a shrug.

The request that arrives with no cookie

Back-channel logout is where this design earns its keep. The identity provider POSTs a logout token straight to your server when a session ends elsewhere. No cookie. No session. No browser involved at all. In a single-tenant BFF that is unremarkable, since there is only one issuer it could be from. In a multi-tenant one you have to answer "which tenant is this for?" before you can answer "is this even real?", and the only material available is the token itself, which you have not verified and therefore cannot trust.

The ordering that makes this safe is worth stating precisely. Read the issuer claim out of the unverified token, and use it for exactly one thing: choosing which tenant's configuration to load. Then verify the token's signature against that tenant's published keys and its client id as the audience. A forged issuer picks the tenant it is pretending to be, and then fails verification against that tenant's keys, because the attacker does not have them. Nothing was ever accepted on the strength of the untrusted claim. The claim only decided who gets to judge it, and the judge is a trust anchor we already had.

After that come the checks that make a logout token a logout token: it must not carry a nonce, since it is not authenticating anybody; it must carry the back-channel logout event; and it must identify either a specific session or a subject. A session id kills one session. A subject kills every session that user has, which is the form we emit, because "log me out everywhere" is what people actually mean when they click log out everywhere. That is why the session store keeps an index by session id and another by subject, rather than only by cookie value.

Single tenant stays boring

All of this is inert for the common case. The default resolver returns the same configuration no matter what key it is handed, and its resolve-by-issuer returns that configuration unconditionally, because there is only one. A single-tenant BFF behaves exactly as it did before the seam existed: no tenant parameter, nothing extra in the cookie, no new failure modes. The multi-tenant machinery is opt-in and invisible until you name a query parameter.

Separate selection from trust

When you make something multi-tenant, the exercise worth doing is to enumerate every entry point and ask what identifies the tenant on each one. Browser navigations carry a cookie you issued and control. Redirect callbacks carry state you signed. Server-to-server callbacks carry only what the caller chose to send, and the caller might be lying.

The awkward entry point, the one with nothing trustworthy on it, is the one whose design decides whether the whole system is sound, and it is usually the one nobody thinks about until late. The pattern that got us through it generalises: separate selection from trust. It is fine to route on untrusted data as long as routing only chooses which trust anchor is allowed to make the final call, and the final call is made by something the attacker cannot forge.

If you would rather not write all of that yourself, Authagonal ships the BFF for .NET and for Node, and the portal will provision the confidential client it needs, redirect URI, back-channel logout endpoint and all, in one click.

Votre sauvegarde ressuscite en silence les utilisateurs que vous avez supprimés

authagonal — Mon, 27 Jul 2026 03:48:22 +0000

Toute sauvegarde incrémentale repose sur la même hypothèse silencieuse : pour sauvegarder ce qui a changé, il faut trouver les lignes qui ont changé. Sur un magasin clé-valeur comme Azure Table Storage ou DynamoDB, « ce qui a changé » signifie « les lignes dont l'horodatage de dernière modification est plus récent que mon dernier repère ». On parcourt la table, on prend tout ce qui est plus récent, on l'écrit. Rapide, pas cher, correct.

Correct pour les écritures. Maintenant, supprimez une ligne.

La ligne ne reçoit pas d'indicateur « supprimé ». Elle ne reçoit pas d'horodatage plus récent. Elle ne part pas dans une corbeille. Elle cesse simplement d'exister. Ces magasins n'ont ni marqueurs de suppression ni flux de changements pour les suppressions, donc une ligne supprimée ne laisse derrière elle exactement rien. Votre sauvegarde incrémentale, qui repère les changements en cherchant des horodatages plus récents, passe tout droit devant l'espace vide où la ligne se trouvait et ne trouve rien. Il n'y a rien à trouver. La suppression est invisible.

Ce qui veut dire que votre sauvegarde contient toujours la ligne. Et c'est là qu'une histoire de perte de données devient une histoire de sécurité.

Pensez à ce qu'une suppression signifie généralement dans un système d'authentification. Vous n'avez pas supprimé cet utilisateur pour le plaisir. Vous avez supprimé le compte d'un salarié qui partait. Vous avez retiré un compte dont le mot de passe est apparu dans un dump de fuite. Vous avez révoqué un octroi OAuth après la fuite d'un jeton. Vous avez retiré les accès d'un administrateur le jour de son départ. Chacune de ces actions est une décision de sécurité, et aucune ne survit à une sauvegarde qui ne voit pas les suppressions.

Alors vous restaurez. Peut-être après un vrai sinistre, peut-être juste vers un clone de staging. La sauvegarde fait exactement ce que vous lui avez demandé : elle remet chaque ligne qu'elle connaît. Le salarié parti est de nouveau un utilisateur. Le mot de passe compromis est de nouveau valide. L'octroi révoqué fonctionne de nouveau. L'administrateur écarté est de nouveau administrateur. Votre restauration n'a pas perdu de données. Elle a annulé vos décisions de sécurité, en silence, et vous a rendu un système qui a l'air sain et qui est discrètement compromis. Une sauvegarde qui oublie une suppression est pire que pas de sauvegarde du tout, parce que vous lui faites confiance.

La solution, c'est d'arrêter de traiter une suppression comme l'absence d'une ligne et de commencer à la traiter comme un événement. Les suppressions sont des données.

Nous donnons donc aux suppressions leur propre table. Chaque suppression du système passe par un ITombstoneWriter injecté qui enregistre un tombstone, une pierre tombale : la clé, et l'heure de la mort. Il n'existe aucun chemin de code qui supprime une ligne sans laisser de tombstone, parce que la suppression et le tombstone sont une seule opération. Une sauvegarde incrémentale devient alors deux parties capturées à un même repère : les upserts (les lignes à l'horodatage plus récent) et les tombstones (les suppressions depuis le dernier repère). La restauration rejoue les deux dans l'ordre chronologique, si bien qu'une suppression s'applique exactement comme une écriture, et qu'une clé supprimée puis recréée se résout à ce qui est arrivé en dernier. L'espace vide a enfin un enregistrement qui lui est attaché.

Voilà toute l'astuce, et elle est petite. La raison pour laquelle elle compte ne l'est pas.

Le schéma dépasse Table Storage et DynamoDB. Tout système qui modélise une suppression comme « la ligne n'est plus là » ne peut ni sauvegarder, ni répliquer, ni synchroniser les suppressions, parce qu'il n'y a rien à transporter. On le retrouve dans les replays d'événements naïfs qui ne rejouent que les créations et les mises à jour. On le retrouve dans les caches qui expirent mais ne s'invalident jamais. On le retrouve dans les réplicas de lecture qui dérivent parce que la suppression ne s'est jamais propagée. Et il est le plus dangereux exactement là où les suppressions sont votre moyen d'appliquer la sécurité, c'est-à-dire partout dans un système d'identité : révocation, offboarding, rotation, verrouillage. Si votre stratégie de durabilité ne suit que ce qui existe, elle préservera fidèlement ce que vous vous êtes donné du mal à faire disparaître.

Auditez donc vos propres sauvegardes avec une seule question : si je supprime un utilisateur maintenant, que je prends une sauvegarde et que je la restaure, cet utilisateur a-t-il disparu ? Si la réponse honnête est « je n'en suis pas sûr », votre sauvegarde est une machine à remonter le temps pointée dans le mauvais sens. Elle ne vous protège pas de vos erreurs. Elle les ressuscite : le mot de passe remplacé, le salarié parti, le jeton révoqué.

Les suppressions sont des données. Sauvegardez-les comme telles.

Si vous préférez que vos sauvegardes respectent une suppression sans avoir à le prouver vous-même, c'est à ça que sert une plateforme. Authagonal pose un tombstone sur chaque suppression, si bien qu'une restauration ne ramène jamais un identifiant révoqué.

The admission webhook that said yes and took us down anyway

authagonal — Mon, 27 Jul 2026 00:52:16 +0000

We run an auth service, so the question "is the container that just started actually the container we built?" is not academic. Our answer was signatures: sign every image in CI, verify before deploy, and then, as a second layer, put a webhook in the cluster so that even a hand-typed kubectl could not run something unsigned. That went in on a Tuesday afternoon. By evening our auth Deployment on the dev cluster had accumulated 2,242 ReplicaSets, was minting a new one roughly every three seconds, reported Available=False, and served nothing.

The obvious hypothesis is that the new webhook was rejecting our images. It was not. Its logs, for every request, said allowed: true. It admitted everything we sent it, all evening, while the Deployment it was admitting fell apart.

The layer we were adding

The pipeline already signed and verified. Every image gets a keyless signature at build time, tied to the GitHub Actions OIDC identity, and the deploy job runs a verification against that identity before anything reaches the cluster. That gate is fail-closed and it is the real control.

The cluster-side layer is defence in depth: sigstore's policy-controller, running as an admission webhook, holding two policies. One says images matching our own registry path must carry a keyless signature from our workflow identity. The other is a catch-all that lets everything else pass, because "no policy matched" means deny, and without the catch-all the cluster loses its Vault agents, its CSI drivers, and every sidecar it did not build. Install, label the namespace, done. The label is the switch: no label, no enforcement.

The first outage, which was boring

Turning it on with failurePolicy: Fail and the chart's default ten second timeout took dev down almost immediately, in the way everyone expects an admission webhook to take you down. A cold controller has to reach Fulcio and Rekor to verify a signature it has not seen before. Cold, that work does not finish in ten seconds. Fail-closed plus a blown deadline means pod creation is refused, which means the rollout cannot place pods, which means the service has no replicas.

That failure mode is well documented and the fix is the documented one: raise the webhook timeout to thirty seconds and set failurePolicy: Ignore. Ignore sounds like giving up, and in a single-layer design it would be. In ours the pipeline gate is the fail-closed primary, and the cluster layer exists to catch what never went through the pipeline at all. A webhook that can never take the cluster down is worth more to us than a webhook that catches the last one percent, because the last one percent has already been caught upstream.

We shipped that at 17:40. It fixed the first outage completely. It also created the second one, and this is the part worth reading.

Mutating, not just validating

Everyone thinks of an admission webhook as a bouncer: it inspects the object and returns yes or no. Policy-controller is not only that. It is a mutating webhook, and what it mutates is the thing it just verified. When it admits a pod spec that references an image by tag, it rewrites that reference to include the digest it resolved and checked. myregistry.io/authagonal-auth:abc123 goes in. myregistry.io/authagonal-auth:abc123@sha256:... comes out.

That is a genuinely good idea. A tag is a mutable pointer, so verifying a tag and then letting the kubelet resolve it again later leaves a window where the two could differ. Pinning the digest at admission time closes it. The object that runs is the object that was verified.

Now put that next to how a Deployment works. The Deployment controller hashes your pod template, and that hash is what identifies the ReplicaSet that owns the pods. It hashes the template you declared. The webhook rewrites the template on the ReplicaSet it admits. So if your Deployment's template says :abc123, its own child ReplicaSet says :abc123@sha256:..., and the two no longer agree.

The controller reconciles, hashes the template, looks for a ReplicaSet with that hash, and finds one whose template is different. There is exactly one thing that means in Kubernetes: a hash collision, two different templates landing on the same hash. The controller handles collisions the way it is supposed to. It increments collisionCount, which perturbs the hash, and creates a new ReplicaSet. Three seconds later it reconciles again, and the new ReplicaSet has been mutated too. The loop does not converge, because the disagreement it is trying to resolve is being recreated by the webhook every time it tries.

Two thousand two hundred and forty-two ReplicaSets is what an infinite loop looks like when you catch it in the evening rather than the morning.

Why only one Deployment broke

Four workloads run in that namespace. One spiralled. Three were completely fine, which is the detail that kept us looking in the wrong place, because a systemic misconfiguration should not be selective.

failurePolicy: Ignore is why. When the webhook is slow or cold and a request times out, Ignore means the object is admitted unmutated. Whether a given apply came back with a digest baked in or with the bare tag it went in with depended on whether the webhook answered in time. The three healthy Deployments had been applied while it was warm, so their templates already carried digests, and the webhook's rewrite was a no-op that matched what was already there. The one that spiralled had been applied while the webhook was cold, kept its bare tag in the template, and then had every child ReplicaSet mutated out from under it.

So the trigger was a race, decided per apply, that any of the four could have lost on any deploy. Ignore did not cause the bug. It turned a deterministic bug into an intermittent one and hid it behind three healthy workloads.

The fix is a fixed point

The instinct is to stop the webhook from mutating. Better instinct: give it nothing to mutate. If the pod template we submit is already exactly what the webhook would produce, the rewrite changes nothing, the hash stays stable, and the loop cannot start.

So the deploy job now resolves the digest itself before applying. For each image it asks the registry what the tag currently points at, then writes the fully pinned reference into the overlay:

digest=$(az acr repository show --name "$acr" \
  --image "authagonal-${img}:${tag}" --query digest -o tsv)
kustomize edit set image "${ref}=${ref}:${tag}@${digest}"

What ships is :tag@sha256:..., tag and digest together. The tag stays for human readability, the digest is what actually resolves. The webhook verifies it, finds nothing to rewrite, and returns the object unchanged. collisionCount has been flat ever since.

There is a small trap in the tail of this. Because CI is what writes the digest, applying the overlay by hand from a laptop sends the base manifests' placeholder tag instead, and the policy now correctly refuses it with "must be an image digest." The cluster is telling you the truth: that thing you just typed was never verified.

A mutating webhook is a second writer, not a checkpoint

A mutating admission webhook is not a checkpoint. It is a writer inside a control loop that is already comparing what you asked for against what exists. Two writers with different opinions about the same field is not a policy question, it is a distributed systems question, and the one thing that makes it safe is idempotence: the state you declare has to be a fixed point of the mutation, so that applying the mutation to it produces it again.

That reframing generalises past sigstore. Anything that rewrites your specs at admission time, whether it injects sidecars, adds default resource limits, or normalises image references, is in the same position, and the same question applies. If you ran your own manifest through this thing, would you get your own manifest back? If not, something is going to keep noticing the difference. It will be patient, and it will be much faster than you.

And the smaller lesson, the one we actually had to unlearn on the night: allowed: true does not mean the webhook is not the problem. We spent an hour treating those logs as an alibi. The webhook was telling the truth the whole time. We were asking it the wrong question, because we had only ever thought of it as something that says no.

If you would rather your identity provider came with its supply chain already argued out, Authagonal is a hosted auth service whose images are signed in CI, verified before deploy, and pinned by digest at the point of admission, which is a sentence we can write because we already lost an evening earning it.

We turned off a dangerous default without migrating a single row

authagonal — Fri, 24 Jul 2026 09:48:15 +0000

Just-in-time provisioning is the feature that makes enterprise SSO feel like magic. A new employee signs in through their company's identity provider, no account exists for them in your app yet, and one is created on the spot from the assertion. Nobody files a ticket, nobody gets invited, the person just works.

It is also, read from the other direction, a feature that lets whoever controls that identity provider create accounts in your customer's tenant by asserting that a person exists. That is fine when the connection is scoped tightly to one company's directory and every human in it should have access. It is less fine when the connection is a shared directory, or a contractor tenant, or one of those sprawling federations where the set of people the identity provider is willing to vouch for is much larger than the set of people your customer meant to let in.

Ours defaulted to on. Not because anybody decided it should, which is the part worth dwelling on. It defaulted to on because when the field was added, the boolean that expressed it was called DisableJitProvisioning, and an unset boolean is false, and false meant "do not disable." The safest reading of a default nobody chose is that it is an accident, and this one had settled in as behaviour.

To be precise about the exposure, because it was never as bad as "anyone can create anyone": two gates already ran before provisioning. A connection can carry a list of allowed email domains, and an assertion outside them is rejected. A connection can require an invitation attribute, and an uninvited user is rejected. The real default-on risk was a connection with neither of those configured, which is exactly the shape of a connection somebody set up quickly to get SSO working.

Flipping the default is one word. Flipping it safely is not.

The change everyone imagines is renaming the field to JitProvisioningEnabled and letting it default to false. New connections are secure by default, done.

Except that field is persisted, and there are connections in storage that were written before it existed. Their rows do not have the column at all. What happens to them depends entirely on which direction the boolean points, because a missing column deserializes to false either way. Under the old negative name, missing means "not disabled" and provisioning continues. Under a new positive name, missing means "not enabled" and provisioning stops.

So a straight rename silently turns off just-in-time provisioning for every connection a customer configured back when it was on. They chose nothing, they were not told, and the first they hear about it is an employee who cannot sign in, at whatever hour that happens. That is not a security improvement, it is an outage delivered by deploy.

The obvious answer is a backfill: walk every stored connection, write the column explicitly, then flip the default. It works, and it is a migration you have to write, test, run against every tenant's storage, and be sure completed everywhere before the code that depends on it ships. For a boolean.

The double negative

We did not write the migration. The stored column keeps its old negative meaning forever, and the model gains a positive property in front of it:

public bool JitProvisioningEnabled { get; set; }

public bool DisableJitProvisioning
{
    get => !JitProvisioningEnabled;
    set => JitProvisioningEnabled = !value;
}

The positive property is the real one, with real storage behind it, and it defaults to false, which is the new safe default. The negative name is now a computed alias that inverts in both directions.

Follow an old row through. The column is missing, so it reads as false, so the setter for DisableJitProvisioning runs with false, so JitProvisioningEnabled becomes true. The connection keeps provisioning, exactly as its owner configured it, and nothing was migrated. Follow a new connection through. Nobody sets either property, JitProvisioningEnabled stays at its default of false, and the connection rejects unknown users until somebody opts in.

Both behaviours come out of the same code with no branch, no version flag, and no data touched. The persisted bit never changed meaning. Only the field it lands in did, and the inversion happens in a property setter that runs on every load.

What it cost

This is not free, and the bill arrives at the API boundary. Both properties are public, so both get serialized, and a client that reads a connection, changes something, and writes it back is now sending two properties that describe the same thing. Deserialization applies them in the order they appear in the payload, so the last one wins. Set the positive property to true while leaving a stale negative one in the object you fetched, and your change is silently undone by a field you did not think you were sending.

We found that the way you find these things, in a test that flipped the flag on and then asserted it was on. The rule that came out of it is to set both forms explicitly on any read-modify-write, which our own end-to-end test now does with a comment explaining why. If you adopt this trick, budget for that. A two-way alias buys you a free migration and charges you an ambiguity on the wire.

The bug the flip uncovered

Here is the part that generalises past booleans. While making the change, we found that the admin endpoint for creating an OIDC connection had never set this flag at all. Not incorrectly, not to the wrong value. It simply never assigned it, and the request object had no field for it to assign.

That was invisible for as long as the default was the value everyone wanted. Every connection came out provisioning, which is what the code that forgot to wire it would have produced anyway, so there was nothing to notice and no test that could have failed. The moment the default flipped, that same gap became "every newly created OIDC connection has provisioning off and no way to turn it on," which is not a subtle bug at all.

A default is the value of every code path that forgot to set the field. While the default is convenient, those paths are indistinguishable from the ones that set it deliberately. Changing a default does not just change new behaviour, it develops the photograph: everything that was silently relying on the default becomes visible at once, and some of it is broken.

The checkbox that did not move

The last place a default hides is the user interface. Our portal had a checkbox that read "Disable JIT provisioning," unchecked by default. It now reads "Enable JIT provisioning," and it is still unchecked by default. Same widget in the same position with the same initial state, and the opposite meaning.

That is a genuinely dangerous kind of change, so the list view gained a badge. Any connection not opted in is now labelled, so the state is visible without opening anything, rather than being inferred from an unchecked box that used to mean the other thing.

And when a connection with provisioning off receives an assertion for somebody unknown, the user is not dumped on a stack trace. They go back to the application they came from with an error that says the account was not found and to contact their administrator, which is the true and actionable version of what just happened.

Defaults are API surface, inherited by four populations

Defaults are API surface. They are inherited by stored rows that predate the field, by configuration files that omit it, by code paths that never set it, and by user interface controls whose unchecked state encodes them. Before you move one, enumerate those four populations and decide, for each, whether it should follow the new default or keep the old behaviour. Usually the answer is different for each, and that is the design work.

And if you find you are about to write a data migration to move a boolean, look first at whether the meaning can stay put while the name and the default move in front of it. Storage is the expensive place to change your mind. A property setter is the cheap one.

If you would rather your identity provider shipped with the careful defaults already chosen, Authagonal makes every SSO connection opt in to provisioning, and tells you plainly which ones have.

Our login hung for exactly 10 seconds. Our own security headers did it.

authagonal — Thu, 23 Jul 2026 00:00:37 +0000

For about a week, returning users who opened our portal watched the word "Loading…" sit on the screen for ten seconds before the login page appeared. Not sometimes. Not roughly. Ten seconds, every time, and then everything worked perfectly. First-time visitors never saw it. Only people who had signed in before.

A bug that takes a random amount of time is a performance problem. A bug that takes exactly ten seconds is a confession. Nothing in a healthy web request rounds itself off to a clean power of ten. That number is not the sum of some real work; it is the ceiling of a timeout, and a timeout means something, somewhere, is patiently waiting for a thing that is never going to arrive.

This is the story of what it was waiting for, and why the thing it waited for was blocked by a security header we were proud of.

What the portal does on mount

Our portal is a single-page app. When it loads, before it shows you anything, it tries to answer one question: are you already signed in? The polite way to do that with OIDC is a silent check. The app asks the identity provider "if this browser already has a session, hand me a fresh token without bothering the user." Our client library, oidc-client-ts, exposes this as signinSilent(), and we called it on mount from a renewSession() helper.

There are two ways that silent check can run. If the app is holding a refresh token, the library does a quiet back-channel exchange, no UI involved, and you are in. If it is not holding a refresh token, the library falls back to the older mechanism: it opens a hidden iframe pointed at the identity provider's authorize endpoint with prompt=none, and waits for that iframe to post a result back. The whole point of the iframe is that it is invisible. You are never supposed to see it, and on a healthy setup you never do, because it resolves in milliseconds.

Ours never resolved at all.

The wall we built ourselves

The iframe loads the auth host. And the auth host, like every host we run that has any business being taken seriously, ships two headers whose entire job is to say "you may not put me in a frame":

X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none'

These are clickjacking defenses, and they are correct. An attacker who can iframe your login page can float it under a decoy, trick a user into typing real credentials into what looks like something harmless, and harvest them. frame-ancestors 'none' is the modern instruction that no origin, not even our own, may embed this page. We turned it on deliberately. It is exactly the kind of thing a security review looks for and rewards.

So when oidc-client-ts opened its hidden iframe against that host, the browser did precisely what we had told it to: it refused to render the page in a frame. And here is the cruel part. A refused frame does not throw. There is no error event for the library to catch, no rejected promise, no console line. The iframe just sits there, empty, indefinitely. From the library's point of view nothing has happened yet, so it does the only thing it can. It waits for its timeout. That timeout, the default silentRequestTimeout, is ten seconds.

Ten seconds of a hidden iframe staring at a blank wall, then the library gives up, the promise finally rejects, the app shrugs and redirects you to the real login page, and everything works. The hang was never a failure. It was a success that took the scenic route through a doomed iframe.

Two correct things, one bad seam

What made this genuinely hard to see is that nothing was broken. The security headers were right. The silent-renew fallback was right, a legitimate and widely used OIDC pattern. Every component behaved exactly as designed and exactly as any reviewer would want. The ten-second hang did not live inside any one of them. It lived in the space between them, in the assumption each made about the other. The SSO library assumed it could frame the identity provider. The identity provider assumed nobody should ever be allowed to frame it. Both assumptions were defensible. They were simply incompatible, and no single file contained the contradiction.

Why it reached for the iframe at all

That still left a question. The fast path, the refresh-token exchange, would have skipped the iframe entirely. Why were returning users landing on the slow path? Because they had no refresh token to hold. And they had no refresh token because our own portal OAuth clients had been provisioned without AllowOfflineAccess, the flag that authorizes a client to be issued one. No offline access, no refresh token, no fast path, and every returning user was shunted into the iframe that could never load.

That was the real defect, and it was a data problem spread across every tenant, not a one-line code change we could ship once. So the repair is a reconcile service that re-applies AllowOfflineAccess to the portal clients of every tenant at startup, correcting the whole fleet on the next deploy without anyone touching a tenant by hand. Refresh tokens started flowing again, and the fast path came back to life on its own.

The fix, and the lesson

The reconcile service fixed the cause. But a login should not stall for ten seconds even when it does end up on the slow path, so we hardened the seam too. renewSession() now inspects the stored user first: if there is no refresh token in hand, it short-circuits and returns nothing immediately, skips the iframe it already knows is doomed, and sends the user straight to interactive login. The refresh-token fast path is untouched. And as a backstop for any background renewal that still opens an iframe, we cut the timeout from ten seconds to five, so the worst case is half as bad.

The lesson we actually kept is about a category of bug, not this one instance. A hang is a bug, even though it emits no error, no exception, no red line in a log. The only evidence it leaves is elapsed time. And when that time is a clean round number, do not go hunting for slow work to optimize. Go hunting for a timeout, and then find the thing on the other end of it that is silently, permanently, never going to answer. Ours was an iframe, knocking politely on a door we had bolted shut on purpose.

If you would rather your login flow already knew that a locked-down auth host and a silent-renew iframe do not mix, that is a seam we have already run into so that you never have to. Authagonal ships the SSO plumbing and the security headers as one system that was tested together, not as two correct halves you get to discover are incompatible at ten seconds a page load.

HMAC ate my autocomplete: type-ahead search over encrypted emails

authagonal — Wed, 22 Jul 2026 01:42:36 +0000

We encrypt user PII at rest with per-tenant keys, so that a leaked database dump exposes nothing useful. The email column is ciphertext. Phone numbers, names, custom attributes — ciphertext. We're proud of this. It's a selling point.

And the day it went live, the admin search box quietly stopped autocompleting.

No error. No log line. Type ali into user search and the tenant admin who used to see alistair@acme.com pop up after three keystrokes now saw... nothing, unless they typed the entire email address, exactly. Search hadn't broken — it had silently degraded from "starts with" to "equals," and nothing in the system considered that worth mentioning.

This is the story of getting type-ahead back over data we refuse to store in plaintext, and the three traps we hit doing it. The cryptography turned out to be the easy part.

Why encryption eats autocomplete

With plaintext, prefix search is what databases are for. Keep an index ordered by email and starts with "ali" is a range scan: everything >= "ali" and < "alj". Cheap, obvious, done.

Encrypt the column and the ordered index is gone. The standard replacement is a blind index: alongside the ciphertext, store a keyed HMAC of the value, and look users up by recomputing the HMAC of the search term. HMAC(key, "alistair@acme.com") is deterministic, so exact-match lookup works perfectly — and the index leaks nothing readable, because without the per-tenant key you can't compute a digest to compare against.

But notice what HMAC is for. Its entire design goal is that similar inputs produce unrelated outputs — flip one bit, get a completely different digest. HMAC("ali") and HMAC("alistair") have nothing to do with each other. The property that makes the blind index safe to leak is precisely the property that makes it unable to answer "starts with." Ordering is leakage. A blind index doesn't accidentally break prefix search; it breaks it on principle.

So the search box degraded to exact-match, silently, because exact-match was the only question the index could still answer.

The design: index every prefix as its own value

If the index can only answer "equals," then turn "starts with" into "equals."

Every prefix of the normalized email local part — the bit before the @ — gets its own blind-index row. For alistair@acme.com, that's rows for al, ali, alis, alist, and so on: PartitionKey = HMAC(prefix), RowKey = the user id. Now "starts with ali" is an exact-match lookup on HMAC("ali") — one point query, no ordering required. Our name search had already worked this way for the same reason; email just joined it.

Two constants keep it sane. Prefixes start at 2 characters (one-character lookups were never useful and double the rows) and cap at 16 (bounds the fan-out per email; a longer query just matches on its first 16 characters, and the handful of candidates get filtered after decryption). So each email costs at most 15 index rows — written on create, moved on email change, removed on delete.

That's the trade in one sentence: you buy back the ordering you refused to leak, and you pay for it in write fan-out. Storage and writes are cheap; leaked structure is not. It's a good trade.

One subtlety in the move-on-change path earned its own comment in the code: the prefix rows are keyed on the local part, so the rewrite has to trigger when the local part changes — independently of the domain. A same-domain rename, alistair@acme.com → wendy@acme.com, looks like "domain unchanged, skip the index work" to a guard written with the domain index in mind, and would leave the old prefix rows pointing at the renamed user forever.

And to be honest about what we built: this index deliberately leaks prefix-equality — an attacker with the table can see that two users share a 3-character email prefix, though not what it is. Searchable encryption never eliminates leakage; it lets you choose it, consciously, per query shape. Equality and prefix-equality are the leakage we chose. That framing — pick your leakage, then engineer everything else around it — is the whole discipline.

The design worked. Then the systems problems started.

Trap one: the key that couldn't be created

Blind indexes need an HMAC key per tenant, provisioned in Vault's transit engine like our encryption keys. Creating one returned a 500: invalid key size for HMAC key.

Vault requires an explicit key_size for hmac-type keys — 32 to 512 bytes — where the fixed-size types (aes256-gcm96, ecdsa-p256) forbid it. Our key-creation call sent only {"type":"hmac"}. One missing field.

Here's why this was a trap and not a bug report: every tokenize operation threw — and the login path tokenizes, because finding a user by email at sign-in goes through the same blind index as admin search. Enabling encryption didn't break search. It broke login. The feature whose sales pitch is "your users are safer" took sign-in down on first enable in dev. The fix is key_size=32 (HMAC-SHA256) for hmac keys, omitted for the fixed-size types — and a standing rule: smoke-test the tokenize path against a real Vault before flipping encryption on anywhere. Mocks don't validate key-creation payloads.

Trap two: the update that could strand a user

Changing an email means index maintenance: remove the old rows, write the new ones. Our first implementation did it in that order — delete, then write. Natural, tidy, wrong.

Every new-row write now involves Vault (computing the HMAC PartitionKeys). Delete the old rows first, and a Vault hiccup during the write leaves the user with neither the old lookup rows nor the new ones. They exist, encrypted, in the table — and nothing can find them. Including login. That's not a degraded search; that's a locked-out user, until some future reindex sweeps by.

The fix is ordering, not error handling: write before delete, everywhere the index is maintained. A crash between the two steps now leaves an extra stale row — harmless, lazily cleaned — instead of a missing one. The failure mode moved from "user unreachable" to "one redundant row," for free. When a write path involves a remote dependency, pick the step order whose half-finished state you can live with.

Trap three: the partition that ate an import

We also keep a domain blind index — HMAC(domain) → members — so "everyone at acme.com" is one lookup. Deterministic hashing has a consequence nobody prices in until an import: every user of one domain lands in one partition. An Azure Table partition takes roughly 2,000 operations a second. A 50k-user single-domain import from Auth0 funnelled every domain-index write into exactly that bottleneck.

The fix is bucketing: members spread across 16 partitions by a hash of the user id, and domain reads fan out over the buckets — bounded, and rare enough not to matter. Two details carried the lesson. The bucket hash is a hand-rolled FNV-1a, because .NET's string.GetHashCode is deliberately unstable across processes — bucket by it and tomorrow's process computes a different bucket for the same user and can't find the row it's supposed to delete. And the read path still sweeps the legacy unbucketed partitions, so existing rows stayed findable with no forced backfill — new writes distribute immediately, old rows migrate whenever the user is next touched.

The lesson

Nothing in this story is novel cryptography. HMAC is decades old; "hash the value, index the hash" fits in a sentence. Everything that actually cost us was systems work: which query shapes the product genuinely needs (equality, prefix, domain — each got its own index, because a blind index answers exactly one question); how keys get provisioned and what happens on the login path when they don't; which order index writes happen in when a remote KMS sits in the middle; and where deterministic hashing concentrates load that plaintext never did.

Searchable encryption is sold as a crypto feature. Build it and you'll discover it's a distributed-systems feature wearing a crypto costume. The search box autocompletes again — ali finds Alistair after three keystrokes — and a stolen dump of the same table shows HMAC digests fanned across sixteen buckets, which is to say: nothing. Both at once was always the point.

Encrypting every user's PII at rest while keeping the admin search box instant is exactly the kind of thing you get to not build when you run auth on Authagonal. We already paid for all three traps.

OIDC oder SAML: welches Sie wirklich brauchen

authagonal — Mon, 20 Jul 2026 23:30:28 +0000

Jedes Team, das B2B-Software baut, steht an derselben Weggabelung, sobald ein ernstzunehmender Kunde zum ersten Mal sagt: „Wir brauchen SSO." Zwei Akronyme, OIDC und SAML, beide beanspruchen, die Antwort zu sein, und ein Internet voller Vergleichstabellen, die Ihnen erzählen, SAML sei „Enterprise" und OIDC sei „modern" und Sie genauso ratlos zurücklassen wie zuvor. Hier ist die Version, die Ihnen wirklich hilft, etwas auszuliefern.

Was sie sind

SAML stammt aus dem Jahr 2005 und ist XML. Ein Identity Provider signiert eine Assertion („das ist alice@bigco.com, hier sind ihre Gruppen") und schickt sie an Ihre App, die die Signatur prüft und sie anmeldet. Es wurde für den Browser und für Workforce-Identity gebaut, in einer Zeit, in der „das Unternehmen" ein On-Premises-Active Directory und einen SOAP-Stack bedeutete. Es ist umständlich, es ist alt, und es ist in großen Organisationen absolut überall – und das ist die eine Tatsache daran, die für Sie zählt.

OIDC stammt aus dem Jahr 2014 und ist JSON und JWTs, aufgesetzt auf OAuth 2.0. Ein Identity Provider stellt ein ID-Token aus, das Ihre App validiert. Es wurde für das moderne Web gebaut: SPAs, mobile Apps, APIs, Social Login. Es ist sauberer, besser spezifiziert für die Dinge, die Sie heute tatsächlich bauen, und das Protokoll, das die meisten Identity-Projekte auf der grünen Wiese inzwischen sprechen.

Wann welches gewinnt

Die ehrliche Antwort auf „welches soll ich bauen" lautet: Sie haben fast nie die Wahl. Sie bauen das, was die IT-Abteilung Ihres Kunden ausgewählt hat – und sie hat es ausgewählt, lange bevor sie je von Ihnen gehört hat.

Ein Kunde auf Okta, Entra ID oder Google Workspace kann meist beides, und OIDC ist der angenehmere Weg.
Ein Kunde mit einem älteren ADFS, einem veralteten On-Premises-IdP oder einer 2016 verfassten Beschaffungs-Checkliste reicht Ihnen einen Brocken SAML-Metadaten und eine Kalendereinladung – und damit ist die Diskussion beendet.
Ihre eigenen First-Party-Apps, Ihr Dashboard und Ihr Mobile-Client, wollen OIDC, Punkt. Sie würden niemals zu SAML greifen, um einen Nutzer in Ihrer eigenen React-App anzumelden.

Das Feld teilt sich also sauber auf: OIDC für das Moderne und das First-Party, SAML für „weil das Unternehmen es so verlangt". Verkaufen Sie an genug Unternehmen, und Sie werden nach beidem gefragt. Nicht irgendwann. Immer wieder.

Die Fallstricke – und hier wird Selbstbauen teuer

SAMLs Problem ist, dass es ein Protokoll mit signiertem XML ist, und signiertes XML gehört zum Verlässlich-Gefährlichsten in der angewandten Kryptografie. Die Wege, die SAML-Signaturprüfung falsch zu machen, sind zahlreich und berüchtigt:

Signature Wrapping (XSW): Ein Angreifer verschiebt das signierte Element und schiebt eine unsignierte, gefälschte Assertion genau dorthin, wo Ihr Parser tatsächlich liest. Wenn Sie die Signatur prüfen und die Assertion in zwei getrennten Schritten lesen, sind Sie wahrscheinlich angreifbar – und fast jede erste Implementierung macht genau das.
Kanonisierung und Comment Injection: die Bug-Klasse von 2018, bei der user@company.com.evil.com für die Signaturprüfung auf eine Weise kanonisiert wird und für die Zeichenkette, die Ihr Code liest, auf eine andere – sodass Sie fröhlich die falsche Person authentifizieren. Echte CVEs, mehrere große Bibliotheken.
Die leiseren: die Response signieren, aber nicht die Assertion; unsignierte Assertions akzeptieren; dem vom IdP gelieferten Issuer vertrauen, ohne ihn zu pinnen; das Gültigkeitsfenster der Assertion falsch setzen. Jeder davon ist ein eigener Fallstrick, und jeder ist schon von Leuten, die wussten, was sie tun, in Produktion ausgeliefert worden.

OIDC ist deutlich vernünftiger, aber nicht frei von scharfen Kanten. Sie müssen immer noch die richtigen Claims validieren (iss, aud, exp, die nonce), PKCE verwenden, den längst toten Implicit Flow ablehnen und JWKS rotieren und cachen, ohne ein Token zurückzuweisen, das mit einem Schlüssel signiert wurde, den Sie noch nicht abgerufen haben. Der Unterschied ist, dass OIDCs Fallen dokumentiert, JSON-förmig und in den meisten Bibliotheken standardmäßig korrekt behandelt sind. SAMLs Fallen sind XML-förmig und haben Sicherheitsteams verschlungen, die weit besser ausgestattet waren als Ihres.

Die wahre Antwort

„OIDC oder SAML" ist die falsche Frage, denn die richtige Antwort für ein B2B-Produkt lautet „ja". Ihre modernen Kunden und Ihre eigenen Apps wollen OIDC. Ihre Enterprise-Kunden werden SAML vorschreiben, nach einem Zeitplan, den Sie nicht kontrollieren. Bauen Sie für eines, und der dritte Verkaufstermin macht es kaputt.

Was Sie wirklich brauchen, ist eine Möglichkeit, das jeweils mitgebrachte Protokoll jedes Kunden anzunehmen, ohne zwei Stacks, zwei Sätze Metadaten-Klempnerei und zwei voneinander unabhängige Gelegenheiten aufzustellen, die Signaturprüfung falsch zu machen. Die Implementierung ist der Preis. Die Wahl war nie der schwere Teil.

Genau diesen Teil nimmt Authagonal Ihnen ab. Jeder Tenant bekommt SAML 2.0 mit Metadaten-Import per Klick und OIDC-Föderation mit den Providern, die Ihre Kunden ohnehin betreiben, auf demselben Login, ohne Gebühr pro Verbindung für beides. Sie implementieren keine XML-Signaturprüfung, Sie hüten keinen JWKS-Cache, und Sie bauen nichts davon neu, wenn der nächste Kunde auftaucht und das andere Protokoll spricht. Sehen Sie, was enthalten ist.