Notifications
Clear all
Topic starter
05/07/2026 10:44 pm
TL;DR: Teams can customize token contents, issue scopes dynamically, and use token exchange, verified claims, and impersonation to control authorization in API-driven architectures, according to Curity. The key issue is not token formatting but how much authority is embedded in tokens at issuance time.
NHIMG editorial — based on content published by Curity: Tokens and Claims
Questions worth separating out
Q: How should security teams govern custom claims in API tokens?
A: Security teams should treat custom claims as governed access inputs, not convenient metadata.
Q: When should token exchange be used instead of passing the original token?
A: Token exchange makes sense when the downstream service needs a narrower audience, a different trust context, or a fresh token with reduced scope.
Q: What do teams get wrong about impersonation flows?
A: Teams often underestimate how easily impersonation blurs accountability.
Practitioner guidance
- Map token claims to decision authority Document which claims are merely descriptive and which are allowed to drive authorization decisions in APIs, then require explicit approval for any claim that changes access scope.
- Separate issuance-time and runtime controls Use token issuance logic for coarse eligibility checks and keep sensitive, fast-changing decisions in runtime policy evaluation so stale assertions do not outlive their context.
- Trace delegation provenance end to end Log original subject, exchanging actor, target audience, and justification for token exchange or impersonation so security teams can reconstruct who acted on behalf of whom.
What's in the full article
Curity's full tutorial set covers the operational detail this post intentionally leaves for the source:
- Step-by-step configuration examples for token issuance authorizers and claim rules
- Implementation guidance for token exchange and impersonation flows in Curity Identity Server
- Tutorial-level examples for verified claims, identity assurance, and custom claim providers
- Configuration patterns for per-client custom token issuers and claim testing
👉 Read Curity's tutorial set on token claims, exchange, and authorization control →
Token claims in APIs: what does tighter authorization control change?
Explore further
05/07/2026 10:47 pm
Token claims are an authorization policy surface, not just a transport detail. Once scopes and claims are used to make downstream decisions, token design becomes part of the control plane. That means governance has to cover who can assert claims, which claims are authoritative, and when token contents should be re-evaluated. Practitioners should treat claim design as an access model decision, not a formatting choice.
A few things that frame the scale:
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 91% of former employee tokens remain active after offboarding, which shows how quickly delegated authority can outlive its original purpose.
A question worth separating out:
Q: How do you know if token claims are too trusted by APIs?
A: A practical warning sign is when APIs accept claims as if they were permanent identity facts, especially for roles, entitlements, or sensitive attributes. If changing the upstream claim source would silently change access across many services, the architecture is overdependent on token contents and underdependent on policy.
👉 Read our full editorial: Token claims and authorization control in APIs
