NHI Authentication Guide: How Machines Prove Who They Are

Non-human identities (NHIs) authenticate constantly and silently. Every API call between services, every CI/CD job that deploys to the cloud, every AI agent that calls a tool, starts with a machine proving who it is. How it proves that is one of the most consequential security decisions an organisation makes, and one of the least visible. This guide explains the main ways NHIs authenticate, where each method fits, what goes wrong, and how to move from long-lived secrets towards short-lived, identity-based access.

Key takeaways

• Most NHI authentication still rests on possession of a secret. Whoever holds the API key, client secret or token is the identity, which is why leaked credentials are so damaging.
• The strongest patterns remove long-lived secrets altogether: platform-issued identities, workload identity federation, SPIFFE and certificate-bound or sender-constrained tokens.
• Choose the method by context: who issues the identity, how long the credential lives, whether it can be replayed if stolen, and how it is rotated and revoked.
• Insecure authentication (OWASP NHI4), long-lived secrets (NHI7) and secret leakage (NHI2) are three of the OWASP Non-Human Identities Top 10 risks, and all three trace back to authentication design.

What NHI authentication is, and why it is different

Authentication answers one question: is this caller who it claims to be? For people, the answer combines something they know, have or are, often with multi-factor prompts and interactive sign-in. Non-human identities, such as service accounts, API keys, OAuth applications, workloads, bots and AI agents, have none of that. There is no one to answer an MFA prompt and no browser session to protect. A machine authenticates by presenting something: a key, a secret, a signed token or a certificate.

That difference drives the whole risk profile:

• The credential is the identity. A stolen API key works just as well from an attacker’s laptop as from the service it was issued to, unless something binds it to its rightful holder.
• Credentials are copied, not typed. They end up in configuration files, environment variables, CI/CD variables, container images and code repositories, which is how secret sprawl begins.
• Lifetimes are long by default. A key created for a proof of concept can stay valid for years because nothing forces it to expire, and rotating it risks breaking production.
• Authentication and authorisation blur. Many static keys carry broad permissions, so proving identity also grants wide access in one step.

The main NHI authentication methods

The methods below run roughly from the most common (and weakest) to the most robust. Most organisations use several at once.

1. Static API keys and shared secrets

How it works: the provider issues a long random string; the client sends it with each request, usually in a header. The server looks the key up and maps it to an account.

Strengths: simple, universal, easy to implement for third-party APIs.

Risks: bearer-only (anyone holding the key can use it), frequently long-lived, often over-scoped, hard to attribute to a specific workload, and easy to leak in code, logs and client-side applications. API keys embedded in browser or mobile code should be treated as public. Incidents such as the Google API keys exposure in Gemini AI integrations, the Gravity SMTP API key exposure and the BeyondTrust API key compromise show how a single key becomes the entry point.

Where it fits: low-risk integrations, or third-party services that offer nothing better. Scope keys narrowly, restrict them by source network or referrer where the provider allows, store them in a secrets manager, and set an expiry.

2. OAuth 2.0 client credentials

How it works: the client application authenticates to an authorisation server and receives a short-lived access token, which it then presents to APIs. The client credentials grant is defined in RFC 6749, section 4.4 and is the standard machine-to-machine OAuth flow: no user is involved.

How the client proves itself to the authorisation server matters:

• Client secret: a shared secret, which carries the same leakage risks as an API key, but at least produces short-lived tokens for the APIs themselves.
• Private key JWT (private_key_jwt): the client signs a short assertion with its private key (RFC 7523). The private key never leaves the client, so there is no shared secret to steal from the server side.
• Mutual TLS: the client authenticates with an X.509 certificate (see method 3).

Strengths: short-lived, scoped access tokens; central issuance, auditing and revocation; standard across identity providers and API gateways.

Risks: access tokens are usually bearer tokens, so a stolen token works until it expires; client secrets are still long-lived; and OAuth applications granted access to SaaS data become high-value targets. The Salesloft Drift OAuth token breach, the Klue OAuth supply chain breach and the Vercel Context.ai OAuth breach all show stolen OAuth tokens being used to reach connected SaaS data.

