Signing Key Domain Separation

A platform issues tokens for consumers and for enterprise tenants, from two identity systems, with two sets of signing keys. A validator in the mail service checks the signature, finds a trusted key, and accepts the token. An attacker who steals one consumer key forges a token that the enterprise side honours. Domain separation means each key is valid for exactly one issuer and audience, and the validator enforces the pairing before it looks at anything else in the token.

Why it matters

A signature proves a key signed the token. It says nothing about whether that key was entitled to speak for this tenant. When validation code is shared across systems and treats all trusted keys as interchangeable, the blast radius of any single key is the whole estate. Microsoft's 2023 Storm-0558 investigation described a consumer-system key being accepted for enterprise email because of a validation flaw, which turned one stolen key into access to about 25 organisations' mailboxes.

Implementation patterns

• Key set per issuer: publish a distinct key set (JWKS endpoint) for each issuer and tenant class, never a combined list.
• Resolve the key from the claimed issuer: read iss, select the key set registered for that issuer, then verify the signature, then check aud, tenant and expiry.
• Key ids with scope metadata, so a key's purpose is checkable (kid plus an allowed-audience table in configuration).
• Short lifetimes and overlap: rotate every 30 to 90 days with one period of overlap; retire old keys from validators when they expire.
• Hardware-backed storage for signing keys, with signing as a service so the key never enters a process that can produce a core dump.
• One shared validation library with a test suite containing cross-domain tokens that must be rejected.

Industry example

Microsoft's 2023 investigation into Storm-0558 (published July and September 2023) described a signing key for the consumer account system being used to forge tokens accepted by enterprise email services, with a library-level validation issue allowing the cross-domain acceptance. Microsoft's response included hardening validation and key management, and the incident reviews that followed treated key scoping and logging defaults as central lessons.

Failure scenarios

• Shared validator, mixed key set: any key signs for any tenant; one theft compromises all.
• Retired key still trusted: an old key stays in the validation set for years because nobody owns removal.
• Fallback on failure: when the key endpoint is unreachable, the validator caches forever or skips verification.
• Audience check omitted, so a token minted for service A is replayed to service B.
• Detection gap: forged tokens verify, so nothing in authentication logs looks wrong; only data-access audit logs reveal it.

Trade-offs

When not to use it

A single-tenant application with one issuer and one audience gains little: checking iss, aud and expiry is enough, and extra keysets are overhead. The pattern pays when several trust domains with different owners share validation code.

Interview question

Q: A token signed by a valid key was accepted by a service it was never meant for. How do you stop recurrence?

What a strong answer covers: validate issuer and audience before trusting any key; bind keys to domains; reject cross-domain tokens in shared-library tests; short lifetimes and removal of retired keys; audit logging that does not depend on a premium tier; and the incident response of revoking the key set and tokens.

Quick check

Quiz: Which check turns a stolen consumer key into a non-event for enterprise services? Resolving the key from the issuer and rejecting a key that does not belong to it.

Flashcard: What does a valid signature not prove? — That the signing key was entitled to speak for this tenant.