Notifications
Clear all
Topic starter
22/06/2026 10:11 am
TL;DR: A built-in React login application, new token issuance authorizers, scriptable authorization logic, and support for signed OpenID Connect authorization requests are added in Curity Identity Server 11.3, according to Curity. The release matters because it pushes more authentication and token policy into the identity layer, where teams must balance developer convenience with stronger governance.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
Q: How should IAM teams govern token issuance authorisers in production?
A: Treat token issuance authorisers as policy code, not configuration trivia.
Q: When do built-in login applications create more risk than they remove?
A: They create more risk when teams treat them as cosmetic front ends instead of governed identity controls.
Q: Why do signed OpenID Connect requests matter for access governance?
A: Signed requests matter because they protect the integrity of the authorisation intent between client and identity provider.
Practitioner guidance
- Review login customisation ownership Map which teams can change the built-in login application, then require the same approval and testing controls you use for other authentication changes.
- Inventory token issuance rules Document every global, script, and composite authoriser in use, including the business reason for each rule and the owner responsible for change approval.
- Test signed request handling end to end Validate that signed OpenID Connect requests are accepted only from intended clients and that downstream scope decisions match the signed parameters.
What's in the full announcement
Curity's full post covers the operational detail this analysis intentionally leaves for the source:
- Implementation specifics for the built-in React login application and how it is enabled at different configuration levels.
- Release-note detail on global, script, and composite token authorisers, including how Curity expects them to be combined.
- Developer Portal references for the webinar, trial access, and hands-on evaluation path.
- Technical notes on persistent background jobs, database scopes, and signed OpenID Connect request support.
👉 Read Curity's release notes for Identity Server 11.3 and token control changes →
Curity 11.3 and token authorisation: what changes for IAM teams?
Explore further
22/06/2026 10:59 am
Curity 11.3 is really a governance release, not just a usability release. The built-in React login application matters because it standardises a control point that many teams previously treated as bespoke implementation work. That reduces front-end sprawl, but it also concentrates authentication experience into the identity platform itself. Practitioners should treat the login layer as governed infrastructure with explicit ownership, review, and change control.
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 5.7% of organisations have full visibility into their service accounts, which shows how often identity governance is still blind to the systems it must control.
A question worth separating out:
Q: What should security teams audit after adding composite authorisers?
A: They should audit rule interactions, exception paths, and the ownership model around changes. Composite authorisers can make policy more precise, but they also make failure modes harder to see if conditions are scattered across teams. The key question is whether the organisation can still explain a token decision in plain language after the fact.
👉 Read our full editorial: Curity 11.3 shifts login and token control closer to policy
