Public Client

Expanded Definition

A public client is an application that cannot keep a credential secret because it runs on an end user device or in a browser runtime. In NHI practice, that means it can request access on behalf of a user or workflow, but it should not be trusted to protect long lived secrets, private keys, or any material that depends on custody. Definitions vary across vendors when public clients are grouped with mobile apps, SPA front ends, and desktop tools, but the operational boundary is consistent: if the runtime is exposed to inspection, tampering, or extraction, it is public.

This distinction matters most when teams decide how an agent, script, or user facing app authenticates. A public client may use redirect based flows, proof of possession mechanisms, or short lived tokens, while a confidential client can safely hold stronger credentials. For identity governance, the practical question is not whether the app is useful, but whether it can be trusted with secrets at rest. The NIST Cybersecurity Framework 2.0 reinforces the need to manage access credentials according to risk and exposure, not convenience. In the NHI context, that aligns with guidance in the Ultimate Guide to NHIs on lifecycle control, rotation, and visibility.

The most common misapplication is treating a browser based or mobile client as if it can safely store reusable API keys, which occurs when developers prioritize release speed over runtime exposure.

Examples and Use Cases

Implementing public client patterns rigorously often introduces token handling constraints, requiring organisations to weigh user convenience and deployment speed against reduced secret custody and stronger expiry discipline.

• A single page application uses OAuth redirect flows with short lived tokens, because embedding a reusable secret in front end code would be recoverable by anyone inspecting the bundle.
• A mobile app authenticates to an API using device friendly flows, but it still avoids storing long term API keys locally, since a rooted or jailbroken device can expose them.
• A desktop automation tool acts as an interface for an operator, yet it delegates sensitive access to a backend service that holds the real credential state.
• An internal portal supports user sign in and session creation, while secret rotation and policy enforcement are handled by a separate trusted service, not the browser itself.

These patterns reflect a broader NHI control theme described in the Ultimate Guide to NHIs: the more exposed the runtime, the more the architecture should shift toward ephemeral authorization and away from static secrets. For implementation teams, the NIST Cybersecurity Framework 2.0 is useful as a reference for managing access, protecting credentials, and monitoring misuse across the system boundary.

Why It Matters in NHI Security

Public clients are a governance issue because they define where trust ends. If a team assumes a public client can safely hold a secret, the result is often credential leakage, difficult rotation, and hidden privilege exposure. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which illustrates how quickly exposed credentials can escape oversight when client boundaries are unclear. The same problem appears in app distribution, where copied code, cached tokens, and device compromise turn an intended access helper into a broad attack path.

This term also matters in zero trust programs. Public clients fit naturally with the NIST Cybersecurity Framework 2.0 emphasis on continuous risk management, and they echo the lifecycle and visibility concerns highlighted in the Ultimate Guide to NHIs. Once a secret has been embedded in a client app, remediation becomes harder than prevention, because every copy of the runtime may need to be assumed compromised. Organisations typically encounter the full cost of a public client mistake only after a token leak or account takeover, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams implement Client ID Metadata Documents?
• Why do still-valid secrets matter after public disclosure?
• When does manual client registration create more risk than it reduces?
• When should organisations use self-signed TLS client authentication instead of CA-signed mTLS?