Client Credentials: Get API Access Without Sharing Passwords

Verizon’s 2026 Data Breach Investigations Report found a third party involved in 48% of breaches, up from 30% the year before.[1] If you run automations for clients, you are that third party. And if you get client API access by asking for a password in a Slack DM, or keep client credentials in a shared spreadsheet, you’re exactly the kind of vendor that number counts.

My position: an agency should never hold a client’s password, and for most apps it shouldn’t even see the API key. The client grants access from their own account, with the narrowest permissions the provider offers.

Why Password Sharing Is the Worst Way to Get Client Access

A shared password gives you everything the client’s login can do, indefinitely, with no record that it was you. It can’t be scoped to one job, and it breaks the moment the client turns on MFA. The only way to revoke it is to change it for everyone, and the copy in the Slack thread never goes away.

GitGuardian’s 2026 State of Secrets Sprawl report found about 28% of leaked-secret incidents originate entirely outside code, in tools like Slack, Jira and Confluence, and those leaks were more likely to be rated critical than secrets found in code.[3] When GitGuardian retested credentials it had confirmed valid in 2022, more than 64% still worked in January 2026. People paste a secret into chat and never rotate it.

The 2026 DBIR is also the first edition in 19 years where stolen credentials weren’t the top way in; exploited vulnerabilities led at 31%.[1] Push Security’s read of the report still puts credential abuse somewhere in the attack chain of 39% of breaches.[2]

The Credential Ladder: Pick the Narrowest Access the App Offers

For every app a client uses, pick the most limited credential the provider supports. In rough order of preference: an OAuth grant the client approves, a restricted API key the client creates, a service account or app installed in the client’s workspace, and only then a full-access key. A password is never on the list.

• OAuth consent. The client signs in at the provider, approves specific scopes, and can revoke from their own settings. Google, HubSpot, Slack and QuickBooks work this way.
• Restricted API key. The client creates a key and picks what it can read or write, per resource.
• Service account or app install. For server-to-server jobs that shouldn’t belong to a person.
• Full-access key. Only when nothing narrower exists, and named so the client can find it later.

On every rung, the client creates the credential in their own account. You ask for it. You don’t make it with their login.

OAuth Done Right: Client API Access Without Passwords

OAuth is the cleanest way to get client API access without passwords. The client signs in at Google or HubSpot, sees exactly which permissions you’re asking for, and approves. The provider issues a token limited to those permissions, the client can revoke it without changing their password, and your agency never sees the login.

Whose name is on the consent screen?

Every consent screen names an OAuth app. Connect through an automation platform’s built-in integration and it usually names the platform, so your client sees a vendor they’ve never heard of asking to read their Gmail. The platform also controls the OAuth app every client connection depends on.

Registering your own OAuth app with each provider puts your agency’s name on the screen. The catch is that verification becomes your job.

Scopes are where least privilege actually happens

Ask for the smallest scope that runs the workflow. Watching for new emails needs gmail.readonly, not gmail.modify. Clients do read consent screens, and a scope list longer than the job erodes trust before you’ve built anything. We fixed exactly this in our own catalog this summer, after finding a Gmail trigger asking for modify access it never used.

Google verification costs weeks and real money

Google splits scopes into non-sensitive, sensitive and restricted, and the last two require app verification. Restricted scopes, which cover most of Gmail and Drive, also need a security assessment from a Google-approved assessor at least every 12 months, and Google warns the process can take several weeks.[5] Published assessor pricing runs $540 to $1,800 for Tier 2 and $4,500 for Tier 3.[6]

One exemption is worth knowing: apps used only by people inside the same Google Workspace organization don’t need verification.[5] For a single client who lives in Workspace, an Internal OAuth app in the client’s own Google Cloud project is a legitimate shortcut. It won’t scale to ten clients, but it gets client number one live this week.

Refresh tokens die, usually at a bad time

An OAuth connection lasts only as long as its refresh token. Google’s docs list the traps:[4]