Where it fits: service-to-service calls across trust boundaries, partner integrations and API platforms. Prefer private_key_jwt or mTLS over client secrets. Follow the OAuth 2.0 Security Best Current Practice (RFC 9700).

OAuth or OpenID Connect? OAuth issues access tokens for calling APIs. OpenID Connect adds an ID token that describes an authenticated end user. In pure service-to-service flows there is usually no end user, so the client credentials grant, not OIDC sign-in, is the relevant pattern. OIDC matters for machines in a different way: as the token format behind workload identity federation (method 5).

3. Mutual TLS and certificate-bound tokens

How it works: both sides of a TLS connection present certificates, so the server authenticates the client cryptographically during the handshake. RFC 8705 extends this to OAuth: the client can authenticate to the authorisation server with its certificate, and access tokens can be bound to that certificate so they are useless without the matching private key.

Strengths: strong, non-replayable authentication; certificate-bound tokens neutralise stolen-token replay.

Risks: certificate lifecycle management (issuance, renewal, revocation, trust store hygiene) is hard at scale; expired certificates cause outages; private keys stored on disk can still be stolen.

Where it fits: internal service-to-service traffic (often via a service mesh), high-assurance APIs, financial-grade integrations.

4. Sender-constrained tokens with DPoP

How it works: Demonstrating Proof of Possession (RFC 9449) binds an access token to a key pair held by the client. Each request carries a signed proof, so a token copied from logs or memory cannot be replayed from elsewhere. Unlike mTLS, it works at the application layer and does not need client certificates.

Where it fits: APIs where bearer-token theft is a realistic threat and mTLS is impractical. Support varies by identity provider and gateway, so check before designing around it.

5. Platform-issued identities and workload identity federation

The most effective way to stop secrets leaking is to not have them. Cloud platforms and CI/CD systems can issue identities to workloads directly and exchange them for short-lived credentials.

• Cloud-native identities: an AWS workload assumes an IAM role and receives temporary credentials from AWS STS; Azure workloads use managed identities; Google Cloud workloads run as an attached service account and obtain tokens from the metadata server. No static key is stored in the application.
• Workload identity federation: a workload outside the cloud (another cloud, an on-premises system, a CI/CD runner) presents a signed OIDC token from its own platform; the cloud provider validates it against a configured trust relationship and returns short-lived credentials. AWS supports this through AssumeRoleWithWebIdentity, Azure through federated identity credentials, and Google Cloud through Workload Identity Federation.
• Keyless CI/CD: GitHub Actions and other CI platforms can issue an OIDC token for each job, which the cloud exchanges for temporary credentials. This removes long-lived cloud keys from CI/CD variables, the kind of secret exposed at scale in the tj-actions supply chain attack.

Risks: the trust policy becomes the control. A federation rule that trusts a whole organisation or every branch, rather than a specific repository, workflow and environment, lets any job in scope assume the role. Review the subject and audience conditions as carefully as you would a firewall rule.

6. Kubernetes service account tokens

How it works: every pod runs as a Kubernetes service account. Current Kubernetes versions mount short-lived, audience-bound tokens into pods through projected volumes, issued by the TokenRequest API and rotated automatically, and they no longer create long-lived token Secrets for service accounts automatically. Managed Kubernetes services can map these service accounts to cloud identities (for example IAM Roles for Service Accounts or EKS Pod Identity on AWS, and workload identity on Azure and Google Cloud), so pods reach cloud APIs without static keys.

Risks: legacy long-lived token Secrets still present in older clusters, the default service account used for everything, tokens mounted into pods that never call the Kubernetes API, and broad RBAC bindings. Kubernetes Secrets objects holding application credentials are a separate sprawl problem.

7. SPIFFE and SPIRE

How it works: SPIFFE defines a standard workload identity (a SPIFFE ID) and short-lived identity documents called SVIDs, either X.509 certificates or JWTs. SPIRE attests each workload (checking what it is and where it runs) before issuing SVIDs and rotates them automatically. Workloads use them for mTLS or to authenticate to other systems. See our guide to SPIFFE and SPIRE for the detail.

Where it fits: heterogeneous, multi-cloud or hybrid estates that need one portable workload identity rather than a different mechanism per platform.

8. SSH keys and SSH certificates

