5 common authentication methods for NHIs

Over the last couple of years, we’ve seen more and more teams start to take a proactive approach to securing non-human identities in their architecture. We’ve had lots of interesting conversations with clients about their NHI use cases. For Cerbos to support these scenarios, the process typically starts with issuing an identity to the NHI, authenticating it, and then using Cerbos to handle authorization.

During these conversations, 5 common authentication methods have come up again and again. In this article, we’ll explore these common authentication methods used for NHIs, analyzing each method's architecture, typical use cases, and real-world security posture.

Table of contents

• Certificate-based mutual TLS (mTLS)
• Stateless token authentication
• OAuth2 client credentials flow
• Asymmetric key authentication
• SPIFFE-based authentication

 

1. Certificate-based mutual TLS (mTLS)

Identity type: X.509 certificates

mTLS is a popular method because it's one of the stronger solutions for authorizing NHIs in machine-to-machine (M2M) and internal service-to-service communication. It’s an extension of the standard TLS protocol that increases security by requiring both the client and server to authenticate each other with X.509 certificates. These certificates are issued and validated by a trusted Certificate Authority, like LetsEncrypt, DigiCert, or GlobalSign.

Let’s take a look at its strengths and challenges (we will have the same format for all AuthN methods in this article):

Strengths	Challenges
• Strong cryptographic identity based on PKI (Public Key Infrastructure) • Provide encrypted transport and identity assurance • Non-repudiation and auditability	• Certificate management (rotation, renewal, handling revocation via CRLs or OCSP) can be complex • Requires a secure and scalable PKI • Deployment can be burdensome in dynamic environments without automation • Misconfigured certs (e.g., wrong SANs, mismatched CNs) often lead to silent handshake failures

Security posture: ✅ High

mTLS's mutual authentication with client certificates provides great security and has cryptographic assurances. With proper certificate management, it is a very scalable solution.

Real world use case:

A financial services company runs a microservices-based trading platform on Kubernetes. Each internal service (e.g., Order Service, Pricing Engine, Risk Engine) uses mTLS to authenticate calls between pods to ensure end-to-end encryption and identity verification. Service-to-service authentication is one of the common use cases for mTLS.

Potential risk for this scenario:

During a CI/CD deploy, a bad rollout fails to rotate a certificate, causing mTLS handshake failures and service disruption. Debugging is hard without good observability into the TLS layer.

 

2. Stateless token authentication

Identity type: API keys

API keys are static tokens, usually passed in headers or query parameters, that allow a client to authenticate to an API endpoint. They are simple and easy to use, which in the past has been one of their strengths. However, today most enterprises and established companies are moving away from API keys because they don’t expire or rotate and lack granularity.

Strengths	Challenges
• Simple to implement, easy to use, and works with basic header-based authentication and low-risk scripts • Lightweight and minimal processing overhead	• No built-in expiration unless wrapped with external logic, rotation, or scoping • Easily leaked in logs, URLs, or through code exposure • No proof of possession, as the attacker can reuse a stolen token indefinitely • Often lacks context as a key tells what it is calling, but not why or where it's running (who/what/why)

Security posture: ❌ Low

Most enterprises are moving away from API keys because they lack rotation, expiration, and scoping by default. These long-lived tokens are also easily leaked (as you will see in the example below), which makes them unsuitable for modern secure systems.

Real world use case:

A weather API provider issues static API keys to partner developers to access forecast data. Keys are passed in HTTP headers with each request. This pattern is common for public APIs, low-risk internal services, prototypes, or environments where ease of use and rapid integration outweigh strict security needs.

Potential risk:

One of the keys is accidentally committed to GitHub. The attacker makes thousands of requests, incurring cost and data leakage. Since there's no TTL or scoping, the token stays valid until manually revoked.

 

3. OAuth2 client credentials flow

Identity type: Client credentials (client ID + secret)

The OAuth2 client credentials flow is a widely used authentication method for machine-to-machine communication. It allows backend systems, internal services, and automated workloads to obtain short-lived, scoped access tokens (often in JWT format) from an OAuth 2.0 Authorization Server using a client ID and secret.

While mTLS can be layered on top of this for transport-level security, the client credentials grant is primarily used for logical identity and access delegation between non-human actors.

Strengths	Challenges
• Supports token expiry and fine-grained authorization (scopes) • Self-contained (JWTs can be verified without calling the issuer) • Compatible with federation and delegation models • Tokens signed with asymmetric keys (RS256, ES256) don’t require key sharing for validation. Compatible with federation and delegation models	• Requires secure storage of client credentials to prevent leaks • Revocation is supported but mostly skipped by teams or poorly implemented, especially with self-contained JWTs, so short TTLs are commonly used to reduce the impact of leaked tokens

Security posture: ✅ High

Client credentials support fine-grained access control, expiry, and revocation, making them well-suited for modern, distributed systems.

Real world use case:

A third-party app integrates using OAuth2 client credentials to access sensitive APIs. More use cases can include: machine-to-machine APIs, platform integrations, service backends, and SaaS systems where scalability and standardization are needed.

Potential risk:

