DEV Community: authagonal

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.

One ES256 migration, three ways to mangle a valid signature

authagonal — Mon, 20 Jul 2026 23:29:35 +0000

The algorithm migration itself went fine. The three lives of my JWT signing key tells that story: RS256 to ES256 on a live issuer, both keys published in the JWKS through the overlap, an active-key picker that rotates itself off the legacy RSA key. Keys, rotation, discovery — all the parts that sound hard — worked first try.

This is the story of the part that didn't. Three separate times during that migration, our auth server minted a token whose signature was cryptographically valid — the math checked out, the right key had signed the right bytes — and no validator on earth would accept it. Three different layers had each mangled the bytes in its own way, and each failure looked identical from the outside: invalid signature. Not "wrong format," not "unexpected length." Just: invalid.

If you're staring at that error mid-migration, skip to the field guide at the end. The length of the decoded signature names the guilty layer almost every time.

RSA spoiled us: one integer, one encoding

Here's the thing nobody tells you before an ECDSA migration: RSA never had this problem, so none of your instincts transfer.

An RSA signature is a single integer. The wire format is just that integer, big-endian, padded to the key size — 256 bytes for RSA-2048, and there is essentially one way to write it down. Sign with any library, verify with any other, and the bytes mean the same thing.

An ECDSA signature is a pair of integers, (r, s). A pair needs an encoding, and the ecosystem settled on two incompatible ones:

ASN.1 DER — a SEQUENCE of two INTEGERs. Variable length (typically 70–72 bytes for P-256), always starting with the byte 0x30. This is what OpenSSL, X.509, and TLS speak.
Raw R‖S (IEEE P1363) — r and s each left-padded to exactly 32 bytes and concatenated. Always exactly 64 bytes. This is what JWS mandates for ES256 (RFC 7518 §3.4).

Both encode the same signature. Both are "correct." Hand a validator the one it isn't expecting and it doesn't say "wrong container" — it decodes garbage integers and reports the only thing it can: the signature doesn't verify.

Every layer between your key and the wire has an opinion about which of these it speaks. Ours had three layers, and we got all three wrong, sequentially.

Footgun one: the KMS answers in DER

Our private key lives in HashiCorp Vault's transit engine and never leaves it — the application sends bytes to be signed and gets a signature back. When we switched the transit key from rsa-2048 to ecdsa-p256, the sign request still carried a leftover from the RSA era: signature_algorithm=pkcs1v15.

That's an RSA padding parameter. It is meaningless for an ECDSA key. Vault did not error. It ignored the irrelevant parameter, signed with the curve key, and returned 200 with a perfectly valid ECDSA signature — in its default marshaling, which is DER.

So the happy path stayed green end to end: request accepted, signature returned, openssl dgst -verify would have blessed it. And every JWT library rejected every token, because after base64url-decoding the third segment it expected 64 bytes of R‖S and found 71 bytes starting with 0x30.

The fix is one request parameter: Vault's transit sign endpoint takes marshaling_algorithm=jws, which returns raw R‖S directly. But note the shape of the trap: a parameter that is wrong for the key type and silently ignored. The request looked wrong, was wrong, and worked anyway — for the wrong definition of worked.

Footgun two: "just concatenate the integers" fails one token in 128

If your KMS can't emit R‖S natively, you'll be tempted to convert DER yourself: parse out the two INTEGERs, concatenate, done. This is the nastiest footgun of the three, because it's intermittently correct.

DER integers are minimal-length and signed. That means:

an r that happens to be numerically small — high byte zero — encodes in 31 bytes or fewer, because DER strips leading zeroes;
an r whose high bit is set picks up a 0x00 sign byte and encodes in 33 bytes.

The JWS format wants neither. It wants each value left-padded to exactly 32 bytes, always. A naive concatenation of the DER integers produces 63-, 64-, 65-, or 66-byte signatures depending on the draw, and only the 64-byte draws verify. Handle the sign byte but forget the padding and you're left with a converter that fails whenever r or s starts with a zero byte — each is a 1-in-256 event, so about one token in 128 comes out short.

That version passes your smoke test, passes code review, ships, and then fails one login an hour in production with no pattern you can see. We dodged it by making Vault do the conversion (marshaling_algorithm=jws again — let the party that owns the signing operation own the format), but the same trap has a purely local variant in .NET: ECDsa.SignData/VerifyData take a DSASignatureFormat, and different corners of the framework default differently — the SignedXml/certificate world thinks in Rfc3279DerSequence while the raw ECDsa APIs default to P1363. Our local verification path now says DSASignatureFormat.IeeeP1363FixedFieldConcatenation explicitly. After this migration, we don't let any signature API default its format, anywhere.

Footgun three: the fix changed the base64 dialect underneath us

Vault wraps every signature in an envelope: vault:v1:<encoded-bytes>. With the default DER marshaling, the encoded part is standard base64, and our client dutifully called Convert.FromBase64String on it.

Switch to marshaling_algorithm=jws and Vault — reasonably, per the spec it's now speaking — encodes the signature portion in base64url: the -/_ alphabet, no padding. One request flag had changed two things at once: the byte format we asked for, and the text encoding it arrived in.

Convert.FromBase64String wants padded standard base64. A 64-byte signature is 86 base64url characters — not a multiple of four — so the decode threw a FormatException on every single token. In a way this was the kindest of the three failures: it at least crashed, loudly, at the exact line that was wrong, instead of producing valid-looking bytes that quietly failed elsewhere. The fix is to decode (and, on the verify round-trip, re-encode) with a base64url codec.

Count the irony: the signature was finally in the right byte format, and now the text layer mangled it. Three encodings, stacked: the integer-pair encoding, the fixed-field padding, and the character encoding. Each one independently able to turn a valid signature into a rejected token.

The field guide: the length names the culprit

When a JWT fails validation mid-algorithm-migration, base64url-decode the third segment of the token and look at what you have:

Decoded signature	Which layer mangled it
Exactly 64 bytes	Wire format is right — look elsewhere (`kid` mismatch, wrong key in JWKS, `alg` pinning)
70–72 bytes, first byte `0x30`	DER leaked through: the KMS or crypto library is emitting ASN.1
63 or 65 bytes, and only some tokens fail	A hand-rolled DER→raw conversion without fixed-field padding
Decode throws or yields garbage	base64 vs base64url mismatch one layer down