• Testing mode. If your consent screen is External and still marked Testing, refresh tokens expire after 7 days unless you only asked for name, email and profile. It’s the classic way a Gmail automation dies a week after launch.
• The 100-token cap. Each Google Account gets 100 refresh tokens per OAuth client ID, and the 101st silently invalidates the oldest.
• Idle or reset. Tokens die after six months unused, and Gmail-scoped tokens die when the user changes their password.

Other providers run their own clocks. Slack apps with token rotation get access tokens that expire every 12 hours.[10] Intuit now caps QuickBooks refresh tokens at five years.[11] Whatever runs your automations has to refresh on schedule and tell a human when a client needs to reconnect.

API Keys: Restricted, Scoped, and One Per Client

When an app doesn’t support OAuth, ask the client to create a restricted API key in their own account and give it to the automation platform, not to you. A restricted key limits the damage if it leaks, and one key per client makes revocation a one-click job.

Stripe is the model. A restricted key starts with rk_live_ and lets the account owner set None, Read or Write on each resource.[7] For a workflow that syncs paid invoices into a CRM, the client creates a key that can read invoices and customers and nothing else, so a leaked key can’t issue refunds or trigger payouts.

HubSpot moved the same way: it labels UI-created private apps as legacy and recommends service keys for data-only integrations, scoped account-level keys that aren’t tied to one user and show last-used timestamps.[8] Name every key after your agency and its purpose, like “Acme Automations: invoice sync”, and never reuse one key across clients.

Service Accounts and Delegated Access

Some jobs don’t belong to a person, like a nightly database export or a bot posting in Slack. Use a non-human identity the client controls: a Slack app installed in their workspace, a dedicated database user, or a Google service account. Be careful with delegation, though.

Google Workspace domain-wide delegation is the one I’d push back on. It lets a service account impersonate any user in the organization, super admins included, and Google’s own guidance says to avoid it when the OAuth consent flow or a plain service account can do the job.[9] If a client’s IT team insists, have their admin authorize only the scopes the workflow needs.

Slack apps are easier. The client’s admin installs your app, the bot gets its own token, and messages post as the bot rather than as an employee. For databases, ask for a dedicated read-only user on the tables the workflow reads, never the admin connection string.

Credential Custody: Your Agency Shouldn’t See the Secret

Custody is about who can read a secret after it exists. The goal is that the client enters it once, it goes straight into the system that runs the automation, and nobody at your agency ever sees the raw value. A credential that never touches your inbox can’t leak from your inbox.

A shared password-manager vault beats Slack, but it still shows plaintext to your whole team and tells the client nothing about who opened it. The setups I trust look like this:

• The client enters the secret on a consent screen or form, through a link that expires.
• Once stored, it stays server-side and is never sent back to a browser, yours included.
• Your team attaches the connection to workflows without being able to read it.
• Clients can see and revoke every connection held on their behalf without asking you.

Custody is one part of keeping clients isolated; the rest is in per-client workflow automation governance.

Rotation and Revocation When the Client Leaves

Offboarding is where password sharing costs the most. If the client granted OAuth access or created their own keys, ending access is their call and takes minutes. If they handed you a password, they have to change it everywhere and hope nobody on your team kept a copy.

Settle ownership before you build. Who owns the account and who owns the credentials is its own conversation, covered in who should own client automations. Short version: the client should own every credential that touches their data, even when you own the workflow.

When a client leaves:

• Export workflows and run history if your contract promises them.
• Have the client revoke your OAuth apps in their Google, HubSpot or Microsoft settings, and uninstall your Slack app.
• Delete the restricted keys and service keys, and drop the database user.
• Confirm in writing that nothing on your side still holds a working credential.

During the engagement, rotate a key when someone with access leaves your team, and immediately if it shows up anywhere it shouldn’t. HubSpot’s order works for every provider: create the new key, update the integration, confirm it works, then delete the old one.[8] The full offboarding runbook lives in managing client automations.

