How should teams enrich JWT claims without exposing sensitive key material to the identity provider?

Why Claim Enrichment Must Stay Behind Your Trust Boundary

JWT enrichment looks like a simple identity feature, but the security question is where the data used to make token decisions lives. If the identity provider must reach into your databases, secrets, or internal APIs, you expand the trust boundary and create a path for sensitive material to be exposed, logged, or reused outside your control. That is why teams usually want enrichment logic to remain inside their own service layer rather than inside the issuer.

In practice, the key issue is not JWT syntax but control of the inputs that shape the token. Claims often encode roles, entitlements, tenant context, or policy decisions, so the backend that knows the business context should make the decision without handing the identity provider direct access to source systems. Current guidance for secrets handling and identity flows is consistent on one point: minimise who ever sees long-lived credentials, because once the issuer can query downstream systems, those systems are effectively part of the authentication path. A useful reference point is the NHI-focused analysis in Ultimate Guide to NHIs, which explains why machine-facing trust paths need tighter control than ordinary user login flows.

Security teams often discover the weakness only after the enrichment layer has already become a shadow integration to production data stores, not when they first designed the token format.

How Synchronous Webhooks Keep Enrichment Logic Local

The cleanest pattern is to let the identity provider call a synchronous webhook during token minting, then let your backend return only the claims needed for issuance. That design lets the identity provider remain the token authority while your service keeps control over policy, data access, and any sensitive lookups. The webhook can approve, deny, or decorate the token, but it should do so without exposing database passwords, API keys, or internal service tokens to the issuer.

This works best when the webhook is narrow in scope and treated as an authorization decision point, not as a general-purpose data broker. The backend can read internal context, apply business rules, and return a minimal claim set such as tenant, entitlement tier, or feature flags. If the decision requires multiple data sources, aggregate them behind your own service so the identity provider never becomes the place where credentials are collected, cached, or replayed. For teams building on machine-identity patterns, NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities is useful because it clarifies why token issuance and downstream trust should be separated from secret custody.

A practical implementation sequence is: validate the request context, look up only the minimum required entitlement data, return claims with the shortest useful lifetime, and fail closed if the backend cannot make a trustworthy decision. The main tradeoff is latency and availability, because synchronous enrichment turns token issuance into a dependency on your service. Teams often underestimate that dependency until peak login traffic, cache misses, or an internal outage begins delaying sign-in. The most relevant external control perspective is NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access mediation and system boundary protection matter. These controls tend to break down when the webhook becomes a high-latency orchestration layer instead of a minimal policy check.

Common Variations and Edge Cases

Tighter enrichment usually improves security, but it also increases coupling, so teams need to balance token precision against login resilience. Not every claim deserves real-time lookup. Static or slow-changing attributes are often better sourced from precomputed profiles, while high-risk entitlements or tenant-scoped access decisions are the strongest candidates for synchronous evaluation.

There is no universal standard for how much should be computed at issuance versus cached ahead of time. Current practice suggests treating anything that depends on live privilege, recent policy change, or sensitive source data as a real-time decision, while keeping low-risk presentation claims out of the critical path. If the webhook must touch secrets-managed systems, the service account used by that webhook becomes part of the security boundary and should be rotated, monitored, and limited to the exact data path needed. The broader pattern is the same one highlighted in NHIMG’s The State of Secrets in AppSec: secret sprawl and slow remediation turn small design choices into persistent exposure.

Teams should also be careful not to let claim enrichment become a substitute for authorization. A claim is only as trustworthy as the policy decision behind it, and if the backend is not authoritative for the data it returns, the token can encode stale or overbroad access. That is especially true in multi-tenant systems, federated environments, and agentic workflows where a token may be replayed by services rather than humans.

Risk and Threat Considerations

The material risk is credential and trust-boundary expansion. Once the identity provider is allowed to reach internal data stores directly, the enrichment path can expose sensitive key material, create new lateral movement opportunities, or leak privileged context into logs and diagnostics.

Failure mechanism: The webhook pattern fails when teams over-permission the integration, cache secrets in the issuer-side workflow, or return claims derived from overly broad backend access. An attacker who compromises the enrichment service, intercepts its credentials, or abuses its data access can then influence token content or harvest the same internal data the issuer was never meant to see.

Impact: The likely consequences are token forgery by policy abuse, exposure of database credentials or API keys, and wider blast radius if the identity provider becomes a bridge into internal systems instead of a controlled issuance boundary.

Practitioner Guidance

What to prioritise: Treat the enrichment service as a security-sensitive policy component, not an integration convenience. Its first job is to keep sensitive source systems out of the identity provider’s trust path.

What to verify: Confirm that the webhook can read only the data needed for claim construction, that it returns the smallest workable claim set, and that any failure mode is fail-closed rather than “issue anyway.”

Decision rule: If a claim requires live access to secrets, privileged databases, or tenant-scoped business data, keep the decision inside your backend and do not hand that retrieval logic to the issuer.

What practitioners underestimate: The real hazard is not just secret exposure; it is the creation of a second privilege path whose outages, logs, and retries can all become part of the attack surface.

Practitioner takeaway: The safest enrichment design is the one that lets the issuer consume a decision, not a dependency, so sensitive material stays inside the backend that already owns it.

Related resources from NHI Mgmt Group

• How should teams evaluate identity verification vendors without relying on sales claims?
• How should security teams implement GraphQL authorization without exposing sensitive fields?
• How should security teams deploy phishing-resistant passkeys in regulated environments without relying on a cloud identity provider?
• How should security teams enable secure collaboration without exposing sensitive data across internal teams and external partners?