Why We Chose eBPF for Service Authentication

Service-to-service authentication is a solved problem — if you’re willing to accept the trade-offs. Sidecars add latency. mTLS adds operational complexity. API gateways become bottlenecks.

We wanted something different: per-request authentication at the kernel level, with zero application changes.

The Sidecar Problem

Service meshes like Istio and Linkerd use sidecar proxies. Every request passes through an additional container:

• Added latency: 1-5ms per hop
• Resource overhead: Each sidecar consumes CPU and memory
• Operational complexity: Managing thousands of sidecar containers
• Failure modes: Sidecar crashes take down the service

For latency-sensitive workloads, this overhead matters.

eBPF: Authentication at the Socket Layer

eBPF (extended Berkeley Packet Filter) lets you run sandboxed programs inside the Linux kernel. We compile JWT validation logic into eBPF bytecode that attaches to the socket layer.

The result:

• ~45μs per request — orders of magnitude faster than sidecar proxies
• Zero application changes — the eBPF program runs transparently
• Zero sidecars — no additional containers to manage
• Kernel-level enforcement — can’t be bypassed by application code

How It Works

1. An eBPF program attaches to the socket_filter hook
2. When a TCP connection arrives, the program extracts the JWT from the request
3. RS256/ES256 signature verification happens in eBPF bytecode
4. Claims are validated (expiry, issuer, audience, permissions)
5. If valid, the connection proceeds. If not, it’s dropped at the kernel — before reaching userspace

The Hard Parts

Compiling JWT validation into eBPF is non-trivial:

• BPF instruction limits — the verifier enforces bounded execution
• No dynamic memory allocation — everything must be stack-allocated or in BPF maps
• Cryptographic operations — RSA and ECDSA verification in constrained bytecode
• JWK rotation — public keys must be updated without reloading the program

We spent months solving these constraints. The result is a production-ready eBPF authentication layer that operates at kernel speed.

When to Use This

eBPF service authentication makes sense when:

• You need per-request auth with minimal latency
• You want to enforce auth at the infrastructure level, not application level
• You’re running microservices on Linux (most production environments)
• You want to eliminate the sidecar tax

It’s part of AuthFI’s Service Layer — one of the four layers of the Identity Control Plane.

---

Read more about the architectural choices behind Quefly’s products in the Open Memory Protocol spec.