Case Study
← All case studiesSignature Validation Telemetry in IdentityModel
PR #3410 was not a hardcoded-authority bug. It added telemetry around JWT and SAML signature validation, including issuer allowlisting, key/algorithm dimensions, and refactoring validation methods so they could record telemetry.
29
files changed
2,250
lines touched
5
telemetry dimensions
What changed
The PR introduced telemetry tracking for JWT and SAML signature validation. It records dimensions such as library version, token algorithm, key algorithm, issuer bucket, and validation error. To do that, several validation paths were refactored from static helpers toward instance methods that can access a telemetry client.
The issuer dimension is intentionally controlled by CryptoTelemetry.TrackedIssuers. Hosts not on the allowlist are reported as otherto avoid unbounded metric-cardinality growth.
Why this is risky
Signature validation is a security-critical path. Even when telemetry is meant to be observational, threading a telemetry client through validation changes call shape, exception paths, and performance characteristics. Reviewers need to confirm that failures still fail closed and that success/failure semantics do not change.
Telemetry dimensions also become production contracts. If issuer values are not tightly bucketed, a validation endpoint can generate high-cardinality metrics or accidentally expose arbitrary tenant/issuer hostnames to downstream telemetry systems.
What the original thin page got wrong
The old case study said the PR introduced a hardcoded login.microsoftonline.comauthority URL in production validation code. The verified PR does not support that. The string appears as an issuer-host example in telemetry documentation, not as a production authority override.
The accurate case study is still valuable: it shows how observability work in a cryptographic validation path should be reviewed for semantic preservation, privacy, performance, and cardinality.
Diff evidence
Accurate review signals
[GCI0055/GCI0003] Review signal Signal : validation method signatures and call paths changed while telemetry was threaded through Concern : token validation is security-critical; observability changes must not change validation semantics Telemetry cardinality review Signal : new issuer/algorithm/key/error dimensions and global tracking knobs Concern : ensure allowlisting prevents unbounded cardinality and avoids leaking arbitrary issuer hosts
Important context
- This is not a GCI0010 hardcoded-configuration case; the previous framing was inaccurate.
- The telemetry issuer allowlist is an explicit mitigation, so the review question is whether it is wired safely, not whether issuer tracking is inherently wrong.
- Benchmarks in the PR body report low overhead, but validation-path changes still deserve focused review because the code is security-critical.
Recommended review steps
- Verify telemetry remains disabled or bounded by default and cannot emit arbitrary issuer hosts.
- Review validation tests for success, signing-key-not-found, unsupported algorithm, and verification-failure paths after the refactor.
- Confirm global telemetry knobs and caches are thread-safe and safe for multi-tenant services.
Sources
Eric Cogen -- Founder, GauntletCI
Eric Cogen is a senior .NET engineer with twenty years in production. He has shipped payments systems, internal platforms, and critical line-of-business applications — the kind where a 2 a.m. alert wasn't an emergency, it was a regular Tuesday. GauntletCI is the pre-commit checklist he wishes he had run before every commit.