And one cross-check that separates format bugs from key bugs in seconds: verify the same signature with OpenSSL, which speaks DER. If OpenSSL says valid while every JWT library says invalid, you have an encoding problem. If both say invalid, you have a key problem.

The lesson

"Cryptographically valid" is a property of the mathematics. "Verifiable" is a property of every encoding boundary between the mathematics and the consumer — and our signature crossed four of them: the KMS's marshaling, its transport envelope, our client's decode, and the JWS wire format. Three of those boundaries had opinions, and each disagreed with its neighbour exactly once.

The testing moral is the one we actually changed process over: never prove a signing path by verifying with your own code. Our sign path and our verify path shared every one of these assumptions, so sign-then-verify round-trips passed while every real consumer rejected us. The test that finally pinned all three bugs mints a real token, validates it with the platform's stock JWT library against the published JWKS — someone else's assumptions, not ours — and then asserts one brutally specific thing on top: the decoded signature is exactly 64 bytes. The math will look after itself. It's the bytes you have to watch.

Getting ES256 right down to the last byte, so your tokens validate in whatever stack consumes them, is work you only do once when it is ours. Authagonal signs your tokens and publishes the JWKS, so the encoding is never your 2am problem.

Every token validation hit our origin. Now the JWKS lives on the edge.

authagonal — Mon, 20 Jul 2026 02:01:45 +0000

To validate one of our JWTs, a service fetches two public documents from the issuer: the discovery document at /.well-known/openid-configuration, and the JWKS it points to — the set of public keys the tokens are signed with. These are the most-requested and least-secret things we serve. They are public keys, which are public by definition, and metadata that changes only when we rotate. And until recently, every one of those fetches came all the way back to our origin. Because we're multi-tenant, it was worse than that sentence makes it sound.

The origin was doing work it had no reason to do

Every tenant is its own issuer, with its own .well-known document and its own JWKS. And every relying party, every resource server, every SDK that validates a token pulls those documents — on a cold start, when its own short cache expires, once per service instance. Multiply per-tenant issuers by per-service validators by cache misses and you get a firehose of requests, all of it terminating at the application, all of it for documents that are byte-for-byte identical for every caller and change only when we rotate a key.

That is the textbook profile of something that should be cached: public, identical, rarely changing. Instead the app was rendering public keys, dynamically, on the hot path of everyone else's token validation. The keys had no business being computed per request.

Putting them on the edge

The change itself is small: set honest Cache-Control headers on the discovery and JWKS responses so Cloudflare caches them at the edge. Now a validator hits the nearest Cloudflare point of presence, and the origin serves each document roughly once per PoP per TTL instead of once per validation. Discovery is trivially cacheable — it changes almost never. The JWKS is the one you have to think hard about, because the JWKS is the one document whose entire job is to change exactly when you rotate a key, and caching a thing that must be fresh at the one moment it changes is where people hurt themselves.

How a cached JWKS bites you

Key rotation plus a cached key set is a trap, and it fails in the worst possible direction. Rotate to a new signing key, start issuing tokens with it, and a validator that fetched the JWKS before the new key appeared is holding a stale copy. A token arrives carrying the new key's id; the validator looks it up, doesn't find it, and rejects the token. The token is perfectly valid. The signature is real. The user did nothing wrong. Your own edge cache just returned a 401 to a legitimate login.

Notice which way that fails. A stale private key is a nonevent — you simply haven't started using the new one yet. A stale public key set is a self-inflicted outage, and you introduced the cache that caused it on purpose, to save origin traffic. The safety of the whole scheme lives or dies on rotation.

The rotation-safe pattern

The safety is entirely in the ordering, and the ordering is the opposite of an atomic swap. Three rules:

Publish before you sign. The new key goes into the JWKS first, and you do not sign a single token with it until that JWKS — new key id and all — has been live at the edge for at least one full cache TTL. By the time any token bearing the new key can reach a validator, the validator's cached key set already contains the key.
Retire after expiry, not on rotation. The old key stays published in the JWKS until the last token it ever signed has expired. Old and new coexist for the entire overlap. Pull the old key the moment you rotate and you strand every token it signed that's still valid.
TTL shorter than the overlap. The edge cache's max-age, plus a margin for clock skew, must be shorter than the key-overlap window. The cache is allowed to be stale; it is never allowed to be stale for longer than the window in which both keys are good. That single inequality is what makes an aggressively-cached JWKS safe.

Put together, rotation becomes a crossfade with a fixed running order: add the new key, wait a TTL for the edge and every validator to see it, start signing with it, wait for the old tokens to age out, then drop the old key. Every step is safe against a cache that's a TTL behind, because the TTL was chosen to be smaller than every window a cache could be behind.

The lesson, factored out

Caching is usually a latency decision. Caching public keys is a correctness decision, because the thing you're caching is the thing that decides which tokens are real. You can absolutely put it on the edge — you should, because it's public and it's hot — but only once rotation is expressed as an ordered overlap instead of a swap, and only once the cache TTL is provably shorter than that overlap. Get that right and the busiest, most cacheable documents in your auth system stop touching your origin, and nobody ever notices the difference, which is exactly the point.

A JWKS that stays off your origin without ever going stale, and a rotation you never have to choreograph, is part of what you stop operating on Authagonal. We keep the overlap and the TTL in step so your tokens keep validating straight through every key change.

Holen Sie Ihren Terraform-State aus dem öffentlichen Internet (ohne ein VPN aufzubauen)

authagonal — Sun, 19 Jul 2026 09:29:40 +0000

Ihre Terraform-State-Datei ist das mit Abstand sensibelste Artefakt in Ihrer Cloud. Sie ist eine vollständige Landkarte jeder Ressource, die Sie betreiben, und je nach Ihren Providern enthält sie zudem Geheimnisse im Klartext: Verbindungszeichenfolgen, generierte Passwörter, Schlüssel. Standardmäßig liegt diese Datei in einem Cloud-Storage-Account mit einem öffentlichen Endpunkt, abgesichert durch nicht mehr als einen Zugriffsschlüssel. Wenn dieser Schlüssel durchsickert, muss der Angreifer Ihre Infrastruktur nicht erst aufzählen. Sie haben ihm das Diagramm in die Hand gedrückt.

