OAuth client metadata and ephemeral clients reshape API auth

At a glance

What this is: This is Curity’s OAuth and client-authentication overview, with a strong emphasis on ephemeral clients, token hardening, and flow selection for modern API access.

Why it matters: It matters because IAM teams must treat OAuth clients, tokens, and device-based access as governed identities, not just protocol plumbing, across NHI, autonomous, and human programmes.

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.
• 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.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Curity's analysis of OAuth 2.0 client identity, token hardening, and flows

Context

OAuth 2.0 is the delegated authorization model many enterprises rely on when a user, workload, device, or client needs access without sharing passwords. The governance gap is not the protocol itself, but the fact that client identity, token lifetime, and revocation often get handled as implementation details instead of identity controls.

Curity’s material frames a practical set of controls around OAuth flows, ephemeral clients, mutual TLS, sender-constrained access tokens, PKCE, device flow, and token revocation. For IAM and NHI teams, the key question is whether the client is authenticated strongly enough, the token is bound tightly enough, and the lifecycle is short enough to limit abuse.

That is a typical pattern in modern API programmes: access is delegated quickly, but the security model still assumes clients are trustworthy once issued credentials. In practice, that assumption is what attackers and misconfigurations exploit.

Key questions

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. Once a client can request delegated access, it functions as a governed identity and should be reviewed for lifecycle, least privilege, and evidence of ongoing need.

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. In API-heavy environments, that portability turns token theft into direct access, which is why sender constraints and short lifetimes matter.

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. It is especially valuable for sensitive APIs, service integrations, and workloads where delegated access must be tied to a specific client instance.

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.

Technical breakdown

Ephemeral OAuth clients and client ID metadata documents

Ephemeral clients reduce the burden of upfront registration by letting a client identify itself at the authorization server through metadata rather than a long-lived manual onboarding record. That can help with dynamic environments, but it also shifts control from static registration to runtime assurance. The security question becomes whether the authorization server can still distinguish legitimate ephemeral clients from lookalikes, and whether lifecycle, provenance, and policy are enforced consistently.

Practical implication: treat ephemeral client onboarding as an identity workflow, not just a convenience feature, and require policy checks before token issuance.

Mutual TLS and sender-constrained access tokens

Mutual TLS authenticates the client at the transport layer, while sender-constrained tokens bind the access token to the client that received it. Together, they reduce the value of a stolen token because the attacker cannot simply replay it from another machine. This matters most in API-heavy environments where bearer tokens otherwise behave like transferable secrets. The core issue is not stronger encryption, but reducing token portability.

Practical implication: pair token issuance with sender constraints wherever token replay would create material lateral-movement risk.

PKCE, device flow, and revocation as lifecycle controls

PKCE protects authorization code flows from interception, device flow handles input-constrained endpoints, and revocation removes access before token expiry when trust changes. These are lifecycle controls, not just protocol options. They matter because OAuth deployments often fail when tokens outlive the business relationship or the session context that justified them. In identity terms, the problem is stale delegated authority persisting after the moment of need has passed.

Practical implication: enforce short-lived delegated access and make revocation part of the operating model, not an exception path.

Threat narrative

Attacker objective: The attacker aims to reuse delegated OAuth access as if they were a legitimate client, preserving trust while bypassing direct credential controls.

1. entry via exposed or stolen OAuth client credentials, tokens, or misbound delegated access that should have been constrained to a specific client context.
2. credential abuse escalates when bearer tokens or weakly bound access tokens are replayed from another environment without sender validation or revocation.
3. impact occurs when the attacker uses delegated API access to read, modify, or extract data through the trusted application path.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Bearer tokens remain too transferable for high-trust environments unless they are constrained. OAuth was designed to avoid password sharing, but bearer semantics still make stolen tokens valuable if they are not bound to the presenting client. That is why sender-constrained access and mutual TLS matter: they reduce token portability and shrink the abuse window. Practitioners should read this as a control boundary problem, not a protocol elegance problem.

Ephemeral clients create a governance gap if identity proof is weaker than registration friction. The convenience of dynamic client identification can outpace the controls that prove who the client is, what it may access, and when that access should end. The implication is that IAM teams need lifecycle logic for clients, even when those clients are short-lived or automation-driven.

OAuth flow choice is a privilege design decision, not an integration preference. PKCE, device flow, client credentials, token exchange, and revocation each encode different trust assumptions about who is acting, on what device, and with what delegation depth. That means architecture teams should stop treating flow selection as developer convenience and start treating it as access-risk classification.

Identity blast radius is the right lens for OAuth programmes. If a client credential or token leaks, the only meaningful question is how far delegated access can travel before control boundaries stop it. That framing aligns better with OWASP Non-Human Identity Top 10 and NIST CSF access governance than with legacy app security checklists.

From our research:

• 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.
• For teams hardening delegated access, the next step is to pair OAuth controls with OWASP Non-Human Identity Top 10 guidance and lifecycle discipline.

What this signals

OAuth programmes are moving from protocol choice to identity governance discipline. As delegated access spreads across APIs, devices, and automation, teams need to inventory clients, scope them tightly, and remove assumptions that a token is harmless because it is not a password.

Identity blast radius: the useful unit of analysis for OAuth is no longer the flow name, but the maximum damage a stolen client credential or access token can do before revocation or sender binding stops it. That is the control boundary practitioners should design around.

With 64% of valid secrets leaked in 2022 still exploitable today, revocation and token binding are not secondary hygiene tasks. They are the difference between a short-lived delegation and an enduring access path.

For practitioners

• 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. Use the same inventory discipline for ephemeral clients and long-lived integrations.
• 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. Bearer tokens should be the exception, not the default, in high-risk environments.
• Shorten delegated access windows Set token lifetimes to match business need, not developer convenience, and ensure revocation is operationally tested. If a token leaks, revocation should be the fastest path to containment, not a manual afterthought.
• Review device and public-client flows separately Treat device flow and public-client patterns as distinct risk cases because the user, device, and client are not the same thing. Apply stronger proof and tighter scopes where user convenience would otherwise mask weak client assurance.

Key takeaways

• OAuth client credentials are governed identity artifacts, not mere setup details, and they need ownership, scope control, and lifecycle review.
• Bearer tokens remain fragile in high-trust API environments unless they are sender-constrained and short-lived.
• Practitioners should design for identity blast radius, because delegated access fails when token portability outruns revocation discipline.

Key terms

• OAuth Client: An OAuth client is the application or service that requests delegated access on behalf of a user or workload. In identity governance terms, it is a non-human identity that must be owned, scoped, and revoked like any other privileged integration.
• Sender-Constrained Token: A sender-constrained token is bound to the client or cryptographic context that received it, which limits replay if the token is stolen. This is a practical control for reducing bearer-token portability in APIs and automation flows.
• Ephemeral Client: An ephemeral client is a short-lived OAuth client that is identified at runtime rather than through a long manual registration lifecycle. It can improve agility, but it also requires runtime assurance, ownership, and policy checks because its trust window is intentionally brief.
• PKCE: PKCE is an OAuth protection that links the authorization request to the token exchange, reducing the impact of code interception. It is especially relevant for public clients, mobile apps, and other flows where the client cannot safely keep a secret.

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.

👉 Curity's full OAuth coverage includes flow selection, token revocation, and client authentication detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.