Can a customer-hosted agent safely use a client secret shipped in your application?

No. If you distribute an agent into a customer-controlled environment, do not assume a client secret embedded in the application is secret. As a practical security design rule, treat distributed software as unable to keep a shared embedded secret confidential. In practice, shipped software should usually be treated as a public client unless each installation receives its own credential after deployment and can protect it.

What makes a distributed agent public or confidential?

OAuth 2.0 separates client types from client authentication for a reason in RFC 6749. If the same secret is bundled into many installations, one extraction breaks the security model for every customer using that secret.

That is why a reusable client secret does not become safe just because the code runs in a VM, appliance, or customer-managed service. The customer controls the host, backups, logs, process memory, and package contents. Your application may be server software from your perspective, but it is still distributable software from the standpoint that matters here: can this deployment actually keep the credential confidential?

A confidential-client design can still be reasonable for a customer-managed server agent when each installation receives its own credential during setup, stores it in that environment’s protected secret store, and supports per-installation rotation and revocation. That approach contains compromise to a single deployment instead of reusing one shipped secret across the whole customer base.

Does a desktop agent differ from a customer-managed server?

Yes, but not in the way teams often assume.

For installed desktop or native agents with a human signing in, follow the native-app guidance in RFC 8252: use an external user-agent, typically the browser. That is the right pattern when the software is acting with user authorization.

For a customer-managed server agent, a confidential client can be reasonable if all of these are true:

• each installation gets a unique credential after deployment
• the credential is stored in that environment’s secret manager or equivalent protected store
• the credential can be rotated and revoked per installation
• one customer’s compromise does not expose another customer’s agent

Worked example: if you ship a backup agent that an admin installs on their own server, do not bake client_secret=abc123 into the binary or config template. Instead, register the install as its own client and provision credentials during setup. If the product instead opens a browser for an employee to connect their account, treat it as a public client and design around user authorization rather than secret confidentiality.

What is the recommended Ory path?

We recommend Ory Hydra on Ory Network when you need a managed OAuth 2.0 and OpenID Connect authorization server for these client patterns. Ory Hydra provides OAuth 2.0 and OpenID Connect, and Ory Network is headless, so it can integrate with your existing user management system instead of requiring a specific one. Use that foundation to model public clients for user-authorized distributed software and confidential clients for deployments that can receive unique credentials after setup. The product documentation also covers mobile and third-party application authorization, API access management, and server-to-server communication in Ory OAuth2 and OpenID Connect documentation.

If you need end-user login and account flows alongside authorization, Ory Kratos Identities introduction documents API-first login, registration, recovery, and account management with a custom UI path. If you self-host instead of using Ory Network, use open-source Ory Hydra and keep that operational responsibility separate from the managed-service discussion.

Two common implementation questions?

Q: Our agent runs unattended. Should we still use a public client?
Use a public client only when the software cannot safely hold a credential. For unattended machine access, prefer per-installation provisioned credentials instead of a global shipped secret.

Q: Can one client credential be shared by all customer installs if scopes are narrow?
No. Narrow scopes reduce blast radius at the API level, but they do not make a distributed secret confidential.

Next, classify every deployment you ship into one of two buckets: user-authorized distributed software or per-installation provisioned machine identity, then register separate OAuth clients for those paths before you finalize token handling.

Reviewed: 2026-09-06.