In OAuth 2.0, what makes a client confidential rather than public, and where does an installed mobile app fall?

## The one property that decides the type OAuth 2.0 does not grade a client by how reputable the company behind it is, what language it was written in, or whether the deployment is production. RFC 6749 §2.1 types a client on exactly one property: **whether it is capable of maintaining the confidentiality of its credentials**. - A **confidential** client can. It runs where the resource owner and the general public cannot read its storage or its memory — a server process, a scheduled job, a container on infrastructure the operator controls. It can therefore hold a `client_secret` or a private key and prove possession of it at the token endpoint. - A **public** client cannot. It runs on the resource owner's own device: an installed native application, a downloadable desktop tool, or script delivered to and executed by a browser. Whatever ships inside it is readable by whoever holds the device. The specification's own client profiles make the same cut. A *web application* — code executing on a server, where only rendered pages reach the browser — is confidential. A *user-agent-based application*, whose code is downloaded and runs in the browser, and a *native application*, installed on the device, are both public. ## Why "but we compiled it" is not an argument A credential compiled into a binary is still a string inside a file the user already possesses. It can be recovered from the package, read out of memory, or simply observed on the wire by anyone who can watch the software's own traffic on a device they own. Extraction only has to succeed once, anywhere in the install base, and the value is then known to everyone. That is the judgement this leaf exists to teach: **shipping a secret inside something the user installs does not make the client confidential — it makes the secret public.** Obfuscation raises the cost of the first extraction and changes nothing afterwards. The same value is in every copy, so the authorization server cannot tell an honest install from a hostile one, and rotating it means shipping a new release to every user at once. ## The consequence at the token endpoint Client type decides what the client may claim about itself when it talks to the authorization server: | | Confidential client | Public client | |---|---|---| | Registered `token_endpoint_auth_method` | a real method — for example `client_secret_basic` | `none` | | What the token endpoint learns | which client, and that it holds the credential | only which `client_id` the request claims | | `client_credentials` grant | permitted | MUST NOT be used (RFC 6749 §4.4) | | Refresh-token policy | ordinary | the authorization server MAY refuse or shorten them | A public client is not an untrusted or second-class application; it is an application that has *admitted it cannot authenticate*. The authorization server then knows only which registration a request names. Everything a public-client flow does to stay safe follows from that admission — including the extension of the authorization code grant that binds a code to the software that started the flow, which this branch covers separately. ## The type is a property of the component RFC 6749 §2.1 explicitly allows a client to be implemented as a distributed set of components, each with its own type and security context. A single product can have a server-side back end that keeps a key, and browser-delivered script that cannot. Where the authorization server does not support that shape directly, the specification says each component SHOULD be registered as a separate client — separate `client_id`, separate `redirect_uris`, separate `token_endpoint_auth_method`. The practical failure this prevents is the tempting shortcut: one registration for the whole product, with the confidential component's `client_secret` handed to the browser half so "the same client" can call the token endpoint from either side. That does not extend confidentiality to the browser; it removes it from the server. ## Reading it off a registration Because the type is recorded rather than inferred, you can read it off the client's registered metadata. A registration whose `token_endpoint_auth_method` is `none` is a public client whatever the marketing says; one that names a secret-bearing or key-bearing method is confidential, and the authorization server will hold it to that method on every token request. A vendor that ships a mobile companion to an existing server product therefore does not extend the existing registration — it registers a second, public client beside it.