Wir verkaufen Authentifizierung. Ein Auth-Anbieter, der die Schlüssel zu seinem eigenen Königreich im offenen Internet liegen lässt, hat nichts damit zu tun, Ihre zu verwahren. Deshalb hat unser Produktions-State-Account überhaupt keine öffentliche Angriffsfläche. Der Weg dorthin hat drei Fallen, und wir sind in die Form jeder einzelnen hineingelaufen, bevor wir es richtig hinbekommen haben.

Falle eins: das Henne-Ei-Problem

Remote-State braucht ein Backend, das bereits existiert, bevor Terraform laufen kann. Aber das Backend ist selbst Infrastruktur, und idealerweise soll Terraform sie verwalten. Sie können den Storage-Account nicht nutzen, um den State des Storage-Accounts zu speichern, den es noch gar nicht gibt.

Der Ausweg ist ein bewusstes zweiphasiges Bootstrapping. Phase eins läuft mit lokalem State und erzeugt genau das Fundament: den State-Storage-Account, das Netzwerk, in dem er liegen wird, und den Zugriffspfad. Phase zwei kippt den Backend-Block von lokal auf remote und migriert die nun existierende State-Datei hinauf in den Account, den sie gerade erstellt hat. Ab diesem Punkt verwaltet sich diese Bootstrap-Schicht selbst aus der Ferne, wie alles andere auch. Es sind ein paar Minuten, in denen man sich fühlt, als stünde man auf einer Leiter, die man noch baut, und dann ist es für immer erledigt.

Falle zwei: das Erreichbarkeitsproblem und die VPN-Gateway-Steuer

Den Account privat zu machen ist eine einzige Zeile: öffentlichen Netzwerkzugriff abschalten und einen privaten Endpunkt davorsetzen. Jetzt ist der Storage-Account nur noch von innerhalb Ihres virtuellen Netzwerks erreichbar. Was genau das Problem ist, denn das, was ihn am häufigsten erreichen muss, Ihre CI-Pipeline, ist nicht innerhalb Ihres virtuellen Netzwerks. Sie selbst auch nicht.

Die Lehrbuchantwort ist, ein VPN beim Provider aufzubauen. Ein verwaltetes VPN-Gateway, oder einen Bastion-Host, oder Point-to-Site mit Client-Zertifikaten. Jeder, der das schon gemacht hat, kennt die Steuer: Das Gateway ist teuer und langsam bereitzustellen, Point-to-Site bedeutet, Client-Zertifikate auszustellen und zu rotieren, jeder neue Operator ist ein Einrichtungsritual, und ein Bastion ist eine weitere Box zum Patchen und Bezahlen. Es ist eine Menge dauerhaft laufender Infrastruktur, deren einzige Aufgabe es ist, vertrauenswürdige Leute eine private Sache erreichen zu lassen.

Wir haben das alles übersprungen. Statt eines VPN-Gateways läuft ein kleiner Zero-Trust-Connector als Container innerhalb des VNet, die Kategorie, die Tailscale, Twingate und Cloudflare Access besetzen. Er tritt einem identitätsbewussten Mesh bei. Autorisierte Personen und die CI-Pipeline erreichen den privaten Endpunkt durch dieses Mesh, pro Identität authentifiziert, mit Zugriff, der auf genau die eine Ressource beschränkt ist, die ihn braucht. Kein Gateway, keine öffentliche IP, keine zu rotierenden Zertifikate, kein Jump-Host. CI bringt seine Verbindung für die Dauer eines Laufs hoch und reißt sie danach wieder ab. Das Erreichbarkeitsproblem verschwindet, ohne die Rechnung für dauerhaft laufende Infrastruktur.

Falle drei: die Abriegelung, die man nicht in einem Schritt machen kann

Der naheliegende Instinkt ist, den Account von Anfang an als privat zu deklarieren, im selben Terraform-Apply, das ihn erstellt. Tun Sie das, dann kappen Sie die Leitung, bevor der private Pfad existiert: Das Apply muss den State über den öffentlichen Endpunkt schreiben, der private Endpunkt und DNS sind noch nicht verdrahtet, und Sie sperren Terraform, und sich selbst, aus genau dem Account aus, den Sie gerade erstellen. Wir haben das durchdacht, bevor wir es ausgelöst haben, und das ist der eine Moment, in dem der Probelauf im Kopf stattfindet statt im Terminal.

Die Abriegelung ist also ein bewusster separater Schritt, der erst ausgeführt wird, nachdem das Netzwerk, der private Endpunkt und der Connector alle laufen und erprobt sind. Ein einziger Befehl schaltet den öffentlichen Netzwerkzugriff auf deaktiviert. In dem Moment, in dem er greift, ist der öffentliche Endpunkt weg, die alte IP-Allowlist wird irrelevant, weil keine öffentliche Angriffsfläche mehr übrig ist, auf die man irgendetwas zulassen könnte, und jeder zukünftige Lauf erreicht den State über das Mesh. Wir haben es auf die einzige Art verifiziert, die zählt: indem wir geprüft haben, dass der Account jetzt über den privaten Pfad antwortet und den öffentlichen verweigert.

Die andere Hälfte: kein Passwort zum Stehlen

Das Töten des öffentlichen Endpunkts entfernt die Netzwerktür. Der passende Zug ist, sicherzustellen, dass auch kein dauerhafter Schlüssel dahinter liegt. Unsere Pipeline hält keine Cloud-Credentials. Sie authentifiziert sich mit Workload Identity Federation: Das CI-System legt ein kurzlebiges OIDC-Token vor, die Cloud vertraut diesem Token für genau ein bestimmtes Repository und gibt Zugriff zurück, der in Minuten abläuft. Es gibt kein Service-Principal-Secret, das in einem Vault auf das Durchsickern wartet, weil es von vornherein gar kein Secret gibt.

Der State-Zugriff folgt derselben Regel. Terraform liest und schreibt das State-Blob mit einem kurzlebigen Verzeichnis-Token, das an diese Identität gebunden ist, nicht mit dem Zugriffsschlüssel des Storage-Accounts. So kommen die beiden Dinge, die ein Angreifer am meisten will, ein Weg hinein und eine Credential, um ihn zu nutzen, als ein rein privater Endpunkt und ein Token heraus, das bereits ablief, während er es las. Nichts Statisches zum Mitnehmen.

