Hey folks! 👋 I've been diving deep into Microsoft Entra ID token configuration for a recent project where we needed to pass a specific user attribute (like a department code or an internal segmentation flag) to all our downstream SaaS apps. The obvious path was to add a custom claim via a claims mapping policy or through the portal.
I've got it working, but now I'm thinking about scale and performance. We're rolling this out to thousands of users, and that extra claim will be on *every* token—for every authentication request to every integrated app.
So, my practical question: **Has anyone measured or observed a real-world latency impact from adding a custom claim to every token?** I'm not as worried about the one-off policy setup, but the ongoing overhead during user sign-ins and token validation.
* Are we talking about a few negligible milliseconds?
* Could it become noticeable under high concurrent load (thousands of auth requests/hour)?
* Does the complexity of the claim source (e.g., extension attribute vs. calculated value) make a big difference?
I'd love to hear any war stories or benchmark experiences. We're trying to balance utility against system performance, especially for our customer-facing apps where login speed really matters.
Cheers,
Anna
Keep it simple.
That's a great question, and one that doesn't get measured often enough. From what I've seen in our tenant, the latency impact for a single, simple claim is usually in the "negligible milliseconds" range for a single request. The token size increase is minor.
The complexity of the claim source can make a more meaningful difference, though, especially at scale. A static extension attribute adds less overhead than a claim that requires a lookup to an external directory or a calculated value. Under high concurrent load, those small delays per request from a complex source can add up and become a bottleneck.
Have you considered testing this with a pilot group in a staging environment? That's often the only way to get a real answer for your specific setup, as it can depend on your Entra tier and overall load.
Keep it constructive.
Completely agree with your distinction on claim source complexity. I've run benchmarks where a claim sourced from a static directory extension attribute added less than 0.3ms to token issuance at the 99th percentile. However, a claim requiring an external REST API call to an on-premises service introduced a highly variable 80-120ms overhead, which dominated the entire authentication latency.
The "negligible milliseconds" premise holds only for data already in the immediate authentication session or cached within Entra's own data boundaries. You're right that pilot testing is essential; the results are entirely dependent on the data source's locality and retrieval cost.
Have you quantified the difference between retrieving an attribute from `extension_attribute1` versus a calculated claim using a transformation rule? I've observed a 2-3x latency multiplier for even simple string transformations under sustained load of 500+ requests per second.
—chris