Why Proof of Possession Matters More Than Ever

Every modern API relies on bearer tokens. You send a token in the Authorization header, the server checks if it's valid, and you're in. The problem? Anyone who has the token is in. Stolen from a log file, intercepted on the network, leaked through a debugging tool — it doesn't matter how they got it. The token works.

The Bearer Token Problem

Bearer tokens are symmetric trust: the server trusts whoever holds the token. There's no way to verify that the token is being used by the same entity it was issued to. This is the fundamental flaw in most API security models.

• Token theft via man-in-the-middle attacks on HTTP (or misconfigured HTTPS)
• Token leakage in server logs, error messages, or URL parameters
• Token extraction from compromised devices or browser storage
• Token reuse from shared machines or stolen backups

In each case, the attacker doesn't need the user's password. They don't need to authenticate at all. They just need the token.

What Is Proof of Possession?

Proof of Possession (PoP) changes the trust model. Instead of trusting the token alone, the server requires proof that the requester holds a private key that was bound to the token when it was issued. Every request is signed with this key. The server verifies the signature before processing the request.

In Enravo Core, this works through ECDSA P-256 key pairs. When a device enrolls, it generates a private/public key pair. The public key is registered with the server. Every mutating request (POST, PUT, DELETE) includes a signature computed from the request method, path, body hash, and a nonce — all signed with the device's private key.

// Sign a request with the device's private key
val signature = Crypto.sign(
    method = "POST",
    path = "/enravo/v1/orders",
    bodyHash = sha256(requestBody),
    nonce = generateNonce(),
    timestamp = System.currentTimeMillis(),
    privateKey = deviceKeyPair.private
)

// Attach to request
request.addHeader("X-PoP-Signature", signature)
request.addHeader("X-PoP-Nonce", nonce)

Why Stolen Tokens Become Worthless

With PoP in place, a stolen token is useless without the corresponding private key. The private key never leaves the device — on Android it's stored in the Android Keystore, on iOS in the Secure Enclave. Even if an attacker extracts the token from a network trace, they can't produce valid signatures.

The Guard Pipeline Integration

PoP verification is Stage 3 of Enravo Core's six-stage guard pipeline. Before the server checks if you have permission to access an endpoint (Stage 5), it has already verified your JWT (Stage 1), confirmed your device is registered (Stage 2), and validated your PoP signature (Stage 3). Each stage is independent — failing any one stops the request.

• Stage 1: JWT Validation — Is the token valid and not expired?
• Stage 2: Device Binding — Is this device registered to this user?
• Stage 3: Proof of Possession — Can the requester sign with the bound key?
• Stage 4: App Chain Check — Is the app legitimate and unmodified?
• Stage 5: Ability Check — Does this user have permission for this endpoint?
• Stage 6: Policy Enforcement — Does the request meet endpoint-level policies?

Nonce Replay Protection

Every PoP signature includes a unique nonce. The server tracks used nonces within a time window (default: 5 seconds). If the same nonce appears twice, it's a replay attack — and the device is immediately banned. This prevents an attacker who somehow captured both the token and a valid signature from replaying the request.

The combination of ECDSA signatures, device-bound keys, nonce tracking, and automatic threat response makes stolen tokens effectively worthless. This is what we mean by 'secure by architecture' — security isn't a feature you bolt on. It's how the system works.

Proof of Possession is available in Enravo Core for all API clients. It's required by default for mobile clients and configurable for web and server clients. If you're building an API that handles sensitive data, PoP should be part of your security model — not as an option, but as a requirement.