Warum der Aufwand

State-Dateien sickern für gewöhnlich nicht durch, weil jemand die Verschlüsselung gebrochen hat. Sie sickern durch, weil der Account öffentlich war, ein Schlüssel in einem Log oder einem Fork oder auf einem Laptop landete und sonst nichts mehr im Weg stand. Den öffentlichen Endpunkt zu entfernen löscht die gesamte Klasse von "der Schlüssel ist durchgesickert" aus dem Bedrohungsmodell. Der Schlüssel wird nutzlos, wenn man nicht auch im Mesh ist.

Es ist dasselbe Prinzip, auf dem wir das Produkt aufbauen: Sicherheit nicht hinter Aufwand oder Tarifstufe verstecken, sondern einfach machen, weil die Alternative das ist, was man um zwei Uhr nachts bereut. Jedes Sicherheitsfeature, das wir an Kunden ausliefern, SSO und SAML, SCIM, MFA, erzwungene Webhooks, Audit-Export, ist in jedem Tarif aktiv, nicht für einen Enterprise-Upsell zurückgehalten. Sehen Sie, was enthalten ist.

Dejar el Duende autoalojado: qué migra y qué dejas de operar

authagonal — Sat, 18 Jul 2026 13:30:12 +0000

Duende IdentityServer es un software realmente bueno: si quieres ser dueño de tu capa de identidad de principio a fin, es el estándar en .NET. Pero "ser dueño" es justamente todo el coste: lo alojas, lo parcheas, lo escalas y construyes todo lo que lo rodea, la interfaz de administración, el MFA, los registros de auditoría, la imagen de marca, una página de estado, la gestión de usuarios y roles. En algún momento, un equipo decide que prefiere no operar un IdP, y la única pregunta que importa es cuán doloroso resulta migrar. Esto es lo que realmente migra.

Lo que realmente estás ejecutando

Autoalojar Duende te hace responsable de mucho más que los endpoints de tokens:

El propio IdP: alojamiento, escalado, parcheo y la licencia (SAML es un complemento de pago adicional).
Todo lo que lo rodea y que construiste tú mismo: portal de administración, registro de MFA, registro de auditoría, imagen de marca personalizada, una página de estado, gestión de usuarios y roles.

Esa segunda lista suele ser donde se va el verdadero tiempo.

Lo que migra, y es en su mayoría mecánico

Duende guarda su configuración en SQL (la ConfigurationDb) y sus usuarios en ASP.NET Identity. Una migración lee ambos:

Clients → clientes OAuth, incluidos los URI de redirección y de cierre de sesión, los orígenes CORS, los tipos de concesión, la semántica de uso y expiración de los refresh tokens y las duraciones de los device codes. Los clientes deshabilitados se importan deshabilitados; los secretos expirados se omiten con una advertencia.
Scopes → los ApiScopes e IdentityResources se mapean directamente. La capa intermedia ApiResource de Duende (una audiencia más una lista de claims compartida) se aplana sobre el modelo más simple: el nombre del recurso se convierte en una audiencia en cada cliente que usa un scope miembro, y sus claims se fusionan con esos scopes.
Users → la buena noticia: los hashes de contraseña de ASP.NET Identity V3 (y el bcrypt heredado) se verifican de forma nativa y se vuelven a hashear en el primer inicio de sesión. Sin restablecimientos de contraseña, sin tickets de soporte, nada que tus usuarios noten. (Esta es la parte que es genuinamente difícil al dejar Auth0: con Duende simplemente funciona, porque es el mismo hashing que tu aplicación ya usa.)
Los roles y asignaciones, los inicios de sesión externos y los proveedores de identidad OIDC se traen todos. Los proveedores SAML se marcan para que los reconfigures en el otro lado.

La parte de la estabilidad de la identidad

Como en cualquier cambio de IdP, lo que hay que hacer bien es no cambiar el sub del usuario ni el client_id: los refresh tokens posteriores, las filas SCIM en los IdP de los clientes y los identificadores de usuario almacenados en tu propia base de datos los referencian todos. El importador preserva ambos. Y si uno de los propietarios de tu portal también existe como usuario de Duende con un identificador distinto, los reconcilia (rotando al sub de Duende) mediante pasos escalonados y recuperables, en lugar de dejar a un propietario migrado a medias que no puede iniciar sesión.

Un inciso sobre probar migraciones (una trampa de .NET)

Probamos el importador contra una base de datos Duende real y poblada, no contra mocks, y dio resultado. ASP.NET Identity almacena AspNetUsers.LockoutEnd como datetimeoffset, y leerlo con reader.GetDateTime() lanza una InvalidCastException con ese tipo. Así que un único usuario bloqueado habría hecho fallar toda la importación de usuarios. Eso solo se descubre ejecutando el importador contra datos reales que incluyan un usuario bloqueado. Si estás sopesando alguna herramienta de migración, esa es la pregunta que merece la pena hacer: ¿se prueba contra una base de datos poblada, o solo se mockea contra la API de origen?

Lo que dejas de hacer

El sentido de migrar no es la migración: es todo lo que viene después. SAML, SCIM, MFA, registros de auditoría, dominios personalizados e imagen de marca vienen incluidos en lugar de ser cosas que construyes y operas, y parchear y escalar el IdP dejan de ser tu problema. Si autoalojar Duende fue una decisión deliberada ("queremos control total") y sigue siéndolo, quédate: es una elección perfectamente buena. Esto es para cuando operar un IdP ha dejado de ser donde quieres dedicar tu tiempo.

Si te lo estás planteando

La migración es en su mayoría mecánica, las contraseñas se trasladan sin restablecimientos, y la vista previa es de solo lectura: apúntala a tu base de datos Duende y te muestra exactamente lo que se importaría antes de escribir nada.

→ Migrar desde Duende

OIDC ou SAML : lequel vous faut-il vraiment

authagonal — Sat, 18 Jul 2026 03:14:31 +0000

Toute équipe qui développe un logiciel B2B se heurte au même carrefour la première fois qu'un client sérieux annonce « il nous faut le SSO ». Deux acronymes, OIDC et SAML, prétendant chacun être la réponse, et un internet rempli de tableaux comparatifs qui vous disent que SAML est « entreprise » et OIDC « moderne », pour vous laisser exactement aussi coincé qu'avant. Voici la version qui vous aide vraiment à livrer.

