Public client apps run in environments where they cannot safely keep a secret, such as mobile, desktop, or browser-based apps. Confidential client apps can securely hold a credential, such as a server-side web app or daemon. Use public client flows that rely on user interaction and device protection, and use confidential client flows when the app can keep credentials private.
Public and confidential client apps differ mainly in where they can keep credentials and what that means for the OAuth flow. public client, such as mobile, desktop, and browser apps, must assume a secret can be exposed, so they use user-centric flows and stronger client-side protections. Confidential clients, such as server-side web apps and daemons, can hold a credential privately and use flows that depend on that property.
That distinction is practical, not just theoretical. A public client should be treated as an environment you do not trust with a long-lived credential, which is why it usually relies on redirected user sign-in, device-bound protections, or PKCE rather than a stored client secret. A confidential client can authenticate itself to the identity provider because the secret or certificate stays on a controlled server side boundary.
The choice also affects how you think about app registration and consent. In Microsoft ecosystems, the app type should match the runtime reality of the code, not the convenience of the implementation. For example, a browser SPA or native app should not be designed like a server app simply because it can call an API, and a backend service should not be forced into public-client patterns when it can safely use credential-based authentication.
How the Client Type Changes Authentication Design
In MSAL, the client type determines whether the application can prove its own identity independently or must rely on a user-centered interaction. Public clients are inherently unable to protect a client secret, so they use flows that assume the app itself is not a trusted secret holder. Confidential clients can use a secret or certificate, which lets the identity platform distinguish the application from the end user and issue tokens with that stronger app authentication context.
This matters because the app type influences both security and operational behavior. Public clients are better suited to per-user delegated access, where the user signs in and grants access to the app. Confidential clients support scenarios where the app needs to act on its own, or where the server can safely manage app credentials and token exchange without exposing those credentials to the browser or device.
In practice, the cleanest mental model is to ask whether the code running on the endpoint can be copied, inspected, or tampered with enough to steal a secret. If yes, it is a public client. If no, because the sensitive credential remains on a protected backend, it is a confidential client. That is why MSAL treats the same logical application differently depending on whether the trust boundary sits in the browser, on a device, or behind a server.
For Microsoft identity guidance, see the OAuth 2.0 and OpenID Connect Guide for Identity Teams for the surrounding flow choices and the RFC 6749: The OAuth 2.0 Authorization Framework for the underlying protocol model.
Confidential client usage also becomes more relevant when an app needs stronger client authentication than a shared secret. If the application can hold a certificate, signed assertion, or similar server-side credential, that generally provides a stronger operating model than putting a reusable secret into client code. That is why confidential app design is usually preferred for backend integrations, scheduled jobs, and daemon-style services.
What Goes Wrong When the App Type Is Misclassified
The biggest failure mode is treating a public client as if it can safely store a secret. Once that happens, the secret can be extracted from the app package, browser context, or device, which turns the application into a reusable credential leak. The reverse mistake is also harmful: forcing a server-side app to behave like a public client can lead to awkward workarounds, weaker authentication choices, and poor separation between user identity and application identity.
Misclassification can also lead to incorrect token handling. Public clients are meant to operate under the assumption that the app runtime is exposed to the user or the local environment, so the security posture must come from short-lived tokens, redirect handling, and device protections rather than from a hidden secret. Confidential clients, by contrast, are expected to protect their app credential carefully and rotate it if it is exposed or suspected to be exposed.
For app teams, the real risk is not just a policy mismatch. It is an architecture mismatch that can create credential theft, unintended token issuance patterns, and access paths that the identity platform will still honor if the app was configured incorrectly. If the platform thinks the app is confidential, but the runtime is actually public, you have effectively placed a secret in a hostile place.
Microsoft-specific app governance issues often surface alongside consent and registration mistakes, so it helps to pair client-type review with the Entra ID Applications and Consent Guide when you are checking whether the app’s registration, permissions, and trust boundary still line up.
Which Pattern Fits Which Scenario
Use a public client pattern when the application is inherently interactive and runs on an endpoint you do not fully control. Common examples are native mobile apps, desktop software, and browser-based front ends. Use a confidential client pattern when the application runs on a server, can protect its own credentials, and needs to authenticate as an application rather than only as a signed-in user.
That distinction is especially important when deciding whether to use delegated permissions or application permissions. Public clients normally align with user-delegated access because they cannot safely hold app credentials. Confidential clients can support app-only access where the backend needs durable, non-interactive authorization to call downstream services.
If the application spans both sides, split the responsibilities. Let the front end remain a public client and move the privileged or credential-bearing logic into a backend confidential client. That separation reduces secret exposure and makes the trust boundary explicit instead of pretending the browser or device is a safe place for long-lived credentials.
When you need protocol-level depth, the RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants and RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens show how stronger confidential-client authentication is handled when a shared secret is not the right choice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | MSAL client type choices depend on how the app authenticates and what assurance model fits. |
| Recommendation — Apply the appropriate assurance and authenticator guidance to the app's trust boundary and sign-in model. | ||
| OWASP ASVS | V10 — OAuth and OIDC | The question is about OAuth client behavior and client authentication patterns in an app. |
| Recommendation — Verify the app uses the correct OAuth and OIDC flow for its client type and trust boundary. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Confidential clients rely on protected app credentials that must be managed and rotated safely. |
| IA-9 — Service Identification and Authentication | Confidential client apps authenticate themselves as services or workloads, not only as users. | |
| Recommendation — Manage application credentials with controlled issuance, storage, rotation, and revocation. Authenticate backend apps with service-level credentials instead of exposing shared secrets to clients. | ||
| CIS Controls v8 | 5 — Account Management | The distinction affects how application identities and credentials are created, used, and removed. |
| Recommendation — Inventory and govern application accounts and their access paths across environments. | ||
Practitioner Guidance
What to verify: Confirm where the app actually runs, who can inspect its runtime, and whether any credential would be recoverable from the client environment. If the answer is “yes,” treat it as public even if the business would prefer a confidential pattern.
Decision rule: If the app must hold a reusable credential, keep that credential on a backend and classify the client side as public. If the app cannot keep a secret, design for interactive authentication and short-lived token use rather than trying to force app-only authentication.
Common mistake: Teams often classify by user experience instead of trust boundary. A polished web app is not automatically confidential, and a desktop app is not confidential just because it has a backend API.
Practitioner takeaway: In MSAL, the right client type is the one that matches the app’s real ability to protect credentials, because that boundary determines whether the identity design is safe or merely convenient.
Related resources from NHI Mgmt Group
- What is the difference between PKCE-based CLI authentication and embedding a client secret in a public binary?
- What is the difference between public, internal, confidential, and restricted data?
- What is the difference between public, internal, confidential, and PII data classifications?
- What is the difference between a confidential client and a trusted client?