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.
At a glance
What this is: This is an overview of token procedure examples that change token endpoint behaviour across OAuth and OpenID Connect flows, with the key finding that policy can shift into issuance, exchange, and refresh decisions.
Why it matters: IAM teams need to understand how these procedures change control points for delegation, lifetime, and token transformation because those decisions affect governance across human, NHI, and API access flows.
Context
Token procedures are a way to alter token endpoint responses inside OAuth and OpenID Connect flows. In practical IAM terms, they move decision points into the token lifecycle itself, where issuance, exchange, and refresh logic can be conditioned on policy.
For identity teams, that matters because the control problem is not only how a token is validated after it exists, but when it should exist, what it can be exchanged into, and whether its lifetime should be extended. This is primarily a token governance and delegation topic, with clear implications for NHI and API access patterns.
Key questions
Q: What breaks when token procedures decide access at the token endpoint?
A: The main failure is control drift. When issuance, exchange, and refresh logic decide who gets a token and how long it lives, teams can lose the clean separation between authentication, authorization, and lifecycle governance. That makes the token endpoint a policy control point, but also a place where misconfiguration can silently widen access.
Q: When should IAM teams prioritise token exchange over stricter token validation?
A: Only when the business problem is cross-system delegation or federation, not when the goal is simply to verify an existing token. Token exchange changes authority boundaries, so it should be used when the receiving system needs a different trust context or audience. If the issue is validation alone, exchange adds complexity without reducing risk.
Q: What are the signs that refresh procedures are creating access creep?
A: Look for tokens that remain usable far beyond the original entitlement review cycle, especially when refresh logic operates with weaker scrutiny than initial issuance. Another warning sign is when teams cannot explain which approval or policy check re-runs at refresh time. That usually means the refresh path has become a hidden access extension channel.
Q: How do token procedures differ from ordinary JWT validation in OAuth and OIDC?
A: JWT validation checks whether a token is syntactically and cryptographically acceptable. Token procedures change the token itself, deciding whether it should be issued, exchanged, or renewed in the first place. That distinction matters because governance problems often live in how authority is created or transformed, not just in how a token is later inspected.
Technical breakdown
Token endpoint procedures as policy enforcement points
Token procedures sit in the token endpoint path and can modify the response that an OAuth or OpenID Connect server returns. That means policy can be evaluated at issuance time, during exchange, or on refresh rather than only at resource access time. In identity architecture terms, this shifts governance closer to the boundary where credentials become usable. The practical effect is that the token service becomes part of the control plane, not just a passive issuer.
Practical implication: map which issuance decisions belong in the token service versus downstream authorization layers.
Token exchange and format transformation
Token exchange, including RFC 8693, lets one token be swapped for another under defined conditions. In the examples here, that includes exchanging an opaque token into a JWT and exchanging external IdP-issued JWTs into a form the local system can accept. The security issue is not the encoding change itself, but the delegation model it creates: the system must decide what authority survives the exchange and what context is lost. That makes token exchange a governance decision, not a purely technical conversion.
Practical implication: constrain which token attributes, audiences, and trust relationships survive exchange.
Refresh procedures and token lifetime extension
Refresh-time procedures change how long access can continue and under what conditions it can be renewed. A long-lived token pattern created through refresh logic can be useful operationally, but it also extends the period during which a compromised or mis-scoped credential remains usable. In IAM terms, this is a lifetime governance problem, because the refresh path may become a second issuance channel with weaker scrutiny than the original login or client authentication step.
Practical implication: review refresh logic as a credential governance control, not just a session convenience feature.
Threat narrative
Attacker objective: The attacker seeks a credential path that preserves usable authority across exchange or refresh while bypassing the narrowest intended control point.
- Entry occurs when a client or external IdP presents a valid token that reaches the token endpoint for procedure-driven handling.
- Policy evaluation or token exchange then determines whether that token is accepted, transformed, or extended into a new credential form.
- Impact follows when the resulting token inherits authority or lifetime that exceeds the intended governance boundary.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Token procedures move authorization-adjacent decisions into the identity issuance path. That is the real design shift in this article. Once issuance, exchange, and refresh are all policy-bearing steps, IAM teams have to govern the token service as part of access control, not as an implementation detail.
Token exchange creates delegation chains that can outlive the original trust decision. An external IdP assertion, an opaque token, and a local JWT are not interchangeable from a governance perspective. Each transformation changes which party is being trusted, which context is retained, and which enforcement point now owns the risk.
Long-lived token behaviour should be treated as lifecycle governance, not convenience engineering. Refresh procedures can silently extend access beyond the review cadence that most identity programmes assume. The practitioner question is whether the refresh path is still aligned to the original entitlement decision, or whether it has become a parallel access grant.
Token format is the wrong primary abstraction for this problem. The more useful control question is where authority is created, transformed, and extended. Curity's examples reinforce that IAM teams need a governance model for token procedures, not just a validation strategy for JWTs.
Token procedure control is now a first-class identity design concern for API and NHI estates. The same control point can govern delegated API access, external federation, and machine-to-machine token handling. Teams that ignore the procedure layer will miss where authority is actually being shaped.
What this signals
Token procedure governance belongs in the same programme tier as federation and lifecycle controls. If a team already manages OAuth, OpenID Connect, and delegated access, it should treat procedure-level issuance and exchange logic as an identity design decision, not as an integration detail. That is where authority is reshaped before downstream services ever see the token.
Governance fatigue often appears when teams over-focus on token type and under-focus on token behaviour. A JWT is not inherently safer than an opaque token, and a refreshable credential is not inherently more convenient if it outlives its review boundary. The durable control question is whether the procedure preserves the intended trust model end to end.
For practitioners
- Map token procedure decision points Document where issuance, exchange, and refresh logic alter authorization outcomes so you can assign ownership to the correct IAM control plane.
- Classify exchange trust boundaries Record which external IdP assertions, opaque tokens, and local JWTs are allowed to survive token exchange and which claims must be stripped or revalidated.
- Review refresh semantics for lifetime creep Test whether refresh procedures extend access beyond the intended entitlement window or bypass the same approval path used at original issuance.
- Separate transport format from governance meaning Treat JWT conversion as a security decision only when it changes audience, delegation, or lifetime. Otherwise keep it as a format detail in the architecture review.
Key takeaways
- Token procedures shift meaningful policy decisions into the token endpoint, where issuance, exchange, and refresh can all alter access governance.
- The article's examples show that delegation boundaries matter more than token format alone, especially when credentials are transformed across systems.
- IAM teams should review procedure-level controls wherever token lifetimes, external federation, or token exchange can expand authority beyond the original trust decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Token procedures alter authentication outcomes at the API token boundary. |
| Recommendation — Audit token-endpoint handling for authentication decisions that should not be delegated to exchange or refresh logic. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Refresh and exchange procedures change authenticator lifecycle handling. |
| IA-9 — Service and Organization-User-Based Authentication | Token procedures support service and workload authentication paths across federated systems. | |
| Recommendation — Apply IA-5 to govern token issuance, renewal, and revocation logic consistently. Use IA-9 to govern non-human token flows where authority is delegated across systems. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Token procedures directly affect how permissions and entitlements are assigned and transformed. |
| Recommendation — Map token issuance and exchange decisions to PR.AA-05 so permissions stay aligned to policy. | ||
| NIST Zero Trust (SP 800-207) | Policy Engine and Enforcement — Policy Engine and Enforcement | Token procedures embody policy decisions inside the identity flow. |
| Recommendation — Place token procedures behind explicit policy enforcement so authority changes remain observable and bounded. | ||
Key terms
- Token Procedure: A token procedure is a programmable step that changes how an OAuth or OpenID Connect token is issued, exchanged, or refreshed. It can add policy checks, rewrite claims, or alter token lifetime, which makes it a governance control point as much as a technical extension.
- Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.
- Refresh Flow: The refresh flow allows a client to obtain a new access token without repeating the original authentication step. It is operationally useful, but it also extends the period during which access can continue, so it must be governed as a credential lifecycle control rather than a convenience feature.
- Delegation Boundary: A delegation boundary is the line that separates what a person, service account, or agent may do directly from what it may do on behalf of someone else. It matters because runtime access should follow the delegated relationship, not expand into broad inherited privilege.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org