Automation still authenticates to servers with SSH key pairs, which are rarely inventoried, rarely rotated and often shared. OpenSSH also supports SSH certificates: a trusted certificate authority signs a short-lived certificate for a key, so servers trust the CA rather than a growing list of authorised keys, and access expires on its own.

9. Token exchange and delegation, including AI agents

Sometimes a workload must act on behalf of a user or another service. OAuth Token Exchange (RFC 8693) lets a service trade the token it received for a new token scoped to the next hop, instead of forwarding the original. This matters for AI agents, which increasingly call APIs and tools on a user’s behalf: each hop should carry a narrowly scoped, audience-bound token that records who delegated what, not a broad token copied from the user or a static key embedded in the agent.

Comparing the methods

Method	What proves identity	Typical lifetime	Replay if stolen?	Rotation burden	Best fit
Static API key / shared secret	Possession of a string	Months to years	Yes	High, manual	Low-risk or third-party APIs with no alternative
OAuth client credentials (client secret)	Shared secret, then access token	Secret long-lived; token minutes to hours	Token: yes, until expiry	Medium	Cross-boundary service calls
OAuth with private_key_jwt	Signed assertion from a private key	Key long-lived; token short	Token: yes, until expiry	Medium (key rotation)	Service calls where secrets must not be shared
mTLS / certificate-bound tokens	Private key behind an X.509 certificate	Certificate days to months (automate)	No, token bound to the key	Automate or it fails	Internal service-to-service, high-assurance APIs
DPoP	Proof signed by a client-held key	Token short	No	Low	APIs where bearer-token theft is a concern
Cloud-native identity (IAM role, managed identity)	Platform attestation	Minutes to hours, auto-renewed	Yes, for the short window	None for the app	Workloads running inside one cloud
Workload identity federation	Signed OIDC token from the workload’s platform	Minutes to hours	Yes, for the short window	None; review trust policies	Cross-cloud, on-premises and CI/CD workloads
Kubernetes projected tokens	Cluster-issued, audience-bound JWT	Short, auto-rotated	Yes, for the short window and audience	None	Pods calling the cluster or cloud APIs
SPIFFE SVIDs	Attested workload identity (X.509 or JWT)	Short, auto-rotated	X.509 via mTLS: no	None	Multi-cloud and hybrid workload identity
SSH certificates	CA-signed certificate for a key	Hours to days	Within validity	Low	Automation access to servers

A maturity path: from static secrets to secretless

1. Find what exists. Inventory API keys, client secrets, tokens, certificates and SSH keys, including those in code, CI/CD variables and container images. You cannot improve authentication you cannot see; the NHI lifecycle management guide covers discovery and ownership.
2. Contain static secrets. Move them into a secrets manager, scope them to least privilege, restrict where they can be used from, assign an owner and set an expiry.
3. Shorten lifetimes. Replace long-lived credentials with short-lived tokens issued on demand. Our static versus dynamic secrets section explains the trade-offs.
4. Remove secrets from the workload. Use cloud-native identities, workload identity federation, Kubernetes projected tokens and keyless CI/CD so there is nothing to store or leak.
5. Bind tokens to their holder. Use mTLS, certificate-bound tokens or DPoP for high-value APIs, so a stolen token cannot be replayed.
6. Standardise identity. Adopt a consistent workload identity (for example SPIFFE) and central policy, so authentication works the same way across clouds and platforms.

The Machine-to-Machine Identity Maturity Model sets out a comparable progression.

Common failure patterns

These map directly to the OWASP Non-Human Identities Top 10, particularly NHI2 (Secret Leakage), NHI4 (Insecure Authentication) and NHI7 (Long-Lived Secrets).

• Hardcoded and leaked credentials: keys and tokens committed to repositories, baked into images or logged in plain text. The Home Depot token exposure stayed public for over a year, and authentication secrets hidden in Docker Hub images show the same pattern in containers.
• Over-permissive credentials: a single token granting far more than the workload needs. The Microsoft SAS token exposure is a well-known example of an overly permissive, long-lived access token.
• Credentials exposed by the tools around them: developer tooling and integrations leaking tokens, as in the JetBrains GitHub plugin token exposure.
• Compromise of the identity layer itself: when the systems that issue or store machine credentials are breached, every dependent NHI is exposed, as the OneLogin API key vulnerability exposing OIDC secrets illustrates.
• Deprecated or weak methods left in place: basic authentication, shared service passwords or unauthenticated internal endpoints that assume the network is trusted.
• No revocation plan: teams that cannot quickly revoke and reissue a credential after a vendor breach or leak stay exposed for days.