The app is granted broad scopes like `read:all` and `write:all`, more than it actually needs. The attacker may misuse OAuth means by taking advantage of over-permissioning, making leaks far more damaging.

 

4. Asymmetric key authentication

Identity type: SSH key pairs

SSH keys offer secure authentication and a strong, asymmetric encryption model (e.g., RSA, ED25519, or ECDSA) with their paired public/private keys. The keys are mathematically linked, with the public key (which is stored on a server) posing a challenge that the private key (which the client holds) provides the answer. However, sanitation and sprawl are major drawbacks.

Common use cases for asymmetric key authentication are typically infrastructure automation, CI/CD deployments, and administrative access. Now let’s jump back to strengths & challenges:

Strengths	Challenges
• Strong cryptographic security because of key signatures • No shared secret transmitted over the network • This approach uses public-key cryptography for challenge-response, avoiding the need to share secrets	• Key sprawl and poor hygiene (e.g., keys never rotated). Keys are often manually generated and distributed, leading to key sprawl • Manual revocation and rotation, unless paired with automation tools (e.g., Teleport, AWS Systems Manager)

Security posture: ⚠️ Moderate

SSH keys offer strong security and cryptography. Their major downfall is that they do not offer automated key management (rotation, revocation, etc.). This can lead to long lived keys, if not automated through a second system.

Real world use case:

A DevOps team grants engineers SSH access to production servers using personal key pairs.

Potential risk:

Keys are manually added to servers but never removed when engineers leave. A former engineer’s laptop (with the private key) gets compromised, allowing unauthorized access to production.

 

5. SPIFFE-based authentication

Identity type: SPIFFE SVID (X.509 or JWT)

SPIFFE (Secure Production Identity Framework for Everyone) is an open standard designed specifically to issue and manage NHIs. The framework uses cryptographically verifiable identities like X.509-SVID or JWT-SVIDs to get rid of static secrets or long-lived tokens. Identity is built-in and continuously validated. This makes SPIFFE a secure, automation-friendly option for dynamic environments like zero-trust microservices architectures, multi-cloud workload federation, and identity for IoT or edge devices.

Strengths

Challenges

• No long-lived secrets • Certificates are dynamic, short-lived, as SVIDs (e.g., X.509 certs) typically rotate every few minutes • Self-contained (JWTs can be verified without calling the issuer) • Identity is cryptographically tied to workload runtime environment • Platform-agnostic, as it supports authentication across all platforms • Native support for mTLS-based service identities • Supports federation across trust domains via SPIFFE trust bundles

• Complex to set up, with a sharp learning curve • Requires a policy layer for authorization • Service mesh or tooling needed

Security posture: ✅ High

SPIFFE is actively developed by the Cloud Native Computing Foundation (CNCF) and is adopted or piloted by companies like Google, Netflix, and others for workload identity. That's because its strong cryptographic identity is very resilient to secret leakage. Plus, it's one of the few authentication methods that natively supports workload federation across organizations and cloud boundaries.

Real world use case:

An org sets up SPIFFE across multi-cloud clusters but forgets to sync trust bundles between domains.

Potential risk:

Federation silently breaks. Services can’t authenticate cross-domain workloads. Debugging becomes painful due to opaque cert issues and complex policy setups.

 

The “messy middle”

It’s important to mention the following disclaimer.

Most of the teams don’t rely on just one authentication method. They combine the methods like mTLS for service-to-service traffic, API keys for quick internal tools, SPIFFE for new zero trust, cloud-native projects and OAuth2 for third-party apps. It’s because every method works better in different scenarios. What matters is when and where to use each method, based on the system requirements and infrastructure. On top of this, even categorization cannot be that straightforward.

 

Why is categorizing AuthN methods hard for NHIs?

AuthN methods often overlap. For example, SPIFFE and mTLS both use X.509 certificates, but SPIFFE automates the whole lifecycle, while mTLS setups are often more manual. Both OAuth2 and SPIFFE can use JWTs, but for different flows or use cases. Some tools combine multiple methods (like using mTLS to get a token, or using SPIFFE to do OAuth2-style access control). Here, these methods sound separate but come under the same hood.

What looks like two different methods is often just a different way to automate, manage, or apply the same identity.

Because when methods reuse the same primitives (like certs, tokens, or keys), they can behave similarly even if they were designed for different things. You can say it comes under the spectrum of trade-offs, depending on your use case, rather than categorizing it.

 

Tradeoffs and considerations

Ultimately, there’s no one-size-fits-all solution. Building a strong authentication strategy for NHIs requires teams to account for both human and non-human identities. Each has different risks, lifecycles, and access patterns that need to be optimized for, which means there’s no single solution. The most effective approach is layered and adaptive, shaped by your architecture, threat model, and regulatory environment.

We like how the Aembit team visualized NHI authentication methods. Their matrix does a great job of showing how different approaches compare based on credential strength and how identity is separated from access. It helps clarify trade-offs like short-lived vs. long-lived tokens and whether credentials need to be shared:

And if you’re looking to go deeper into NHI security, our engineering team would be happy to run a personalized 1:1 session to explore your use case and permission management needs. Yes, a small moment of self-promotion, but a helpful one 🙂.