Agentic AI Module Added To NHI Training Course

Notifications
Clear all

Token issuance authorizers in Curity 11.2: what changes for IAM teams


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 1681
Topic starter  

TL;DR: Curity Identity Server 11.2 adds Token Issuance Authorizers, letting policies apply per scope across all grant types so access decisions can use runtime context instead of static configuration, while the admin UI, BankID flow, delegation revocation, and front-channel logout also get updates. Runtime authorization at issuance is a governance shift, not just a feature tweak.

NHIMG editorial — what this means for NHI practitioners

Questions worth separating out

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.

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.

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.

Practitioner guidance

  • 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.

That pushes NHI programmes toward policy ownership, audit logging, and clearer separation between issuance logic and application code?

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

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 weeks ago
Posts: 207
 

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.

A few things that frame the scale:

  • 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.

A question worth separating out:

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.

👉 Read our full editorial: Curity Identity Server 11.2 tightens runtime authorization at token issuance



   
ReplyQuote
Share: