The problem

Sender-constrained authentication is well understood in theory. Standards clearly describe the guarantees it provides.

In practice, those guarantees are difficult to deploy:

• they assume changes to token formats or identity providers
• they require tight coupling between clients, authorization servers, and resources
• they increase operational coupling across authentication and resource components
• they introduce binding state that must be coordinated during rollout and rollback

As a result, sender-constrained authentication often remains a protocol feature rather than a system property.

The approach

Plumbus treats sender-constraint as an enforcement concern, not an authentication concern.

Instead of embedding sender binding into authentication material, Plumbus enforces sender binding externally, at the service boundary, while treating authentication material as an opaque value.

This decouples sender-constraint guarantees from how authentication is issued or represented, and allows them to be enforced consistently across existing systems.

Placement within the system

flowchart LR
  FE["Frontend / Client"]
  PL["Plumbus
Enforcement Layer"]
  BE["Backend / Services"]

  FE -->|Requests + authentication material| PL
  PL -->|Forward or reject| BE          

In a Plumbus-enabled system:

• client interactions are intercepted by a Plumbus client component
• both identity-provider traffic and application traffic pass through Plumbus at the service boundary
• policy and configuration are applied centrally at the enforcement layer
• identity providers and application services remain unchanged

What Plumbus provides

• Non-invasive enforcement — no changes to identity providers, token formats, or application code
• Authentication-material independence — works with bearer tokens, session cookies, and proprietary credentials
• Stateless enforcement — no authentication state embedded into credentials or application logic
• Configuration-driven control — enforcement is explicit and selective
• Deterministic behavior — verifiable proofs, not heuristics
• Reversible deployment — introduce or remove without restructuring authentication flows

What Plumbus does not do

• It does not issue, inspect, or modify authentication material
• It does not replace identity providers or authorization servers
• It does not introduce tracking, fingerprinting, or behavioral identification
• It does not alter application-level authentication or authorization logic

Standards alignment

Standards define sender-constraint guarantees.

Plumbus enforces those guarantees consistently, while decoupling enforcement from token formats and identity-provider capabilities.

Guarantees enforced by Plumbus

Plumbus enforces the following sender-constraint guarantees, consistent with those defined by RFC 9449 :

• requests are bound to a single client-held cryptographic context
• authentication material cannot be replayed from a different sender
• proof of possession is verified for each protected request
• replayed or tampered requests are rejected before application logic

Summary

Plumbus is not an authentication mechanism. It is an enforcement layer.

It turns sender-constrained authentication from a protocol feature into a practical, deployable property of real systems.

Adopting sender-constrained authentication is a shift in security hygiene: once enforced, replayable credentials stop being an acceptable baseline.