A service-to-service OAuth flow where a client authenticates directly to an authorization server using its own credentials. The token represents the service’s authority, not a user’s delegated permission, which makes it suitable for backend workloads but risky if the client secret is stored long term.
Expanded Definition
2-legged OAuth is the service-to-service pattern where one software workload authenticates itself to an authorization server and receives a token for its own use. In NHI security, that means the identity bound to the token is the application or service account, not a person exercising delegated consent.
This distinction matters because 2-legged OAuth is often used for backend integrations, scheduled jobs, and API-to-API calls where user context is unnecessary. The model is conceptually simpler than user-delegated OAuth, but operationally it concentrates risk in client credentials, token handling, and the trust placed in the calling workload. Definitions vary across vendors when they describe this flow as “client credentials grant,” yet the core security issue is the same: the service becomes a non-human identity with durable access unless controls limit scope, lifetime, and storage. Guidance from the NIST Cybersecurity Framework 2.0 still applies through least privilege, asset visibility, and credential lifecycle management. The most common misapplication is treating 2-legged OAuth as “safe by default,” which occurs when teams issue broad tokens to backend services and then leave the underlying secret in code or configuration.
Examples and Use Cases
Implementing 2-legged OAuth rigorously often introduces operational friction, because each service needs a tighter trust boundary, stronger secret handling, and clearer token renewal logic, requiring organisations to weigh automation speed against credential exposure.
- A billing microservice calls a payment API with its own client credentials, using narrowly scoped tokens for invoice generation and reconciliation.
- An internal data pipeline authenticates to a warehouse API on a schedule, where the service account must be rotated and monitored like any other NHI.
- A SaaS integration accesses Salesforce or support tooling through backend OAuth, similar to cases examined in the Salesloft OAuth token breach and the Dropbox Sign breach.
- A DevOps automation service requests short-lived access to deployment APIs, with secrets stored in a vault and not embedded in CI/CD variables.
- A monitoring agent collects telemetry from internal endpoints using a service identity instead of shared administrator credentials.
For the protocol mechanics, the OAuth 2.0 client credentials model is the closest external reference, while implementation guidance should be mapped back to NHI governance controls and secret management practice.
Why It Matters in NHI Security
2-legged OAuth becomes a security concern when service identities accumulate long-lived secrets, broad scopes, and poor visibility. NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes service-to-service access especially hard to inventory and review. When a token or client secret is stolen, the attacker does not need to impersonate a human user, only the workload that already has standing authority.
That is why backend OAuth must be treated as an NHI lifecycle issue, not just an application integration choice. The real risk is not the protocol itself, but the combination of durable credentials, weak rotation, and inadequate offboarding when services are retired or replaced. Those failures turn routine automation into persistent access paths that survive beyond their intended business use. Organisations typically encounter the consequence only after a token leak, vendor compromise, or unexpected API abuse, at which point 2-legged OAuth becomes operationally unavoidable to address.
- Rotate client secrets on a defined schedule and on every suspected exposure.
- Prefer short-lived tokens and narrow scopes over static, high-privilege credentials.
- Inventory every service using backend OAuth, including third-party connectors and automation jobs.
- Monitor token issuance, token use, and anomalous API activity as part of identity telemetry.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Service-to-service OAuth creates a non-human identity that must be inventoried and governed. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Client secrets and tokens are secrets that must not be stored or reused unsafely. |
| NIST CSF 2.0 | PR.AC-1 | OAuth client authentication supports access control when scoped and managed correctly. |
Store OAuth client secrets in a vault and rotate them before compromise or retirement.
