The public identifier that tells an identity provider which application is requesting access. It is not a secret and does not prove the executable behind the request is legitimate, which is why impersonation of desktop clients can succeed if governance relies on the identifier alone.
Expanded Definition
Client ID is the public application identifier used during OAuth or similar delegated authorization flows to tell the identity provider which client is asking for access. It identifies the app, but it does not authenticate the app by itself. In practice, that distinction matters because definitions vary across vendors on how much trust a client identifier should carry in desktop apps, mobile apps, browser-based apps, and AI agents.
In NHI and IAM design, Client ID sits beside other protocol elements such as redirect URIs, PKCE, and client secrets, but it is not a substitute for proof of possession or device trust. The NIST Cybersecurity Framework 2.0 reinforces the broader principle that identity-related controls must support verified access, not just declared identity. For public clients, the identifier is often embedded in distributed software and can be observed by users or attackers, so governance must assume it is readable and reusable. That is why a Client ID helps route and classify the request, while the real security boundary comes from stronger controls around credential handling and authorization policy.
The most common misapplication is treating the Client ID as proof that the calling application is legitimate, which occurs when teams trust the identifier without validating the surrounding flow, redirect binding, or sender constraints.
Examples and Use Cases
Implementing Client ID rigorously often introduces deployment and support constraints, requiring organisations to balance smoother application onboarding against tighter validation of request origin and redirect behavior.
- A desktop app uses a Client ID to start an OAuth login, but PKCE is required so the app cannot redeem an intercepted code without the verifier.
- A browser-based single-page app publishes its Client ID openly, while the authorization server checks redirect URI registration and scopes before issuing tokens.
- An AI agent calling SaaS APIs presents a Client ID to identify the integration, but the platform still needs token audience checks and workload-level governance.
- A service integration team reviews the Ultimate Guide to NHIs to distinguish visible application identifiers from the broader lifecycle controls needed for non-human identities.
- Security architects compare client registration practices against NIST Cybersecurity Framework 2.0 so application identity is paired with access control, monitoring, and recovery planning.
In mature environments, the same Client ID may be reused across development, staging, and production, but that convenience should be weighed against the risk of confusing environments or expanding blast radius when tokens or registrations are exposed.
Why It Matters in NHI Security
Client ID matters because it is often the first thing an attacker can copy from a legitimate app, and copying it alone may be enough to impersonate the application in poorly governed flows. That is especially dangerous in NHI environments where machine access is frequent, automation is trusted, and application registrations can outlive the people who created them. The Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which shows how often the problem is not human login misuse but weak machine identity governance.
Client ID also intersects with Zero Trust thinking: the identifier should inform policy, not confer trust. If a desktop client is copied, repackaged, or embedded in malware, the attack can succeed unless additional controls such as PKCE, token binding, device posture, or workload attestation are enforced. This is why practitioners should treat Client ID as metadata for routing and policy, not as an access credential. Organisations typically encounter the consequences only after token abuse, code interception, or a fraudulent app registration is discovered, at which point Client ID governance becomes operationally 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 SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Identity proofing and authenticator strength inform how clients are distinguished from authenticated actors. | |
| NIST Zero Trust (SP 800-207) | 3.e | Zero Trust requires every request to be explicitly verified, not trusted because of a known client ID. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Public application identifiers become risky when they are mistaken for authenticated NHI ownership. |
Register, inventory, and review client applications so identifiers are never used as proof of legitimacy.
Related resources from NHI Mgmt Group
- How should security teams implement Client ID Metadata Documents?
- How should teams govern hybrid Active Directory and Entra ID at the same time?
- 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?
