Notifications
Clear all
Topic starter
06/07/2026 9:35 am
TL;DR: When APIs, apps, and constrained devices need delegated access without credential sharing, ephemeral clients, mutual TLS, sender-constrained tokens, PKCE, revocation, and device flow are the controls that matter, according to Curity. The real governance issue is that OAuth still depends on strong client identity, token binding, and lifecycle discipline, not just flow selection.
NHIMG editorial — based on content published by Curity: OAuth 2.0, client metadata, mutual TLS, and token hardening guidance
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
- 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 govern OAuth clients as identities?
A: Security teams should inventory OAuth clients, assign owners, define scopes, and require explicit revocation paths.
Q: Why do bearer tokens create more risk in API-heavy environments?
A: Bearer tokens create more risk because anyone in possession of the token can use it unless the token is bound to the client or context that received it.
Q: When should organisations choose mutual TLS over standard OAuth token handling?
A: Organisations should choose mutual TLS when token replay would materially increase the blast radius of a stolen credential.
Practitioner guidance
- Map OAuth clients into the identity inventory Record every OAuth client, its owner, scopes, token lifetime, and revocation path so it is governed like any other non-human identity.
- Bind tokens to the presenting client Use mutual TLS or other sender-constrained patterns wherever replay of an access token would expose sensitive APIs or customer data.
- Shorten delegated access windows Set token lifetimes to match business need, not developer convenience, and ensure revocation is operationally tested.
What's in the full article
Curity's full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for selecting the right OAuth flow for code, client credentials, device, and token exchange use cases.
- Implementation detail for mutual TLS, sender-constrained tokens, and PKCE in real API environments.
- How the OAuth client ID metadata document changes onboarding for ephemeral clients.
- Curity's supported RFC coverage and configuration examples for identity server deployments.
👉 Read Curity's analysis of OAuth 2.0 client identity, token hardening, and flows →
Ephemeral OAuth clients: what changes for identity teams?
Explore further
06/07/2026 9:50 am
OAuth client identity is now a governed identity, not a technical configuration detail. Once a client can obtain delegated access to APIs, it is part of the identity estate and should be treated with the same lifecycle discipline as other non-human identities. The practical implication is that client onboarding, scope assignment, and revocation need ownership, review, and auditability.
A few things that frame the scale:
- 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, according to Guide to the Secret Sprawl Challenge.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and they are 13% more likely to be categorised as critical than code-based leaks.
A question worth separating out:
Q: What is the difference between PKCE and token revocation in OAuth security?
A: PKCE prevents interception of the authorization code during the login exchange, while token revocation removes access after issuance when trust changes or credentials are compromised. They solve different problems, so mature OAuth programmes need both rather than treating one as a substitute for the other.
👉 Read our full editorial: OAuth client metadata and ephemeral clients reshape API auth
