Curity Identity Server 11.2 tightens runtime authorization at token issuance

At a glance

What this is: Curity Identity Server 11.2 introduces token issuance authorizers, a plugin model for making access decisions at the moment a token is issued.

Why it matters: For IAM and NHI practitioners, this matters because it moves part of the control point closer to runtime context, which can reduce standing assumptions in token-based access.

👉 Read Curity's release notes for Identity Server 11.2 and runtime authorization changes

Context

Token-based access becomes harder to govern when policy decisions are fixed too early and reused too broadly. In NHI and IAM environments, the real issue is not just who authenticated, but whether the scope granted still matches current context at the moment access is created. Curity's 11.2 release is a useful trigger for examining that gap in token issuance design.

Runtime authorization is especially relevant where service accounts, delegated clients, and AI agents consume tokens across multiple systems. As environments scale, static policy logic can become a source of overreach rather than control. That is why token issuance, revocation linkage, and session logout now sit much closer to the center of NHI governance than many teams assume.

Key questions

Q: How should security teams apply runtime authorization to token issuance in multi-application environments?

A: Security teams should place policy checks at the issuer, not only at the application, for scopes that carry meaningful risk. The decision should use current context, grant type, and downstream impact so the same entitlement is not approved blindly across every request path. That keeps token creation aligned with live conditions instead of stale configuration.

Q: When does static scope configuration become a governance problem for NHIs?

A: Static scope configuration becomes a problem when the same scope can be issued under different conditions, different clients, or different grant types without re-evaluating risk. At that point the control is describing intent, not enforcing context. For NHIs, that creates overprivilege and makes audit evidence weaker because access was approved once and reused too broadly.

Q: What breaks when delegation revocation is not tied to client deletion?

A: If delegation is not revoked when the client is deleted, the trust relationship can persist even though the owning object no longer exists. That leaves a residual path for token use, refresh, or downstream access that administrators may assume is gone. The failure mode is stale authority, which is hard to detect and easy to overlook in large identity estates.

Q: How can teams tell whether front-channel logout is actually working across applications?

A: Teams should test whether sign-out in one application invalidates the user session everywhere the identity session is reused. If applications remain usable after logout, the control is partial and users may retain access longer than intended. The best signal is consistent session termination across browsers, tabs, and dependent apps after a single logout event.

How it works in practice

Token issuance authorizers and runtime policy evaluation

Token issuance authorizers are a plugin pattern that evaluates authorization at the point a token is minted rather than only at login or client registration. That matters because scope, grant type, and runtime context can all change between initial authentication and token creation. By inserting policy logic into issuance, the access decision can consider external systems, current state, and scope-specific rules. The architectural shift is from static entitlement assignment toward contextual approval at the moment privileges become usable.

Practical implication: teams should treat token issuance as an active policy enforcement point, not a passive token factory.

Per-scope authorization across grant types

Per-scope controls tighten the relationship between requested access and approved access. In OAuth-based architectures, a token can carry multiple scopes, and different grant types may reach the issuer through different paths, which creates inconsistency if policy is only applied once. Applying rules per scope across all grant types helps normalize the decision model and reduces the chance that one request path becomes a weaker control surface. The real gain is consistency, especially when multiple applications and delegated flows share the same issuer.

Practical implication: map high-risk scopes to explicit approval logic and verify that every grant flow reaches the same policy gate.

Delegation revocation and front-channel logout as control hygiene

Delegation revocation and front-channel logout address a common weakness in token ecosystems: access that persists after the underlying relationship has changed. When a client is revoked or deleted, related delegations need to be invalidated as well or tokens can outlive the trust relationship that created them. Front-channel logout extends that discipline to user sessions by propagating sign-out across applications. These controls do not replace authorization design, but they reduce the window in which stale access remains valid.

Practical implication: align client deletion, delegation cleanup, and session logout so access termination is actually enforced across dependent systems.

NHI Mgmt Group analysis

Token issuance is becoming a governance choke point, not just an authentication step. Once policy can evaluate scope at the instant a token is minted, the issuer effectively becomes part of the authorization plane. That changes how IAM teams should think about trust boundaries, especially when tokens are consumed by service accounts, delegated clients, and AI agents. The practitioner conclusion is straightforward: if issuance is the control point, it needs policy ownership and auditability on par with privileged access.