Ce qu'ils sont

SAML date de 2005 et c'est du XML. Un fournisseur d'identité signe une assertion (« voici alice@bigco.com, voici ses groupes ») et la transmet à votre application, qui vérifie la signature et la connecte. Il a été conçu pour le navigateur et pour l'identité des collaborateurs, à une époque où « l'entreprise » signifiait un Active Directory sur site et une pile SOAP. Il est verbeux, il est ancien, et il est absolument partout au sein des grandes organisations, ce qui est le seul fait le concernant qui compte pour vous.

OIDC date de 2014 et c'est du JSON et des JWT, posés sur OAuth 2.0. Un fournisseur d'identité émet un jeton d'identité que votre application valide. Il a été conçu pour le web moderne : SPA, applications mobiles, API, connexion sociale. Il est plus propre, mieux spécifié pour ce que vous construisez réellement aujourd'hui, et c'est le protocole que parle désormais la plupart des nouveaux projets d'identité.

Quand chacun l'emporte

La réponse honnête à « lequel dois-je développer » est que vous n'avez presque jamais le choix. Vous développez celui qu'a choisi le service informatique de votre client, et il l'a choisi bien avant d'avoir entendu parler de vous.

Un client sous Okta, Entra ID ou Google Workspace peut généralement faire l'un ou l'autre, et OIDC est la voie la plus agréable.
Un client sous un ADFS plus ancien, un IdP historique sur site ou une grille d'achat rédigée en 2016 vous remettra un bloc de métadonnées SAML et une invitation à un rendez-vous, et la discussion s'arrête là.
Vos propres applications maison, votre tableau de bord et votre client mobile, veulent OIDC, point final. Vous n'iriez jamais chercher SAML pour connecter un utilisateur à votre propre application React.

Le terrain se divise donc nettement : OIDC pour le moderne et le maison, SAML pour « parce que l'entreprise l'a décidé ». Vendez à suffisamment d'entreprises et on vous demandera les deux. Pas à terme. À répétition.

Les pièges, là où le faire soi-même devient coûteux

Le problème de SAML, c'est qu'il s'agit d'un protocole à XML signé, et le XML signé est l'une des choses les plus régulièrement dangereuses de la cryptographie appliquée. Les façons de rater la vérification de signature SAML sont nombreuses et célèbres :

Encapsulation de signature (XSW) : un attaquant déplace l'élément signé et glisse une assertion forgée, non signée, là où votre analyseur lit réellement. Si vous vérifiez la signature et lisez l'assertion en deux étapes distinctes, vous êtes probablement vulnérable, et c'est exactement ce que fait presque toute première implémentation.
Canonicalisation et injection de commentaires : la catégorie de failles de 2018 où user@company.com.evil.com se canonicalise d'une façon pour la vérification de signature et d'une autre pour la chaîne que lit votre code, si bien que vous authentifiez allègrement la mauvaise personne. De vraies CVE, plusieurs bibliothèques majeures.
Les plus discrets : signer la réponse mais pas l'assertion, accepter des assertions non signées, faire confiance à l'émetteur fourni par l'IdP sans l'épingler, se tromper sur la fenêtre de validité de l'assertion. Chacun est son propre piège, et chacun a été mis en production par des gens qui savaient ce qu'ils faisaient.

OIDC est nettement plus sain, mais il n'est pas exempt d'arêtes vives. Vous devez tout de même valider les bons claims (iss, aud, exp, le nonce), utiliser PKCE, refuser le flux implicite mort depuis longtemps, et gérer la rotation et la mise en cache des JWKS sans rejeter un jeton signé par une clé que vous n'avez pas encore récupérée. La différence, c'est que les pièges d'OIDC sont documentés, de forme JSON, et gérés correctement par défaut dans la plupart des bibliothèques. Les pièges de SAML sont de forme XML et ont dévoré des équipes de sécurité bien mieux dotées que la vôtre.

La vraie réponse

« OIDC ou SAML » est la mauvaise question, car la bonne réponse pour un produit B2B est « oui ». Vos clients modernes et vos propres applications veulent OIDC. Vos clients grands comptes imposeront SAML selon un calendrier que vous ne maîtrisez pas. Construisez pour l'un, et le troisième appel commercial le casse.

Ce dont vous avez réellement besoin, c'est d'un moyen d'accepter le protocole que chaque client apporte, sans monter deux piles, deux tuyauteries de métadonnées et deux occasions distinctes de rater la vérification de signature. La mise en œuvre, voilà le coût. Le choix n'a jamais été la partie difficile.

C'est précisément ce dont Authagonal vous décharge. Chaque locataire bénéficie de SAML 2.0 avec import de métadonnées en un clic et de fédération OIDC avec les fournisseurs que vos clients utilisent déjà, sur la même page de connexion, sans frais par connexion pour l'un comme pour l'autre. Vous n'implémentez pas la vérification de signature XML, vous ne maternez pas un cache JWKS, et vous ne reconstruisez rien de tout cela quand le prochain client se présente en parlant l'autre protocole. Découvrez ce qui est inclus.

OIDC 还是 SAML：你真正需要的是哪一个

authagonal — Sat, 18 Jul 2026 03:07:42 +0000

每一个开发 B2B 软件的团队，都会在第一次有正经客户说出"我们需要 SSO"时撞上同一个岔路口。两个缩写，OIDC 和 SAML，都自称是答案，而满网都是对比表格告诉你 SAML 是"企业级"、OIDC 是"现代化"，然后把你撂在原地，跟之前一样毫无头绪。这里给你一个真正能帮你交付的版本。

它们是什么

SAML 来自 2005 年，本质是 XML。身份提供方对一份断言签名（"这是 alice@bigco.com，这是她所属的群组"），然后把它发送给你的应用，应用校验签名并让她登录。它是为浏览器和员工身份场景而生的，那个年代的"企业"意味着本地部署的 Active Directory 和一套 SOAP 技术栈。它冗长、它老旧，而且在大型组织内部无处不在——这才是关于它你唯一需要在意的事实。