Client Onboarding Access Checklist

Run this with every new client before you build anything. It takes about an hour on a kickoff call and saves the week you’d otherwise spend chasing logins. Send it ahead so the client can find out who actually holds admin rights to each app.

• List every app the automations touch, and who at the client is its admin.
• Pick a credential type per app from the ladder, OAuth first.
• Write down the exact scopes each workflow needs. Nothing extra.
• Publish your OAuth apps to production, not Testing, and get sensitive scopes verified before the client clicks approve.
• Send one access request covering every app, with a one-line reason for each.
• Have the client create keys in their own account, named after your agency.
• Record where each credential lives and how the client revokes it, in the handoff doc.
• Set a rotation date for anything that doesn’t expire on its own.

How TaskJuice Handles Client Credentials

We built TaskJuice so an agency never has to ask for a password. When a workflow node needs a client’s account, you mark it as client-provided and queue a request. The client connects the app themselves, and the credential goes from the client to the platform without passing through you.

Each client contact gets one branded email covering every app you queued. The link lasts 7 days for someone without a portal login and 4 hours for an existing portal user. OAuth apps open the provider’s own consent screen, and since TaskJuice requires your own OAuth app for every OAuth integration, that screen names your agency. For API keys, basic auth, or a database connection string for four common engines, MySQL and MongoDB among them, the client fills in a form on the same branded page.

The secret is stored server-side and never shown back in a browser. Clients see the connections they provided in their portal and can refresh, rotate or revoke them, and a workflow that depends on a revoked connection pauses until they reconnect. The honest cost: bringing your own OAuth app means the Google verification is yours to do.

Frequently Asked Questions

Should the OAuth app belong to my agency or to the client?

Usually your agency, one app per provider, so clients see your name and you verify once. The exception is one large client on Google Workspace, where an Internal app in their own Google Cloud project skips verification and stays theirs when you leave.

What happens to my automations when a client revokes access?

They stop. The next run that needs the connection fails or pauses until the client reconnects. That’s the design working: the client should be able to cut you off without asking. Make sure those failures reach a person, not just a log.

What does client credentials mean in OAuth?

In OAuth, “client credentials” is also a grant type where an app authenticates as itself with its own client ID and secret, no user involved, for server-to-server access. The least-privilege rules above apply to it too.

If you keep one rule, keep this one: the client creates the credential in their own account, with the fewest permissions that run the job, and you never see their password. A password sitting in a DM is the one mistake you can’t take back.

References

[1] Vulnerability exploitation overtakes stolen credentials as top breach entry point, 2026 DBIR, Verizon: www.verizon.com/about/news/breach-industry-wide-dbir-finds

[2] What the Verizon DBIR tells us about breaches in 2026, Push Security: pushsecurity.com/blog/verizon-dbir-2026-review

[3] The State of Secrets Sprawl 2026, GitGuardian: blog.gitguardian.com/the-state-of-secrets-sprawl-2026/

[4] Using OAuth 2.0 to Access Google APIs: Refresh token expiration, Google for Developers: developers.google.com/identity/protocols/oauth2

[5] Restricted scope verification, Google for Developers: developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification

[6] Google CASA Cloud Application Security Assessment, DeepStrike: deepstrike.io/blog/google-casa-security-assessment-2025

[7] Restricted API keys, Stripe Docs: docs.stripe.com/keys/restricted-api-keys

[8] HubSpot Service Keys: The Right API Credential for Data Integrations, HubSpot Developers: developers.hubspot.com/blog/hubspot-service-keys-the-right-api-credential-for-data-integrations

[9] Best practices for using service accounts securely, Google Cloud: docs.cloud.google.com/iam/docs/best-practices-service-accounts

[10] Using token rotation, Slack Developer Docs: docs.slack.dev/authentication/using-token-rotation/

[11] Important changes to refresh token policy, Intuit Developer: blogs.intuit.com/2025/11/12/important-changes-to-refresh-token-policy