Dynamic authorization exposes how much risk is hidden in static configuration. Static scope rules assume the same request is equally safe every time, but real environments are not that stable. Device posture, application context, upstream trust, and transaction state can all change between requests. The practical result is that teams need to re-evaluate where policy logic lives and which decisions should be deferred to runtime rather than encoded once and reused indefinitely.

Revocation must be treated as a connected lifecycle event, not a single admin action. When a client is removed, any delegations attached to it should lose authority too, or the organisation keeps a shadow path to access. That is the same governance problem seen in NHI sprawl more broadly: tokens and delegations outlive the relationship that justified them. The practitioner takeaway is to bind access termination to dependency cleanup, not just object deletion.

Access intelligence now belongs inside the token service. The named concept here is the runtime authorization gap: the distance between a static access rule and the live conditions under which access is actually granted. That gap is where overprivilege, stale delegations, and inconsistent grant handling accumulate. Teams that close it early will be better positioned to govern machine access as token ecosystems continue to expand.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• For a deeper control model, see Top 10 NHI Issues for the governance failures that usually sit behind stale privilege and incomplete revocation.

What this signals

Runtime authorization will matter most in environments where machine access is issued repeatedly under changing conditions. The governance question is no longer whether a token was minted correctly once, but whether it should have been minted at all in this specific context. That pushes NHI programmes toward policy ownership, audit logging, and clearer separation between issuance logic and application code.

Ephemeral token governance gap: organisations need a way to prove that short-lived access decisions still reflect current risk. When policy logic is externalised or evaluated at issuance, the control only works if teams can show what data, rule source, and exception path informed the decision. Without that evidence, runtime authorization becomes harder to audit, not easier.

With 97% of NHIs carrying excessive privileges, per Ultimate Guide to NHIs, dynamic issuance controls should be paired with privilege reduction, not treated as a substitute for it. The same environment that needs smarter token decisions usually also needs fewer standing permissions, tighter delegation hygiene, and better lifecycle cleanup. That combination is what closes the gap between policy intent and actual access.

For practitioners

• Map high-risk scopes to runtime policy gates Identify the scopes that can expose sensitive data or downstream administrative actions, then require explicit runtime evaluation at issuance for those scopes across all supported grant types.
• Treat delegation cleanup as part of revocation When a client is removed or disabled, verify that related delegations, refresh paths, and downstream grants are invalidated together so access does not survive through attached relationships.
• Review session logout across dependent applications Confirm that front-channel logout or an equivalent sign-out flow propagates across applications that rely on the same identity session, especially where shared tokens or browser sessions persist.
• Document external policy dependencies If token issuance relies on external systems or policy sources, define ownership, failure handling, and audit evidence for each dependency before placing it in the critical path.

Key takeaways

• Token issuance is shifting from a passive minting step to a real authorization control point.
• Stale delegations and client lifecycle gaps can preserve access even after administrators believe it has been removed.
• Runtime policy, revocation hygiene, and logout consistency need to be designed as one governance system, not separate features.

Key terms

• Token Issuance Authorizer: A Token Issuance Authorizer is a policy component that decides whether a token should be issued and what it may contain. It evaluates authorization at issuance time, which lets teams use current context, scope, and external signals instead of relying only on static configuration.
• Delegation Revocation: Delegation revocation is the process of removing access that was granted through an intermediate client, service, or delegated relationship. In NHI environments, it matters because deleting one object does not always remove the access paths attached to it, leaving residual authority behind.
• Front-Channel Logout: Front-channel logout is a sign-out pattern that propagates session termination through the browser to connected applications. It helps reduce the chance that one application ends a session while other relying apps continue to accept the same identity context.
• Runtime Authorization Gap: The runtime authorization gap is the distance between a policy that looks correct in configuration and the live conditions under which access is actually granted. It appears when decisions are made too early, reused too broadly, or fail to reflect current context at token issuance.

Deepen your knowledge

Runtime authorization and NHI lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building policy controls for token issuance and delegation cleanup, it is worth exploring.

This post draws on content published by Curity: Identity Server 11.2 release notes. Read the original.