OIDC 来自 2014 年，本质是 JSON 和 JWT，构建在 OAuth 2.0 之上。身份提供方签发一个 ID 令牌，由你的应用来校验。它是为现代 Web 而生的：SPA、移动应用、API、社交登录。它更简洁，对你今天真正在构建的东西有更完善的规范，也是如今大多数全新身份方案所使用的协议。

各自何时胜出

对于"我应该构建哪一个"这个问题，老实的答案是：你几乎从来没有选择权。你构建的是你客户的 IT 部门选定的那一个，而且他们早在听说你之前就已经选好了。

一个使用 Okta、Entra ID 或 Google Workspace 的客户通常两种都能用，而 OIDC 是更舒服的那条路。
一个用着老版 ADFS、某个遗留的本地部署 IdP，或一份写于 2016 年的采购清单的客户，会扔给你一堆 SAML 元数据和一封日历邀请，讨论到此为止。
你自己的第一方应用——你的仪表盘和你的移动客户端——要的是 OIDC，没有例外。你绝不会为了让用户登录进你自己的 React 应用而去搬出 SAML。

于是局面清晰地一分为二：现代场景和第一方场景用 OIDC，"因为企业方这么要求"的场景用 SAML。卖给足够多的企业，你就会被要求两者都支持。不是迟早，而是反反复复。

那些坑——也正是自己动手会变得昂贵的地方

SAML 的问题在于它是一种签名 XML 协议，而签名 XML 是应用密码学中最稳定可靠地危险的东西之一。把 SAML 签名校验做错的方式既多又出名：

签名包装（XSW）： 攻击者移动已签名的元素，把一份未签名、伪造的断言塞到你的解析器实际读取的位置。如果你把校验签名和读取断言做成两个分开的步骤，那你大概率就有漏洞——而几乎每一个初版实现做的恰恰就是这件事。
规范化与注释注入： 2018 年那一类漏洞，user@company.com.evil.com 在签名校验时按一种方式规范化、在你代码读取的字符串里按另一种方式规范化，于是你乐呵呵地把错误的人认证通过了。真实存在的 CVE，涉及多个主流库。
那些更不起眼的： 只签名响应却不签名断言、接受未签名的断言、信任 IdP 提供的颁发者却不做固定校验、把断言的有效期窗口算错。每一个都是自己的一颗地雷，而且每一个都被本该懂行的人发布到了生产环境。

OIDC 明显更理智一些，但也并非没有锋利的边角。你仍然得校验正确的声明（iss、aud、exp、以及 nonce）、使用 PKCE、拒绝早已作古的 implicit 流程，还要在轮换和缓存 JWKS 时不至于拒掉一个由你尚未拉取的密钥所签名的令牌。区别在于，OIDC 的陷阱有文档可查、是 JSON 形态的，并且在大多数库里默认就被正确处理。SAML 的陷阱是 XML 形态的，已经吞掉过资源远比你充裕的安全团队。

真正的答案

"OIDC 还是 SAML"是个错误的问题，因为对一款 B2B 产品来说，正确的答案是"都要"。你的现代客户和你自己的应用想要 OIDC。你的企业客户会在一个你无法掌控的时间表上强制要求 SAML。只为其中一个去构建，第三通销售电话就会把它打破。

你真正需要的，是一种能接住每个客户带来的任意协议的办法，而不必搭起两套技术栈、两套元数据管线，以及两次各自独立、各自把签名校验做错的机会。实现才是成本所在。选择从来都不是难的那部分。

而这正是 Authagonal 替你卸下的那部分。每个租户都能获得带一键元数据导入的 SAML 2.0，以及与你客户已在使用的提供方对接的 OIDC 联合登录，二者共用同一个登录入口，且任何一种都不收取按连接计费的费用。你不必实现 XML 签名校验，不必照看 JWKS 缓存，也不必在下一个说着另一种协议的客户出现时把这一切重建一遍。看看都包含了什么。

Las tres vidas de mi clave de firma JWT

authagonal — Fri, 17 Jul 2026 05:02:18 +0000

Una sola clave privada firma todos los tokens que emite nuestro servidor de autenticación. Piérdela y un atacante acuña un token válido para cualquier usuario, sin necesidad de contraseña, y tus registros muestran un inicio de sesión impecable. Es el secreto más valioso de todo el sistema y, a lo largo de su vida, se ha mudado dos veces: nació dentro del proceso de la aplicación, luego fue desterrada a una bóveda de la que ya no puede salir y después se reencarnó en un tipo de clave completamente distinto. Cada mudanza ocurrió en un emisor en producción, con tokens ya en circulación y validadores que cachean un estado que no controlamos. Esto es lo que realmente cuestan esas mudanzas, y la que más nos enseñó fue la que no anunciamos.

Vida uno: la clave que el servidor guardaba en el bolsillo

Al principio, la clave vivía donde se usaba. El servidor generaba una clave RSA-2048, la mantenía en memoria y firmaba sus tokens con RS256. Este es el comportamiento por defecto en casi todas partes, y funciona bien hasta el momento en que pronuncias en voz alta la palabra custodia. La clave privada era accesible para cualquier cosa capaz de leer la memoria del proceso, su configuración o una copia de seguridad de cualquiera de las dos. Queríamos poder decirles a los clientes que una base de datos filtrada no expone nada útil, y una clave de firma que estaba a un solo proceso de distancia de esa base de datos convertía esa afirmación en una mentira. La clave tenía que salir del edificio.

Vida dos: la clave que se mudó a una bóveda de la que no puede salir

Introdujimos una costura —un ISignatureProvider al que el servidor llama cada vez que necesita una firma— y pusimos un KMS detrás. Ahora la clave se genera dentro del motor transit de Vault y nunca se exporta. La aplicación no la posee; envía a la bóveda los bytes que hay que firmar y recibe de vuelta una firma. Puede usar la clave, pero no puede exfiltrarla.

Esa distinción es todo el quid del asunto. Un volcado de memoria, un archivo de configuración derramado, una copia de seguridad filtrada: ninguno de ellos contiene ya la clave, porque la clave nunca estuvo en ninguno de esos lugares. Comprometer la aplicación ahora le compra al atacante la capacidad de pedirle a la bóveda que firme, algo que podemos limitar por tasa, auditar y revocar. Ya no le compra la clave en sí, que era algo sobre lo que no podíamos hacer nada una vez que desaparecía.

