An application that cannot safely keep a client secret and therefore must be treated as externally visible in its trust model. For CLI tools, this usually means the app can initiate authorization but should not rely on hidden credentials for authentication. The security boundary shifts to scope control, token handling, and revocation.
Expanded Definition
A public OAuth client is an OAuth-based application that cannot keep a client secret confidential, so its trust model assumes the software runs in an exposed environment. That usually includes browser-based apps, mobile apps, desktop tools, and command-line utilities that initiate sign-in without possessing a protected backend credential.
In practice, the important distinction is not whether the app is “trusted,” but what it can safely prove. A public client relies on authorization grant design, redirect handling, token scope, and token storage controls rather than on a reusable secret. Industry guidance increasingly aligns this pattern with OAuth 2.0 best practices and with broader zero-trust thinking described in the NIST Cybersecurity Framework 2.0, especially where identity assurance depends on containment and monitoring instead of hidden credentials. The Ultimate Guide to NHIs also shows why this matters: many organisations still store secrets in vulnerable places, which makes “secret-backed” assumptions unsafe for software that should never have one.
The most common misapplication is treating a public client like a confidential backend app, which occurs when teams embed a client secret in mobile, desktop, or CLI code and assume it remains hidden.
Examples and Use Cases
Implementing public OAuth clients rigorously often introduces user-experience and revocation complexity, requiring organisations to weigh simpler login flows against tighter token controls and shorter-lived credentials.
- A developer CLI that starts an OAuth browser flow and exchanges an authorization code with PKCE, rather than shipping a reusable secret inside the binary.
- A desktop application that connects to SaaS APIs through delegated scopes, with refresh tokens stored only in the local OS keychain and not hardcoded in config.
- A mobile app that uses OAuth to access user data while relying on platform attestation, redirect URI discipline, and narrow scopes instead of a client secret.
- A public integration that is monitored for token abuse after lessons learned from incidents such as the Salesloft OAuth token breach, where token exposure became the real attack path.
- A third-party sign-in app that is reviewed under OAuth app inventory controls, informed by patterns seen in the Dropbox Sign breach and similar token-centric compromises.
For protocol-level design, teams often pair this model with the OAuth 2.0 security guidance maintained by the RFC Editor and implementation patterns that reduce interception risk.
Why It Matters in NHI Security
Public OAuth clients matter because they are easy to overtrust and difficult to inventory. When organisations mistake them for confidential applications, they often over-grant scopes, extend token lifetimes, or place sensitive credentials in code and config. That turns a user-facing integration into a durable NHI risk. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and that same pattern is especially dangerous when applied to software that is structurally unable to protect a secret. In parallel, 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which means public clients can become a blind spot in SaaS-to-SaaS access chains.
Governance should focus on scope minimisation, token rotation, consent review, redirect URI validation, and rapid revocation of compromised grants. The right question is not whether the application has a secret, but whether its access path can be constrained and observed as an NHI. Organisations typically encounter the operational impact only after a token is stolen or a connected app is abused, at which point public OAuth client management becomes 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 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Public OAuth clients increase secret-sprawl and token-abuse risk in NHI ecosystems. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and permission governance apply directly to OAuth scopes and tokens. |
| NIST SP 800-63 | Identity assurance concepts inform how public clients authenticate without storing secrets. |
Treat public clients as secretless, inventory their grants, and rotate or revoke exposed tokens fast.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
