A non-persisted OAuth client is an OAuth client that is never written as a lasting registration in the authorization server. It is created for immediate use and then disappears. This pattern is useful when identities are short-lived, dynamic, or generated by automated systems.
Expanded Definition
A non-persisted oauth client is a client identity that exists only for the duration of an exchange and is not stored as a lasting registration in the authorization server. In NHI practice, this usually means the client is issued or assembled just-in-time for a task, then discarded when the task ends.
That makes it distinct from a normal OAuth client registration, which is intended to be durable, inventoryable, and governed over time. The pattern is useful for ephemeral automation, temporary integrations, and agent workflows where a standing client would create unnecessary attack surface. Definitions vary across vendors on whether the client is truly unregistered, dynamically registered, or simply ephemeral in the control plane, so practitioners should verify the lifecycle being described rather than assume the label implies a single technical design.
For standards context, OAuth itself is defined by the OAuth 2.0 authorization framework, while lifecycle, revocation, and secret handling expectations are often shaped by broader guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls. The most common misapplication is treating a temporary client as inherently low-risk, which occurs when teams skip lifecycle logging, secret binding, and expiration enforcement.
Examples and Use Cases
Implementing non-persisted OAuth clients rigorously often introduces more orchestration overhead, requiring organisations to weigh reduced standing exposure against tighter issuance and teardown controls.
- A build pipeline creates a short-lived OAuth client for a single deployment job, then tears it down after token exchange completes.
- An AI agent uses a transient client to access a scoped API during one workflow run, reducing the need for a standing integration record.
- A partner onboarding flow issues a client only after approval, then removes it when the integration expires or is replaced.
- A temporary support automation uses a non-persisted client to perform a one-time remediation task, limiting long-term credential sprawl.
- Ephemeral federation is used to avoid storing a permanent client secret in CI/CD while still allowing programmatic access for a defined session.
These patterns are especially relevant where standing OAuth apps have been abused, as seen in the Salesloft OAuth token breach and the Klue OAuth Supply Chain Breach. Operationally, the access model still needs to align with OAuth 2.0 Dynamic Client Registration when registration is automated rather than manually pre-provisioned.
Why It Matters in NHI Security
Non-persisted OAuth clients can reduce the inventory burden of NHI management, but they also create a visibility problem if teams do not log issuance, scope, expiry, and teardown. NHI Mgmt Group research shows that only 5.7% of organisations have full visibility into their service accounts, and similar blind spots often affect ephemeral OAuth clients when they are treated as disposable rather than governed identities.
This matters because ephemeral does not mean harmless. If a transient client can request broad scopes, mint refresh tokens, or survive beyond its intended task, it becomes a fast-moving access path that is difficult to detect during incident response. The control objective is not persistence alone, but provable lifecycle restraint, least privilege, and explicit revocation logic. The issue becomes more severe when third-party apps, agents, or automation platforms initiate access on behalf of hidden workflows.
For governance, a non-persisted client should still be bound to ownership, purpose, and expiration, with controls mapped to OAuth 2.0 Security Best Current Practice and monitored alongside identity-risk guidance in the Ultimate Guide to NHIs. Organisations typically encounter the real risk only after an incident review reveals an ephemeral client was used as the initial access path, at which point the term becomes operationally unavoidable to address.
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 Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Ephemeral clients still need lifecycle and ownership controls for non-human identities. |
| NIST CSF 2.0 | PR.AC-1 | Access control requires identities to be uniquely governed even when short-lived. |
| NIST SP 800-63 | Identity assurance concepts inform how strongly ephemeral clients are bound and authenticated. | |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires every access path to be evaluated, even if it is temporary. |
| OWASP Agentic AI Top 10 | A1 | Agentic systems often use temporary clients to obtain tool access safely. |
Assign each non-persisted client explicit authorization rules and verify them before use.
