An application that cannot safely store a secret because it runs in an environment the user controls, such as a browser or desktop client. These clients must rely on redirect-based authorization flows, because embedding long-lived credentials in the client creates a direct exfiltration risk.
What a public client means in OAuth 2.0
A public client is defined by its inability to safely keep a client secret, so the design assumption is that the client can be inspected, copied, or tampered with by the user or environment. That changes the trust model, not the fact that it can still participate in OAuth.
In practice, the main distinction is between clients that can prove themselves with a protected secret and clients that cannot. Public clients therefore use redirect-based authorization flows and proof mechanisms that do not depend on hidden long-term credentials.
The distinction matters because the same application category can be legitimate and secure when it relies on the correct flow, but unsafe when teams try to treat it like a confidential application. The security model is about what the client can realistically protect, not what developers wish it could protect.
Why OAuth 2.0 treats public clients differently
OAuth 2.0 separates the roles of resource owner, authorization server, resource server, and client so the protocol can support many application types. A public client is allowed, but the protocol expects it to authenticate the user through an authorization redirect rather than through a secret it cannot protect. The RFC 6749: The OAuth 2.0 Authorization Framework is the core reference for that model.
For this class of client, the practical security boundary is the browser, desktop runtime, or other user-controlled environment. That means the application can initiate an authorization request, receive an authorization code, and exchange it using the protocol rules, but it should not be trusted with a long-lived shared secret as if it were a server-side application.
The same logic is why modern OAuth guidance emphasizes safer flows, redirect URI validation, and sender-constrained or proof-based protections where available. The client type drives the control choice, and the control choice drives whether the flow can resist interception or replay.
Where public clients fit in real deployments
Public clients are common in browser-based apps, native desktop software, mobile apps, CLI tools, and other software that ships to an end user. These environments improve usability, but they also make embedded secrets discoverable through decompilation, local storage inspection, logging, memory access, or proxying.
That is why public clients are often paired with mechanisms such as authorization code flow with PKCE, audience restriction, and short-lived tokens rather than static credentials. The point is not to hide a secret that cannot be hidden, but to reduce the value of anything an attacker can extract.
This class of client also shows up in federated and delegated access patterns where the application needs user consent but not full server-to-server trust. When used correctly, the design keeps the client lightweight and shifts sensitive trust decisions back to the authorization server.
Related guidance on OAuth 2.0 and OpenID Connect is useful because it places public clients in the broader flow landscape, including grant types, scopes, redirect handling, and common mistakes.
Public client mistakes that change the security outcome
The most common mistake is treating a public client like a confidential client by embedding a reusable secret and assuming it will stay hidden. That fails because any secret shipped to an untrusted execution environment becomes extractable, reusable, and often shareable across copies of the app.
Another mistake is relying on weak redirect handling or broad token scopes. If the redirect URI is poorly controlled, or if access tokens are oversized for the job, the client becomes a more attractive target for code interception, token theft, and consent abuse.
Public clients also become risky when teams blur the line between app identity and user identity. The client should not be granted privileges it does not need, and it should not be used as a shortcut for back-end trust relationships that belong in a different architecture.
For a broader identity and secret-management view, Ultimate Guide to NHIs, What are Non-Human Identities helps explain why OAuth tokens and other identity-bearing material still need careful handling even when the client itself is public.
Risk and Threat Considerations
Public clients are exposed to secret extraction, token theft, authorization-code interception, and consent phishing because they operate in environments the attacker or user can inspect and influence. The main security issue is not that they exist, but that defenders may overestimate how much trust the client can hold.
Failure mechanism: Attackers or malicious apps can recover embedded credentials, replay stolen tokens, or abuse permissive redirect handling to gain unauthorized access. If the client is treated as confidential, the design puts durable trust material into a place where it cannot be reliably protected.
Impact: The result can be account takeover, persistent access, mailbox or API exposure, and downstream movement into other systems that trust the stolen token or consent grant. In practice, the compromise often survives longer than the original application session.
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 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Public clients are commonly implemented through OAuth and OIDC flows. |
| Recommendation — Validate redirect handling, grant choice, and token use for client-facing OAuth flows. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Public clients should not rely on long-lived embedded secrets or reusable authenticators. |
| IA-9 — Service Identification and Authentication | Covers machine and application authentication patterns relevant to non-public OAuth clients. | |
| Recommendation — Manage client secrets so they are not embedded in user-controlled software. Use stronger client authentication only where the application can protect credentials. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Public client design is directly tied to insecure use of credentials in non-confidential environments. |
| Recommendation — Prefer flows that do not require a protectable client secret in exposed runtimes. | ||
Practitioner Guidance
Why practitioners should care: The decisive question is whether the application can truly keep a secret, not whether it would be convenient to do so. If it cannot, the architecture should be built around redirect-based authorization, short-lived credentials, and strict redirect URI control.
Common misunderstanding: A public client is not a weaker confidential client, it is a different trust class altogether. Treating it as if a hidden secret will remain hidden is usually the root cause of insecure OAuth deployments.
Practitioner takeaway: Design the client so that disclosure is assumed, then make the authorization flow and token handling safe under that assumption.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