Aquí viene la parte que no incluimos en las notas de la versión. El mismo commit que trasladó la clave a la bóveda también, sin hacer ruido, redujo a la mitad nuestro número de iteraciones de PBKDF2, de 100.000 a 50.000. Un solo diff, dos cambios de seguridad que apuntaban en direcciones opuestas: el titular era «firmar en el KMS», y viajando por debajo iba un factor de trabajo de hash de contraseñas reducido a la mitad, en una línea que nadie miraba porque la historia trataba de otra cosa. Ambos son código de seguridad, así que ambos se revisaron como un único cambio «más seguro» y se aprobaron sin más gracias a la solidez de la mitad buena.

La corrección fue de una línea. La lección no. Un diff etiquetado como más seguro sigue siendo un diff, y las constantes sensibles a la seguridad que contiene —número de iteraciones, tamaños de clave, tiempos de espera, nombres de algoritmos— no heredan una aureola del mensaje del commit. Ahora tratamos un número de factor de trabajo igual que tratamos la elección de un algoritmo: algo que se afirma y se verifica, no algo en lo que confías porque el cambio que lo rodeaba era una buena idea.

Vida tres: la clave que se hizo más pequeña para ser más rápida

Con la firma detrás de un KMS, cada firma es un viaje de ida y vuelta por la red, y firmar con RSA es de las operaciones caras. Así que la clave cambió de especie: RS256 sobre RSA-2048 pasó a ser ES256 sobre la curva P-256. Firmar con curva elíptica es aproximadamente un orden de magnitud más barato que con RSA, una firma P-256 ocupa 64 bytes donde la de RSA-2048 ocupa 256, y el conjunto de claves públicas que descargan los validadores encoge en consecuencia. Clave más pequeña, firma más pequeña, JWKS más pequeño, tokens más rápidos: todo por elegir una curva mejor.

La trampa es que no puedes cambiar de golpe el algoritmo de firma en un emisor en producción. Todos los tokens ya emitidos se firmaron con RS256 y tienen que seguir validándose hasta que caduquen. Cada validador tiene cacheada tu clave pública antigua. Cambia el algoritmo de un solo movimiento e invalidarás, en el mismo instante, todos los tokens en circulación y todos los conjuntos de claves cacheados: una caída autoinfligida disfrazada de mejora.

Lo que funcionó fue dejar de fingir que alguna vez hubo una sola clave. El almacén de claves se volvió agnóstico respecto al algoritmo: mantiene la clave RSA y la clave EC al mismo tiempo, y publica ambas en el JWKS, cada una bajo su propio identificador de clave y su propio algoritmo. Un selector de clave activa, independiente, decide qué clave firma los nuevos tokens, y se aparta por sí solo de la vieja clave RSA en el momento en que existe una clave EC: sin ninguna opción de configuración, sin ningún despliegue programado para coincidir con una rotación. Durante el solapamiento, el documento de discovery anuncia ambas claves públicas, de modo que los tokens firmados con cualquiera de las dos siguen validándose. Una vez que ha caducado el último token RS256, discovery anuncia solo ES256 y la validación fija ValidAlgorithms = ES256, lo que además le cierra la puerta en las narices a los ataques de confusión de algoritmo que intentan convencer a un validador de que acepte el esquema equivocado. La migración es un fundido cruzado que el emisor realiza sobre sí mismo, no un interruptor que alguien acciona.

La lección, factorizada

Una clave de firma parece una constante: un secreto, establecido una vez, referenciado para siempre. La nuestra no lo era. A lo largo de su vida cambió de custodia, del proceso a un KMS, y cambió de especie, de RSA a curva elíptica, y ambas mudanzas hubo que hacerlas con tokens en circulación y validadores cacheando cosas que no nos pertenecen. La propiedad que hizo sobrevivible cada mudanza fue la misma en ambas ocasiones: el sistema nunca dio por sentado que hubiera exactamente una clave, un algoritmo o un hogar. Construye el almacén de claves para que albergue varias claves y para que anuncie con honestidad cuáles alberga, y la rotación —de dónde vive la clave o de qué tipo de clave se trata— deja de ser una caída que programas y se convierte en una propiedad que el emisor gestiona por su cuenta.

Si gestionas la autenticación, aquello que firma tus tokens debería ser el objeto más aburrido, más inspeccionable y menos ingenioso que poseas. Al nuestro le hicieron falta tres vidas para llegar ahí. Valió la pena cada una de ellas.

The three lives of my JWT signing key

authagonal — Fri, 17 Jul 2026 05:02:08 +0000

One private key signs every token our auth server issues. Lose it and an attacker mints a valid token for any user, no password required, and your logs show a clean login. It is the single most valuable secret in the system, and over its life it has moved twice: it was born inside the application process, then exiled to a vault it can no longer leave, then reincarnated as a different kind of key entirely. Each move happened on a live issuer with tokens already in flight and validators caching state we don't control. This is what those moves actually take, and the one that taught us the most was the one we didn't announce.

Life one: the key the server kept in its pocket

In the beginning the key lived where it was used. The server generated an RSA-2048 key, held it in memory, and signed its tokens with RS256. This is the default almost everywhere, and it is fine right up until you say the word custody out loud. The private key was reachable by anything that could read the process's memory, its configuration, or a backup of either. We wanted to be able to tell customers that a leaked database exposes nothing useful, and a signing key sitting one process away from that database made the claim a lie. The key had to leave the building.

Life two: the key that moved into a vault it can't leave

We introduced a seam — an ISignatureProvider the server calls whenever it needs a signature — and put a KMS behind it. The key is now generated inside Vault's transit engine and never exported. The application doesn't hold it; it sends the bytes to be signed to the vault and gets a signature back. It can use the key and it cannot exfiltrate it.

That distinction is the whole point. A memory dump, a spilled config file, a leaked backup — none of them contain the key anymore, because the key was never in any of those places. Compromising the application now buys an attacker the ability to ask the vault to sign, which we can rate-limit, audit, and revoke. It no longer buys them the key itself, which we could do nothing about once it was gone.

Here is the part we didn't put in the release notes. The same commit that moved the key into the vault also quietly halved our PBKDF2 iteration count, from 100,000 down to 50,000. One diff, two security changes pointing in opposite directions: the headline was "sign in the KMS," and riding underneath it was a password-hashing work factor cut in half, in a line nobody was looking at because the story was about something else. Both are security code, so both got reviewed as a single "more secure" change and waved through on the strength of the good half.

