Notifications
Clear all
Topic starter
25/06/2026 2:45 pm
TL;DR: Choosing between 2-legged and 3-legged OAuth depends on who authorizes access, but the deeper security issue is avoiding persistent client secrets and redirect abuse across modern workloads, according to Aembit. Secretless workload identity, PKCE, short-lived tokens, and workload identity federation are now the decisive controls for reducing exposure windows and credential sprawl.
NHIMG editorial — based on content published by Aembit: OAuth flow choice and secretless access for modern workloads
By the numbers:
- Each service potentially needs credentials for 5-10 external dependencies, creating thousands of secrets requiring rotation.
Questions worth separating out
Q: How should security teams replace static secrets in service-to-service OAuth flows?
A: Security teams should move from stored client secrets to workload identity federation wherever the platform supports it.
Q: Why do long-lived client secrets create risk in modern workload architectures?
A: Long-lived client secrets create risk because they are reusable, difficult to revoke cleanly, and often copied across code, pipelines, and environment variables.
Q: What breaks when teams use 3-legged OAuth without PKCE?
A: Without PKCE, intercepted authorization codes can be replayed by an attacker who was not the intended client.
Practitioner guidance
- Replace static client secrets with federated workload identity Map every service-to-service integration that still depends on stored credentials, then move the highest-risk ones to environment-based attestation and short-lived token exchange.
- Enforce PKCE and strict callback validation for delegated flows Require PKCE for all mobile and browser-based applications, validate the state parameter on every callback, and keep access tokens short-lived with rotation for refresh tokens.
- Treat secret zero as a design defect Document where workloads still need an initial credential to reach a secret store, then redesign those bootstrap paths so the workload can prove identity without holding a reusable secret.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Protocol-by-protocol examples for choosing between 2-legged and 3-legged OAuth in real architectures.
- Concrete implementation patterns for workload identity federation across AWS, Azure, GCP, and Kubernetes.
- Security handling guidance for PKCE, state validation, and token storage in browser and mobile apps.
- A decision framework for replacing stored secrets with secretless access in CI/CD and microservice environments.
👉 Read Aembit's analysis of OAuth flows, workload identity, and secretless access →
OAuth flow choice for workloads: are your secrets the real risk?
Explore further
25/06/2026 3:53 pm
Static client secrets are the wrong trust primitive for modern workloads: The article shows that 2-legged OAuth still depends on stored credentials, which means identity is anchored in something reusable rather than something provable at runtime. That is exactly why workload governance keeps collapsing under secrets sprawl, rotation lag, and environment drift. The practitioner conclusion is that access models built on durable secrets are structurally misaligned with ephemeral execution.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- A further 47% have only partial visibility into those OAuth-connected vendors, which means the governance gap is not limited to edge cases.
A question worth separating out:
Q: Who should own revocation and lifecycle control for workload credentials?
A: Revocation and lifecycle control should sit with the team that owns the workload, but it must also be enforced by the identity platform. Administrators need clear visibility into which services still depend on secrets, which tokens are long-lived, and which integrations can be moved to ephemeral access. That ownership model is what keeps governance practical.
👉 Read our full editorial: OAuth flow choice and secretless access for modern workloads