Authenticating machine clients at the API gateway

API gateways are where most NHI authentication is enforced. Practical guidance:

• Prefer token-based authentication over raw API keys. Validate OAuth access tokens (signature, issuer, audience, expiry and scopes) at the gateway, and use API keys mainly for identification and rate limiting rather than as the sole proof of identity.
• Validate the audience. A token issued for one API must not be accepted by another. Missing audience checks turn one leaked token into access to many services.
• Separate authentication from authorisation. Authenticating the caller at the gateway does not replace object- and function-level authorisation in the service. Broken object-level authorisation is the top risk in the OWASP API Security Top 10.
• Use mTLS for internal and partner traffic where client certificates can be managed, and sender-constrained tokens for high-value external APIs.
• Do not trust the network. Internal APIs need authentication too; zero trust applies to service-to-service calls as much as to users.
• Log the identity, not just the key. Record which workload, client ID or SPIFFE ID made each call, so misuse can be traced and a single credential revoked without an outage.

AI agents and MCP servers

AI agents are NHIs that act with more autonomy, and they multiply authentication paths: the agent to its tools, the tools to downstream APIs, and often a user delegating authority to the agent. The same principles apply, with extra care:

• Give each agent its own identity. Do not reuse a human’s credentials or a shared service key across agents.
• Use delegated, scoped tokens. When an agent acts for a user, use OAuth delegation or token exchange so the agent’s access is limited to the task and traceable to the user who granted it.
• Follow the MCP authorisation model for remote servers. The Model Context Protocol authorisation specification (June 2025 revision) builds on the OAuth 2.1 draft: a protected MCP server acts as an OAuth resource server, publishes Protected Resource Metadata (RFC 9728), and clients must request audience-bound tokens using Resource Indicators (RFC 8707). MCP servers must validate that tokens were issued for them and must not pass a client’s token through to upstream APIs. Authorisation is optional in the specification, and local STDIO servers take credentials from the environment instead, so check how each server you deploy actually authenticates. Later revisions of the specification may change details.
• Watch for token theft through agent platforms. The CoPhish campaign abusing Copilot Studio agents shows OAuth tokens being harvested through AI agent experiences.

Practitioner checklist

• Inventory every machine credential and give each an accountable owner.
• Remove credentials from code, images and CI/CD variables; scan continuously for new leaks.
• Replace long-lived cloud keys with IAM roles, managed identities, attached service accounts or workload identity federation.
• Move CI/CD pipelines to OIDC-based, keyless authentication, with trust policies pinned to specific repositories, branches and environments.
• Prefer private_key_jwt or mTLS over client secrets for OAuth clients.
• Validate issuer, audience, expiry and scope on every token; never accept tokens issued for another service.
• Bind tokens for high-value APIs with mTLS or DPoP.
• Set expiry on every credential that cannot yet be eliminated, and automate rotation.
• Prepare revocation runbooks for third-party and OAuth integrations before an incident.
• Give AI agents their own identities and delegated, audience-bound tokens.

Standards and references

• OWASP Non-Human Identities Top 10 (2025): NHI2 Secret Leakage, NHI4 Insecure Authentication, NHI7 Long-Lived Secrets
• RFC 6749: The OAuth 2.0 Authorization Framework (client credentials grant, section 4.4)
• RFC 9700: Best Current Practice for OAuth 2.0 Security
• RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
• RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
• RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP)
• RFC 8693: OAuth 2.0 Token Exchange
• RFC 8707: Resource Indicators for OAuth 2.0 and RFC 9728: OAuth 2.0 Protected Resource Metadata
• Model Context Protocol: Authorization specification
• SPIFFE concepts
• OWASP API Security Top 10

Related NHI Mgmt Group resources: The Ultimate Guide to Non-Human Identities · Guide to the Secret Sprawl Challenge · Guide to NHI Rotation Challenges · Guide to SPIFFE and SPIRE