The fix was one line. The lesson wasn't. A diff labelled more secure is still a diff, and the security-sensitive constants inside it — iteration counts, key sizes, timeouts, algorithm names — don't inherit a halo from the commit message. We now treat a work-factor number the same way we treat a choice of algorithm: something asserted and checked, not something you trust because the surrounding change was a good idea.

Life three: the key that got smaller to get faster

With signing behind a KMS, every signature is a network round-trip, and RSA signing is the expensive kind. So the key changed species: RS256 over RSA-2048 became ES256 over the P-256 curve. Elliptic-curve signing is roughly an order of magnitude cheaper than RSA, a P-256 signature is 64 bytes where RSA-2048's is 256, and the public key set validators download shrinks accordingly. Smaller key, smaller signature, smaller JWKS, faster tokens — all from picking a better curve.

The catch is that you cannot flip-swap the signing algorithm on a live issuer. Every token already issued was signed RS256 and has to keep validating until it expires. Every validator has your old public key cached. Change the algorithm in one move and you invalidate every token in flight and every cached key set at the same instant — a self-inflicted outage dressed up as an upgrade.

What worked was to stop pretending there was ever only one key. The key store went algorithm-agnostic: it holds the RSA key and the EC key at the same time, and publishes both in the JWKS, each under its own key id and algorithm. A separate active-key picker decides which key signs new tokens, and it rotates itself off the legacy RSA key the moment an EC key exists — no config flag, no deploy timed to line up with a rotation. Through the overlap, discovery advertises both public keys, so tokens signed with either one keep validating. Once the last RS256 token has expired, discovery advertises only ES256 and validation pins ValidAlgorithms = ES256, which also slams the door on algorithm-confusion attacks that try to talk a validator into accepting the wrong scheme. The migration is a crossfade the issuer performs on itself, not a switch anyone throws.

The lesson, factored out

A signing key looks like a constant: one secret, set once, referenced forever. Ours wasn't. In its life it changed custody, from the process to a KMS, and it changed species, from RSA to elliptic curve, and both moves had to be made with tokens in flight and validators caching things we don't own. The property that made each move survivable was the same one both times: the system never assumed there was exactly one key, one algorithm, or one home. Build the key store to hold several keys and to honestly advertise which ones it holds, and rotation — of where the key lives or of what kind of key it is — stops being an outage you schedule and becomes a property the issuer manages on its own.

If you run auth, the thing that signs your tokens should be the most boring, most inspectable, least clever object you own. Ours took three lives to get there. It was worth every one.

If you would rather your signing key were already boring, inspectable, and rotated for you, that is the job Authagonal does, so yours never needs a fourth life.

The SAML signature was valid. That was never the problem.

authagonal — Thu, 16 Jul 2026 02:56:30 +0000

SAML single sign-on has a replay problem built into its shape, and most service providers "solve" it in the one place an attacker can reach.

Here is the setup. You are the service provider. A user lands on your login, you send an AuthnRequest to their identity provider, and that request carries a random ID. The IdP authenticates the user and posts back a SAML Response with InResponseTo="<that ID>". You look up the ID, confirm you actually issued it, and consume it so it can never be used twice. Request bound to response, response used once, replay defeated. Textbook.

Now the question that breaks it: what did the IdP actually sign?

Not the Response. The Assertion. Entra, Okta, most of the field sign the <Assertion> element and leave the <Response> envelope around it unsigned. That is normal, and the spec allows it. But InResponseTo lives on the <Response>. So the field your entire replay defense keys off is the one field the signature does not cover. You can edit it, delete it, do whatever you like to it, and the assertion's signature still validates perfectly, because you never touched the assertion.

So watch what happens when an attacker does the obvious thing.

SAML has two flavors. SP-initiated responses answer a request you sent, so they carry InResponseTo. IdP-initiated (unsolicited) responses were never asked for, so they have no InResponseTo at all. Your code, reasonably, branches on this: if there is an InResponseTo, match it to a stored request and consume it; if there is not, there is no request to match, so it skips that check. That skip is the whole vulnerability.

The attack is three steps and zero cryptography:

Capture one real, successful SAML Response. A genuine login, a genuine signature, a genuine assertion.
Delete the InResponseTo attribute. The signature covers the assertion, not the envelope, so it still verifies.
Post it back. With no InResponseTo, your SP treats it as IdP-initiated, takes the branch with no replay check, validates the signature (valid), and logs the user in.

Then post it again. And again. The assertion is a skeleton key now. Every check you were proud of still passes: signature valid, certificate pinned, issuer correct, conditions in date. The one control that would have stopped a replay was keyed to a field the attacker deletes for free.

Here is the trap in one line: you signed the assertion, but you gated on the envelope.

The fix is not more validation. It is validating the right thing. Stop keying replay protection off InResponseTo, which is unsigned and optional, and key it off the assertion's own ID, which is signed and always present. Every assertion has an ID, it sits inside the signature, and tampering with it breaks verification. Keep a one-time-use cache of assertion IDs, bounded by each assertion's NotOnOrAfter so the cache never grows without limit, and reject any ID you have already seen. Now deleting InResponseTo buys the attacker nothing, because the value you actually check cannot be forged and cannot be replayed.

While you are in there, treat the request binding as defense in depth rather than the primary control. Still match InResponseTo when it is present. Still reject unsolicited responses outright if you never offer IdP-initiated login. Still enforce Audience and the Conditions window. But the load-bearing anti-replay check has to sit on signed bytes, full stop.

We know this one because we found it auditing our own SAML before we launched, not because a customer found it afterward. And the lesson generalized well past SAML. A signature answers exactly one question: did the holder of this key produce these bytes. It does not tell you the bytes are fresh, that they were meant for you, or that you have not already accepted them once. Those are three separate checks, and every one of them has to read a field the signature actually covers. The moment a security decision depends on data sitting outside the signature, it stops being a security decision and becomes a polite request that an attacker is free to decline.

Sign the field you gate on, or gate on the field that is signed. There is no third option that survives a replay.

If you would rather not hand-roll SAML validation and get the replay case wrong, that is a good reason to let someone else run it. Authagonal keys replay off the signed assertion ID, so stripping InResponseTo goes nowhere.