Notifications
Clear all
Topic starter
06/07/2026 9:40 am
TL;DR: Token procedure examples show how token endpoint logic can alter OAuth and OpenID Connect responses across AuthZEN-based issuance decisions, external IdP token exchange, opaque-to-JWT exchange, and refresh-time extensions, according to Curity. The governance question is no longer token format alone, but where policy, delegation, and lifetime decisions sit in the identity flow.
NHIMG editorial — based on content published by Curity: Token procedure example implementations
Questions worth separating out
Q: How should security teams govern token exchange in federated identity flows?
A: Security teams should treat token exchange as a trust decision, not a protocol convenience.
Q: When does refresh token design become a governance problem?
A: Refresh token design becomes a governance problem when renewal outlives the access conditions that justified it.
Q: What do IAM teams get wrong about opaque token to JWT exchange?
A: Teams often focus on format conversion and miss the trust boundary.
Practitioner guidance
- Map every token procedure to a control owner Document whether issuance, exchange, claim transformation, and refresh logic are owned by identity engineering, platform teams, or application teams.
- Separate token format changes from trust decisions Treat opaque-to-JWT conversion as a different control from issuer and audience validation.
- Bind refresh rules to lifecycle events Revocation, role change, partner offboarding, and risk elevation should all narrow or stop refresh behaviour.
What's in the full article
Curity's full article covers the operational detail this post intentionally leaves for the source:
- Example implementations of token procedure plugins across multiple OAuth and OpenID Connect flows.
- The mechanics of issuing or rewriting tokens at the token endpoint for different integration patterns.
- Implementation detail for exchanging opaque tokens into JWTs and handling external IdP-issued JWTs.
- An AuthZEN PDP example that shows how token issuance decisions can be tied to policy checks.
👉 Read Curity's example implementations of token procedures for OAuth and OpenID Connect →
Token procedures and token exchange: what IAM teams need to know?
Explore further
06/07/2026 9:55 am
Token procedures turn the token endpoint into a governance decision point. Once issuance, exchange, and refresh logic are adjustable, the identity platform is no longer only authenticating subjects. It is also deciding how trust is shaped, narrowed, or translated across contexts. That matters because downstream services often assume token semantics are stable, when in fact a procedure may have transformed the token before it ever arrived at the API.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How can organisations tell whether token procedures are too permissive?
A: A token procedure is probably too permissive if it can issue, exchange, or refresh access without a clear policy owner and an audit trail that explains why the decision was made. Another warning sign is when downstream systems assume token semantics are stable even though the token endpoint can rewrite them.
👉 Read our full editorial: Token procedures in OAuth and OIDC: what they change for IAM
