Notifications
Clear all
Topic starter
22/06/2026 4:59 pm
TL;DR: OAuth 2.0 client authentication has shifted from shared-secret methods to cryptographic methods like private_key_jwt and mTLS, because leaked secrets remain replayable until rotation and sender-constrained tokens reduce that blast radius, according to Scramble ID. Shared-secret trust assumptions are now the weak point, not the integration pattern itself.
NHIMG editorial — based on content published by Scramble ID: OAuth client authentication is moving beyond shared secrets
Questions worth separating out
Q: How should security teams replace shared-secret OAuth client authentication in production?
A: Security teams should move high-trust integrations to private_key_jwt or mTLS-based client authentication, then layer sender-constraint at the resource server with mTLS or DPoP.
Q: Why do shared secrets create more risk in non-human identity integrations?
A: Shared secrets create more risk because they are copied into multiple systems, are hard to contain once exposed, and remain valid until rotated.
Q: What breaks when access tokens are not sender-constrained?
A: When access tokens are not sender-constrained, anyone who steals the token can usually replay it until expiry, regardless of where it came from.
Practitioner guidance
- Replace shared-secret client auth for high-trust integrations Move new production integrations away from client_secret_basic and client_secret_post.
- Adopt private_key_jwt as the default client proof Register asymmetric public keys with each authorization server, store private keys in hardware-backed storage, and enforce short-lived JWT assertions with aud, exp, and jti validation.
- Bind access tokens at the resource layer Use mTLS where PKI and certificate operations are mature, or DPoP where proxies, browsers, or cloud front doors make mTLS operationally awkward.
What's in the full article
Scramble ID's full article covers the operational detail this post intentionally leaves for the source:
- Exact request and response examples for client_secret_basic, private_key_jwt, mTLS, and DPoP flows
- Standards-by-standards comparison of RFC 7523, RFC 8705, RFC 9449, and RFC 9700 for implementation teams
- Decision matrix for internal service-to-service, partner integration, legacy system, and AI agent use cases
- Migration sequence for replacing shared secrets without breaking existing token endpoint integrations
👉 Read Scramble ID's analysis of OAuth client authentication methods and sender-constrained tokens →
OAuth client authentication: are shared secrets still acceptable?
Explore further
22/06/2026 5:11 pm
Shared-secret client authentication is an identity leakage model, not a credentials model. The real problem is not that the secret is weak. It is that the design assumes the credential can be duplicated safely across tooling, environments, and operators without changing its trust value. That assumption breaks under modern delivery pipelines, where secrets are expected to proliferate before they are controlled. Practitioners should treat this as a structural NHI governance issue, not a syntax choice in OAuth configuration.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who should own OAuth client authentication decisions in an IAM programme?
A: OAuth client authentication decisions should sit with IAM, NHI, and platform security owners together, because the choice affects identity lifecycle, credential storage, revocation, and replay risk. Application teams can implement the flow, but governance should define which methods are acceptable, which are exceptions, and how proof material is rotated and audited.
👉 Read our full editorial: OAuth client authentication is moving beyond shared secrets
