Notifications
Clear all
Topic starter
06/06/2026 11:21 am
TL;DR: JWT and OAuth solve different problems, but production systems often blend them in ways that hide authorization gaps, especially in machine-to-machine flows that cannot use browser logins or MFA, according to Aembit. The real issue is that many teams still rely on static secrets and muddled trust boundaries when workload identity needs short-lived, verifiable access.
NHIMG editorial — based on content published by Aembit: JWT vs. OAuth: What’s the Difference?
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should security teams handle workload authentication without relying on client secrets?
A: Security teams should prioritise secretless patterns such as managed identities, workload identity federation, or attestation-based authentication.
Q: Why do JWT and OAuth need to be treated as separate controls?
A: They solve different problems.
Q: What breaks when workloads still use long-lived client secrets?
A: Long-lived client secrets create standing access that can be copied from containers, environment variables, or CI systems and reused outside the intended session.
Practitioner guidance
- Define the token boundary explicitly Separate token format decisions from authorization lifecycle decisions in architecture reviews.
- Eliminate persistent workload secrets where possible Replace client secrets in environment variables and config files with managed identities, attestation, or federation.
- Audit machine-to-machine flows for standing privilege Inventory every service account, token issuer, and refresh path.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of OAuth 2.0 client credentials and token exchange flows in workload environments
- Architecture options for broker and proxy patterns when legacy applications cannot be rewritten
- Operational details on attestation-based authentication and cross-cloud federation
- Implementation guidance for conditional access policies and short-lived access token handling
👉 Read Aembit's analysis of JWT vs. OAuth for workload authentication →
JWT vs. OAuth for workload identity: are your controls keeping up?
Explore further
06/06/2026 12:06 pm
JWT and OAuth confusion creates a governance blind spot, not just a terminology problem. OAuth manages delegated access, while JWT packages claims for validation. When teams collapse those roles into one mental model, they often design controls around the token rather than around issuance, refresh, and revocation. That leaves NHI programmes with good-looking authentication artefacts and weak lifecycle control. Practitioners should treat the split as a governance boundary, not a naming preference.
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.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
A question worth separating out:
Q: How do teams decide between JWT, OAuth, and federated workload identity?
A: Use JWT when you need a signed, self-contained token for local validation. Use OAuth when you need to control access lifecycle across services. Use federated workload identity when you want to eliminate duplicated secrets and support multicloud access with cryptographic proof of runtime identity. In mature designs, the three usually work together.
👉 Read our full editorial: JWT vs. OAuth for workload identity: where controls break
