Notifications
Clear all
Topic starter
06/07/2026 9:36 am
TL;DR: API examples show how teams can apply OAuth tokens, JWT validation, client assertions, and mTLS across common languages and frameworks to secure APIs, serverless functions, and event-driven integrations, according to Curity. The practical message is that API security still depends on explicit identity controls, not framework convenience.
NHIMG editorial — based on content published by Curity: API security coding examples for OAuth, JWTs, and related patterns
Questions worth separating out
Q: How should security teams govern OAuth-secured APIs across multiple languages and frameworks?
A: Start by standardising the identity rules, not the code samples.
Q: When does a bearer token create too much risk for API access?
A: Bearer tokens become high risk when the API protects sensitive data, supports privileged actions, or runs in distributed systems where interception or replay is plausible.
Q: What do teams get wrong about JWT-based API security?
A: The common mistake is treating JWT validation as the full security control.
Practitioner guidance
- Map every API to an explicit identity trust model Classify each API by caller type, token type, validation point, and whether the service accepts bearer tokens, client assertions, or mTLS.
- Separate authentication proof from authorisation scope Check that JWT validation, scope enforcement, and business permissions are not being treated as the same control.
- Harden machine-to-machine access with stronger caller proof Prefer client assertions or mutual TLS where replay risk or token exposure would create excessive blast radius.
What's in the full article
Curity's full article covers the operational detail this post intentionally leaves for the source:
- Concrete code examples for securing APIs in Java, .NET, Python, Go, Kotlin, Node.js, Spring Boot, Symfony, and Flask.
- Implementation patterns for JWT validation, OAuth request authorisation, client assertions, and mutual TLS in real application code.
- Serverless and event-driven examples showing how identity checks work at invocation and message boundaries.
- Architecture and customer-story material that helps teams translate the patterns into larger identity and API designs.
👉 Read Curity's API security examples for OAuth, JWTs, and client assertions →
OAuth API security coding examples: what IAM teams need?
Explore further
06/07/2026 9:50 am
API security is an identity problem before it is an application problem. These examples show that the control surface is not the endpoint language, but the identity evidence attached to each request. JWTs, OAuth scopes, client assertions, and mTLS are all ways of expressing trust in machine traffic. The practitioner conclusion is that API protection only holds when identity rules are explicit enough to survive framework changes.
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 GitGuardian.
A question worth separating out:
Q: How do serverless APIs change identity governance requirements?
A: Serverless systems make identity decisions more granular because each invocation is short-lived and frequently chained to events or messages. Teams need to verify that identity context survives correctly across hops, and that every boundary reasserts the right caller, audience, and expiry conditions.
👉 Read our full editorial: OAuth API security coding examples for JWT-secured APIs
