DEV Community: kt

xDS Deep Dive: Dissecting the "Nervous System" of the Service Mesh

kt — Mon, 20 Apr 2026 15:40:41 +0000

Introduction

I was debugging Istio routing the other day, and honestly, I had a moment where I felt a bit "creeped out."

You tweak a VirtualService YAML file, hit kubectl apply, and within seconds, the routing rules across hundreds of Envoy proxies scattered throughout the cluster switch over perfectly.

There's no process restart. You aren't running nginx -s reload. Rolling out configuration changes to thousands of hosts happens in seconds, and even if you push a completely broken YAML, it magically rolls back to a safe state on its own.

It feels like magic, but naturally, there's an incredibly gritty mechanism running behind the scenes. That mechanism is xDS (xDiscovery Service).

You might think of it as just "Envoy's config protocol," but xDS has long escaped Envoy's borders. Today, it's standardized as the "Universal Data Plane API" (the lingua franca of L4/L7 networking) by the CNCF xDS API Working Group, heavily used by gRPC (Proxyless) and Cilium's ztunnel. As of 2026, it is the absolute most important protocol to understand if you want to talk about service mesh.

We are going to read through this from top to bottom—covering why static configuration is a nightmare, the dependency chain of LDS/RDS/CDS/EDS, and the ACK/NACK rollback mechanism that saves us from outages.

0. Prerequisites: Why use an "API" to push configurations?

Envoy and Protocol Buffers

The decisive difference between Envoy and traditional reverse proxies like Nginx or HAProxy is that Envoy was built from the ground up on the premise that configuration will be injected externally, in real-time, via gRPC.

Envoy doesn't do service discovery on its own. The control plane (like Istio's istiod) watches Kubernetes Pods and Services, translates them into strongly-typed Protocol Buffers (proto3) messages that Envoy understands, and streams them over HTTP/2 gRPC. By using gRPC streaming instead of JSON polling, it achieves incredibly low latency and type safety.

1. The Despair of Static Configuration and the Awakening of xDS

If you were to configure Envoy statically, you’d end up writing an envoy.yaml file like this:

static_resources:
  listeners:
  - name: my_listener
    address:
      socket_address: { address: 0.0.0.0, port_value: 8080 }
    # ...filter configs...
  clusters:
  - name: my_backend
    type: STRICT_DNS
    load_assignment:
      cluster_name: my_backend
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address: { address: 10.0.1.15, port_value: 8080 }

In the idyllic days when you only had 10 Pods, this was fine. But in today's Kubernetes environments, Pods scale every second, they fluctuate due to HPA, and IPs change constantly as nodes are retired. Every time a backend IP changes, are you going to rewrite the config files for all proxies and restart their processes? That's pure insanity. Connections would drop, latency would spike, and the system would collapse.

That is exactly why dynamic configuration (xDS) is mandatory.

With xDS, Envoy can seamlessly start routing traffic to new Pod IPs with absolutely zero restarts.

2. The Core 5 Discovery Services

The "x" in xDS is a wildcard. The protocol is heavily segmented into five major services (APIs) based on the scope of the configuration.

These aren't just parallel configuration items—they have strict dependencies (pointers) on one another. Grasping this dependency chain is step one to mastering xDS.

LDS (Listener): Which port should we listen on?
RDS (Route): Which path routes to where?
CDS (Cluster): What are the connection settings for the destination service?
EDS (Endpoint): What are the actual IP addresses of that service?
SDS (Secret): What certificate data (e.g., for TLS termination) do we need?

Let's look at how they point to each other at the YAML/code level.

① LDS → Pointing to RDS

LDS creates the entry point, defining "Listen for HTTP on port 8080." However, instead of hardcoding IP destinations for the traffic, it embeds a reference (name) to the RDS.

# Data streamed from LDS (Listener Discovery Service)
name: my_listener
address:
  socket_address: { address: 0.0.0.0, port_value: 8080 }
filter_chains:
- filters:
  - name: envoy.filters.network.http_connection_manager
    typed_config:
      rds:
        route_config_name: my_routes  # ← [KEY] Refers to RDS resource "my_routes"

② RDS → Pointing to CDS

RDS is the "signboard." Called up by LDS as my_routes, this config evaluates HTTP paths or headers and returns a logical cluster name (a reference to CDS). Istio's VirtualService gets translated into this layer.

# Data streamed from RDS (Route Discovery Service)
name: my_routes
virtual_hosts:
- name: api_host
  domains: ["api.example.com"]
  routes:
  - match: { prefix: "/v1/" }
    route: { cluster: api-v1-cluster }  # ← [KEY] Refers to CDS resource "api-v1-cluster"

③ CDS → Pointing to EDS

CDS defines the nature of the designated cluster. It determines the load balancing algorithm (Round Robin, etc.) and circuit breaker thresholds. This is the domain of Istio's DestinationRule.

It still doesn't write down specific IP addresses here; it delegates the final resolution to EDS.

# Data streamed from CDS (Cluster Discovery Service)
name: api-v1-cluster
type: EDS                           # ← [KEY] Declares we will fetch endpoints dynamically via EDS
eds_cluster_config:
  eds_config: { ads: {} }           # (Requests EDS via ADS)
lb_policy: ROUND_ROBIN

④ Touching Down at EDS

Finally, EDS returns the actual IP addresses of the Pods tied to that cluster. Because clusters scale up and down, EDS is the most aggressively updated component in xDS.

# Data streamed from EDS (Endpoint Discovery Service)
cluster_name: api-v1-cluster
endpoints:
- lb_endpoints:
  - endpoint:
      address:
        socket_address: { address: 10.0.1.15, port_value: 8080 }  # ← Actual IP
  - endpoint:
      address:
        socket_address: { address: 10.0.1.22, port_value: 8080 }  # ← Actual IP

⑤ Encrypting via SDS (mTLS) and Zero-Downtime Rotation

Once the destination IP is pinned down, we don't just blindly fire the packet. In modern service meshes, mTLS (mutual TLS) encryption between Pods is mandatory. This is where SDS (Secret Discovery Service) steps onto the stage.

Inside the CDS definition, it dictates "use this specific TLS context when talking to this cluster." Envoy then uses SDS to dynamically fetch the certificate (SVID) and private key straight into memory.
What's spectacular here is certificate rotation. Before a certificate expires, you historically had to restart the web server process. With SDS, the microsecond a new certificate is issued, it is flashed into memory via xDS, enabling 100% zero-downtime, automated certificate rotation. Because this is highly sensitive secret data, this specific stream is strictly gated and protected.

# Conceptual data streamed from SDS (Secret Discovery Service)
name: default
tls_certificate:
  certificate_chain: { inline_string: "-----BEGIN CERTIFICATE-----\n..." }
  private_key: { inline_string: "-----BEGIN PRIVATE KEY-----\n..." }

In short, a packet perfectly traces the configuration pointers in the exact order of LDS → RDS → CDS → EDS (+ SDS), encrypts itself, secures routing, and takes flight.

You must never forget this "dependency order." It is the exact reason why ADS (Aggregated Discovery Service), which we'll discuss later, exists.

3. Surviving Broken Configs: The ACK/NACK Flow

In an architecture where dynamic configs are blasted out to thousands of proxies, pushing a "bad config" causes apocalyptic damage. What happens if the control plane sends a malformed JSON or a conflicting route setting?

Does Envoy bug out and crash? ...Absolutely not.
xDS is armed with a fiercely robust rollback mechanism called "NACK" (Negative Acknowledgement).

xDS communication is a bidirectional gRPC stream. When a DiscoveryResponse arrives from the control plane, Envoy attempts to apply it. It then packages the result into a DiscoveryRequest and shoots it back to the control plane.

The absolute beauty of this design is that even if a NACK occurs, Envoy's stream does NOT sever; it just keeps humming along using the last-known-good config (v1).
Even if an operator brutally applies a flawed VirtualService to Kubernetes, Envoy essentially says "screw this," returns a NACK, and existing traffic doesn't drop a single millisecond. It simply waits idly for a corrected config to be pushed.

Two control fields are the key players here: nonce and version_info.

nonce: A simple ID that says, "Hey, which specific update payload are you giving me the validation result for?"
version_info: The factual state that says, "As a result, what version of the config am I currently running?"

If Envoy simply parrots back the latest version_info the server sent, it's categorized as an "ACK (Success)." If it returns an older version number, the server realizes it's a "NACK (Failure)." It’s brilliantly simple, yet ruthlessly effective.

4. Why We Need ADS (Aggregated Discovery Service)

Earlier, I mentioned that LDS → RDS → CDS → EDS share a strict dependency chain.

What would happen if you subscribed to these four APIs via completely separate gRPC streams asynchronously from the control plane? Naturally, due to network latency or processing timing, their arrival order would scramble.

Imagine the worst-case scenario.
A new RDS (route setting) arrives first. It says, "route traffic to cluster-B". Envoy eagerly updates its settings and tries to shove traffic towards cluster-B. However, the streams for CDS and EDS (the actual definition and IPs of cluster-B) are lagging slightly behind and haven't hit Envoy yet.

As a result, Envoy concludes "the destination cluster doesn't exist" and starts aggressively throwing 503 Service Unavailable errors. A service mesh where 503s run rampant every time a configuration changes is completely unusable.

The Fix: Bundling the Streams (ADS)

To prevent this "temporary inconsistency in an eventually consistent system," ADS (Aggregated Discovery Service) was forged.

ADS multiplexes (aggregates) the requests and responses for ALL xDS resource types (LDS/RDS/CDS/EDS) into a single solitary gRPC stream.

By bundling everything into one stream, the control plane gains the ability to enforce perfect Sequencing: "I will force Envoy to apply CDS/EDS first, and I won't send RDS until I get the ACKs back."
Istio's control plane (istiod) uses this ADS approach by default to stream configurations safely.

5. SotW vs Delta: Taming the Infinite Endpoint Explosion

Looking back at the history of xDS brings us to another massive evolutionary fork: how the configs are sent.

The Limits of State of the World (SotW)

Early xDS utilized a model called SotW (State of the World). When Envoy asks "Tell me the current endpoints," the server responds by sending back "the entire, exhaustive list of endpoints" every single time.

Let's assume you have a cluster of 1,000 Pods, and a single Pod scales out, making it 1,001.
In the SotW model, istiod beams out the full list of 1,001 IP addresses to every single Envoy proxy. The 1,000 unmodified records are re-transmitted entirely. This is a colossal waste of network bandwidth and CPU horsepower. Once your cluster scales large enough, the control plane literally chokes and dies.

The Dawn of Incremental (Delta) xDS

This crisis birthed Delta xDS.
When returning subscription requests, the server now sends "only the diff from the last state (added IPs, removed IPs)."

SotW: [IP_A, IP_B, IP_C] (If B is deleted, it resends [IP_A, IP_C]. Items missing from the list are implicitly assumed deleted.)
Delta: removed_resources: ["IP_B"] (Explicitly sends ONLY the deletion directive.)

Because the server must maintain an in-memory cache tracking the individual state of every single client, the backend implementation becomes drastically more complex. However, the performance gains are monumental. Modern service meshes circa 2026 (like recent versions of Istio) securely default to Delta xDS.

6. Beyond Routing: Advanced xDS Use Cases

When discussing xDS, it's impossible to ignore the fact that xDS is no longer an "Envoy-exclusive routing protocol." As of 2026, the xDS ecosystem has wildly expanded beyond basic routing and breached into non-Envoy clients.

6.1 Dynamic Injection of Extensions (ECDS)

ECDS (Extension Config Discovery Service) is a mechanism to dynamically push "extension filters" (like WebAssembly) directly into Envoy.
For example, you write a proprietary Wasm module that applies custom obfuscation to a specific HTTP header, and you stream it via ECDS. This lets you hot-reload and inject brand-new Wasm modules into every proxy safely, while they are running, without touching LDS or RDS at all.

6.2 Streaming Runtime Variables (RTDS)

RTDS (Runtime Discovery Service) skips routing altogether and instead streams "runtime variables" (think of it as a virtual file system).
Need to flip a new feature ON/OFF (feature toggles) or temporarily throttle a specific user's rate limits? You use RTDS. It instantly propagates single variable tweaks to thousands of proxies without forcing an application rebuild or redeploy.

6.3 Building Proprietary Control Planes (`go-control-plane`) & Case Studies

Because the xDS specs are fully open (defined in Protobuf), it's highly common for massive-scale environments to ditch off-the-shelf products like Istio and build their very own bespoke xDS control planes.

Libraries provided by the Envoy project, like go-control-plane, shoulder the agonizing implementation burdens of operating an xDS gRPC server (handling streams, snapshot caching, etc.). By wiring this up, companies can construct proprietary control planes that use "internal corporate databases" as the Source of Truth, governed by heavily customized business logic.

Tech Giant Case Studies:
For companies wrestling with horribly complex "brownfield" infrastructure, these custom control planes are a lifeline.

Stripe: They operate an internal service mesh using HashiCorp Consul as the Source of Truth for service discovery. They built a custom control plane that snags data from Consul, compiles it into xDS parameters, and streams it to Envoy.
Netflix: To manage their astronomical fleet of microservices, Netflix built a custom foundation fused with Eureka (their service registry). By aggressively utilizing On-Demand Cluster Discovery (ODCDS), they dynamically inject only the settings Envoy actually needs, shattering the scaling boundaries of giant clusters.
Airbnb / Uber: They bake custom logic into their bespoke control planes to rein in legacy, non-containerized workloads that refuse to submit to Kubernetes, and to shove highly specialized, company-specific L7 routing logic straight into the proxy tier.

The meta isn't just "deploy Istio and call it a day." It’s "translate your company's proprietary domain logic into xDS, the universal language, and stream it." That is the absolute frontline of the service mesh today.

6.4 The "Proxyless gRPC" Paradigm

The ultimate evolution of this is Proxyless gRPC.
Instead of deploying an Envoy (sidecar) next to your application, the gRPC library itself seamlessly acts as an xDS client.

By generating a gRPC channel using the unique xds:///my-service URI scheme, the gRPC library quietly connects to the control plane (like istiod) under the hood, pulls down EDS configs, and blasts direct HTTP/2 requests right to the optimal Pod from within your own application process.
Because you bypass the sidecar entirely, you prune network hops, slashing latency and devouring far less CPU. This is the true essence of xDS earning the title "Universal Data Plane API".

Conclusion

Behind the wizardry of an infrastructure that magically swaps over seconds after you smash kubectl apply, lies this heavily gritty, battle-tested mechanism.

The rigid hierarchy of LDS/RDS/CDS/EDS enforcing dependencies.
The indestructible ACK/NACK flow shielding the system from crippled configurations.
The sequencing and stream multiplexing of ADS preventing nasty 503 hiccups.
And the adoption of Delta xDS breaking the chains of scalability limits.

It is precisely because these gears mesh in such miraculous balance that we get to casually enjoy things like "zero downtime traffic shifting" and "canary releases."
xDS is no longer just Envoy's internal protocol. It is the absolute, most vital "nervous system" anchoring modern, cloud-native network architecture.

References

Why Can We Use "Shorter" Keys?: Key Length vs Security Bits, the Real Story

kt — Sun, 19 Apr 2026 15:50:50 +0000

"ECDSA P-256 has shorter keys than RSA-2048. So it must be weaker."

...I used to think that too.

2048 bits vs 256 bits. Just looking at the numbers, RSA seems 8x "stronger." But NIST (the National Institute of Standards and Technology) treats these two as equal in security strength.

On top of that, RSA-2048's actual security does not even reach "128-bit security." It sits at 112 bits, and it is getting deprecated in 2030. Meanwhile, P-256 properly achieves 128-bit security.

So the shorter key is actually stronger. The concept behind this counterintuitive fact is called "security bits."

This article covers why "key length" and "actual security" do not match up, from the mathematical foundations all the way to the 2026 transition timeline.

1. Background: Symmetric vs Public Key Cryptography

There are two fundamental types of cryptography. Without understanding this distinction, key length discussions will never make sense.

Symmetric Key Cryptography: Uses the same key for both encryption and decryption. The canonical example is AES (Advanced Encryption Standard). Both sender and receiver need to share the same key. It is fast, and it is what actually encrypts your data. WiFi (WPA2/3) and disk encryption (BitLocker, FileVault) all use this.

Public Key Cryptography: Uses a pair of different keys for encryption and decryption. The main examples are RSA and ECC (Elliptic Curve Cryptography). You can hand out the public key to anyone, but only the corresponding private key can decrypt. Key distribution is easy, so it is used for TLS (HTTPS) key exchange and digital signatures. The downside is that it is computationally expensive.

In practice, HTTPS combines both. Public key crypto handles "securely exchanging a key," then symmetric crypto handles "encrypting data fast."

Now here is the thing. These two types of cryptography require completely different key lengths.

2. "Key Length" and "Security Bits" Are Different Things

Let me clarify the terminology.

Key Length: The number of bits in the key data that the algorithm uses. RSA-2048 uses 2048 bits, AES-128 uses 128 bits.
Security Bits (Security Strength): The computational effort required to break the cipher, expressed as a power of 2.

"128-bit security" means that even the best known attack requires roughly $2^{128}$ operations. $2^{128}$ is about 3.4 x $10^{38}$. Even if you threw every supercomputer on Earth at it, you could repeat the entire age of the universe (about 13.8 billion years) trillions of times over and still not finish. It is basically the threshold for "cannot be broken in practice."

Here is the biggest source of confusion: key length ≠ security bits.

AES-128 has 128-bit security. Key length and security bits happen to match.
But RSA-2048 only has 112-bit security. Despite having a 2048-bit key, its effective strength is only 112 bits.

Why does this happen?

3. Each Cipher Has Different Attack "Shortcuts"

Breaking a cipher is not just about trying every possible key (brute force). Some algorithms have much more efficient attack methods. The existence and efficiency of these "shortcuts" determine the key length each algorithm needs.

AES: No shortcuts, so key length = security bits

The best known attack against AES is essentially brute force. For AES-128, you need to try all $2^{128}$ possible keys. That is why key length directly equals security bits.

RSA: Integer factorization is a powerful shortcut

RSA's security relies on the assumption that "factoring a huge number $N$ is hard."

$N$ is the product of two large primes $p$ and $q$ ($N = p \times q$). If you can find $p$ and $q$, you can compute the private key, but if $N$ is large enough, factoring should take an impractical amount of time... or so the idea goes.

The problem is that there exists an efficient algorithm for integer factorization called the General Number Field Sieve (GNFS). Thanks to GNFS, the effort to break RSA-2048 drops from $2^{2048}$ (brute force) down to roughly $2^{112}$.

Think of it this way. If you tried every combination on a 2048-digit safe one by one, it would take an astronomical amount of time. But GNFS is like "analyzing the safe's internal structure to dramatically narrow down the combinations." The key is 2048 bits, but the effective defense is only 112 bits.

ECC: Has shortcuts, but they are far less efficient than RSA's

ECC (Elliptic Curve Cryptography) relies on the "Elliptic Curve Discrete Logarithm Problem (ECDLP)."

I will skip the detailed math, but the key point is this: the best attack against ECC (Pollard's rho) requires computation proportional to half the key length. For P-256 (256-bit key), that means $2^{128}$ operations, which gives you 128-bit security.

Digging a bit deeper, this difference comes from a gap in computational complexity. GNFS runs in sub-exponential time, meaning that even as you make keys longer, the attack cost grows sluggishly. Pollard's rho against ECC, on the other hand, runs in exponential time, specifically $O(\sqrt{N})$. Each extra bit in the key doubles the attack cost.

In concrete numbers: RSA-2048 goes from 2048 bits to 112-bit security (roughly 1/18), RSA-3072 goes from 3072 bits to 128 bits (roughly 1/24), and RSA-15360 goes from 15360 bits to 256 bits (roughly 1/60). The longer the key, the worse the "decay ratio" gets. This is a direct consequence of GNFS being sub-exponential: the growth in attack cost cannot keep up with the cost of making keys longer. ECC stays at 1/2 regardless. This mathematical gap is what makes "ECC is secure with short keys" possible.

RSA has the longer key but the lower security bits. That is how big the difference in attack efficiency is.

4. Equivalent Security Key Lengths (NIST SP 800-57)

So how do these differences in attack efficiency translate to actual key lengths? NIST SP 800-57 Part 1 defines a security strength equivalence table, and it is the industry standard as of 2026.

Security Bits	Symmetric (AES)	RSA (Key)	ECC (Key)	Hash (SHA)	Status
80	-	1024	160	SHA-1	❌ Prohibited
112	-	2048	224	SHA-224	⚠️ Deprecated by 2030
128	AES-128	3072	256	SHA-256	✅ Current minimum
192	AES-192	7680	384	SHA-384	✅ Recommended
256	AES-256	15360	512+	SHA-512	✅ Long-term protection

Read this table horizontally. Every entry in the same row provides the same security.

Look at the 128-bit security row: AES needs 128 bits, ECC needs 256 bits, and RSA needs 3072 bits. RSA requires 12x the key length of ECC and 24x that of AES for the same security level. At 192-bit security, RSA-7680 is needed, and that causes serious performance issues in TLS handshakes.

The most important row right now is 112 bits. That is where RSA-2048 lives. It does not meet the current minimum recommendation of 128-bit security.

5. RSA-2048 Gets Deprecated in 2030

By now you know that RSA-2048 only provides 112-bit security. But it is not getting disabled overnight. NIST has defined a phased transition schedule.

NIST Transition Timeline

NIST IR 8547 (published November 2024) lays out the concrete timeline.

When	Status	Scope	What it means
2030	Deprecated	RSA-2048 and other ≤112-bit algorithms	No new deployments. Existing systems need a migration plan.
2035	Disallowed	RSA-3072/4096, P-256, P-384, and all quantum-vulnerable public key crypto	Completely prohibited in FIPS-compliant systems.

Take a close look at the 2035 row. RSA-3072, P-256, P-384: algorithms that are currently "recommended" will all be prohibited. This is not about security bits. It is about quantum computers breaking the algorithms at a fundamental level. The next section explains why making keys longer will not help.

The Gap Between 112 and 128 Bits Is Not "Just 16"

You might think "112 vs 128, that is only 16 apart." But in security bits, the difference is exponential.

$2^{128} \div 2^{112} = 2^{16} = 65,536$

An attacker capable of breaking 112-bit security would need 65,536 times more computation to break 128-bit security. Put another way, 112-bit security is only $\frac{1}{65536}$ as hard to break as 128-bit.

RSA-2048 is not going to be cracked tomorrow, not in 2026. But computing power improves every year. If you are encrypting data today with RSA-2048 that would be damaging if decrypted in 10 or 20 years (medical records, intellectual property, diplomatic communications), it is time to start thinking about migration.

6. Quantum Computers: Why Longer Keys Will Not Save You

In section 5, I wrote that RSA-3072 and P-384 will be prohibited by 2035. If longer keys mean more security bits, why ban them?

The answer is quantum computers. Quantum computers affect cryptography in two ways, and they are fundamentally different from each other.

Shor's Algorithm: Breaks Public Key Crypto at the Root

Shor's algorithm solves integer factorization and the discrete logarithm problem in polynomial time.

For RSA, this means the assumption that "factoring $N$ is astronomically hard" simply collapses. The discrete logarithm problem behind ECC falls the same way. No matter how long you make the key, the fundamental assumption the algorithm relies on is gone. Upgrade to RSA-4096, RSA-15360, it makes no difference against Shor.

This is why "all quantum-vulnerable public key crypto is prohibited by 2035." It is not a key length issue. You have to change the algorithm itself.

Grover's Algorithm: Halves Symmetric Crypto Security

Grover's algorithm speeds up brute-force search from $2^n$ to $\sqrt{2^n} = 2^{n/2}$.

Symmetric Cipher	Classical Security	Quantum Security	Verdict
AES-128	128 bit	→ 64 bit	❌ Not enough
AES-192	192 bit	→ 96 bit	⚠️ Marginal
AES-256	256 bit	→ 128 bit	✅ Sufficient

One caveat, though. These numbers assume Grover's algorithm running under ideal conditions. Actually attacking AES-128 with Grover would require tens of millions of logical qubits, which is orders of magnitude beyond current quantum computers (which have a few thousand physical qubits at best). Still, for long-term security, moving to AES-256 is the safe bet.

The crucial difference from Shor is that Grover can be countered by using longer keys. AES-256 maintains 128-bit security even against quantum computers. No need to change the algorithm. Just use longer keys.

This is why NIST is saying "use AES-256, use SHA-384 or above."

7. Harvest Now, Decrypt Later: Today's Data, Broken Tomorrow

"Practical quantum computers are still years away, right?"

That is the most dangerous assumption. There is an attack model called Harvest Now, Decrypt Later (HNDL).

Attackers intercept encrypted data now and store it, then decrypt it once quantum computers become viable. The NSA and CISA have warned that nation-state actors are already in this "collection phase."

The critical question is: how long does your data need to stay confidential? If a medical record encrypted today gets decrypted 20 years from now, that is a real data breach. Before quantum computers arrive, long-lived sensitive data needs to be re-protected with quantum-resistant methods.

8. Post-Quantum Cryptography (PQC) Key Sizes

So what cryptography can actually withstand quantum computers? In August 2024, NIST officially published three post-quantum cryptography standards.

ML-KEM (FIPS 203): Key Encapsulation

Formerly known as CRYSTALS-Kyber. Replaces RSA key exchange and ECDH.

Parameter	Security	Public Key	Ciphertext
ML-KEM-512	AES-128 equiv.	800 bytes	768 bytes
ML-KEM-768	AES-192 equiv.	1,184 bytes	1,088 bytes
ML-KEM-1024	AES-256 equiv.	1,568 bytes	1,568 bytes

ML-DSA (FIPS 204): Digital Signatures

Formerly known as CRYSTALS-Dilithium. Replaces RSA signatures and ECDSA.

Parameter	Security	Public Key	Signature
ML-DSA-44	AES-128 equiv.	1,312 bytes	2,420 bytes
ML-DSA-65	AES-192 equiv.	1,952 bytes	3,309 bytes
ML-DSA-87	AES-256 equiv.	2,592 bytes	4,627 bytes

SLH-DSA (FIPS 205): Hash-Based Signatures

Formerly known as SPHINCS+. Positioned as a backup for ML-DSA. It relies on a different mathematical foundation (hash functions) than the lattice-based ML-DSA, so it serves as insurance in case a vulnerability is found in ML-DSA.

Comparing Legacy Crypto and PQC Key Sizes

This is where PQC hurts. Quantum resistance comes at the cost of larger keys and signatures.

	ECDSA P-256	RSA-3072	ML-DSA-65
Public Key	64 bytes	384 bytes	1,952 bytes
Signature	64 bytes	384 bytes	3,309 bytes
Security	128 bit	128 bit	192 bit (quantum-resistant)

ML-DSA-65's public key is roughly 30x that of ECDSA P-256. This directly impacts TLS handshake sizes and certificate chains. That is why hybrid approaches (combining legacy crypto + PQC) are currently recommended. The transition will be gradual, not a full switchover all at once.

9. What to Do in 2026

Theory is great. But what should you actually do?

Start with a Crypto Inventory

Figuring out what your systems are currently using is step one.

# Check your server's TLS certificate
echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -text \
  | grep -E "Public Key Algorithm|Public-Key"

# Check your SSH keys
for key in ~/.ssh/id_*; do
  ssh-keygen -l -f "$key" 2>/dev/null
done

What to check:

Are your TLS certificates using ECDSA (P-256 or above)? If they are still RSA-2048, start planning the migration.
Are your SSH keys Ed25519? If they are still RSA-2048, regenerate them with ssh-keygen -t ed25519.
Are your JWT signatures using ES256 / EdDSA? If RS256, consider switching.
Are you using AES-256 for symmetric encryption? Migrate long-lived data from AES-128.

Build Crypto Agility into Your Architecture

No cryptographic algorithm lasts forever. RSA and ECC both have expiration dates.

The important thing is to not hardcode algorithms. Make them configurable via config files or environment variables so that when NIST publishes new recommendations, you can switch with a config change. If you have to rewrite code and redeploy to every environment, you are looking at months of work.

Combined with shorter certificate lifetimes (SC-081v3 brings the max down to 47 days by 2029), you can automatically switch algorithms at the next renewal cycle. If you are already auto-renewing certificates with ACME, the PQC transition is a natural extension of that.

Takeaways

Key length and security bits are different things. AES-128 has 128-bit security, but RSA-2048 only has 112. The efficiency of the best known attack against each algorithm determines how many key bits it actually needs.
Why ECC gets away with short keys. GNFS against RSA runs in sub-exponential time, and the security decay ratio gets worse with longer keys (roughly 1/18 for RSA-2048, roughly 1/60 for RSA-15360). Pollard's rho against ECC stays at 1/2 regardless, so short keys provide equal or better security.
RSA-2048 gets deprecated in 2030. Per NIST IR 8547. By 2035, all quantum-vulnerable public key crypto, including RSA-3072, P-256, and P-384, will be prohibited.
Quantum computers are not a key length problem. Shor's algorithm destroys RSA and ECC at the algorithmic level. Longer keys do not help. Migration to post-quantum crypto (ML-KEM, ML-DSA) is required.
Grover's algorithm can be handled with longer keys. It halves AES security, but AES-256 still maintains 128-bit security.
Run a crypto inventory now. Know what your systems are using and build in crypto agility.

References

Why I Built awesome-authorization: Mapping the World of Auth Engines onto a Single Page

kt — Sat, 18 Apr 2026 15:16:48 +0000

Introduction

"Which authorization engine should I use?"

Very few people can answer this instantly. OPA, Cedar, OpenFGA, SpiceDB, Casbin, Cerbos... That’s six just off the top of my head. They are based on entirely different access control models (RBAC, ABAC, ReBAC), with different design philosophies and use cases.

I've always been an auth nerd. I wrote an AuthZEN-compatible plugin for OPA, read through the SPIFFE/SPIRE implementations, and deep-dived into the Google Zanzibar paper. Through all of this, I realized something: There is no single place to get a bird's-eye view of the entire authorization landscape.

A repository called awesome-authorization already existed. However, it was mostly a collection of articles and concepts—it didn't answer the practical question of "What engines actually exist and how do they differ?". With AuthZEN 1.0 officially approved, the authorization space is moving fast, but the information is too scattered to track.

So, I built one.

awesome-authorization : A curated list of tools, frameworks, standards, and learning resources for authorization and access control.

In this post, I want to explain why this list needed to exist and map out the state of authorization engines in 2026.

1. Setting the Stage: PEP vs. PDP

Before looking at the engines themselves, let's clarify where authorization sits within the architecture and what exactly an authorization engine—or Policy Decision Point (PDP)—does.

Authentication (Who are you?) → Token Issuance → Authorization (What can you do?) → Resource Access. In this flow, the authorization engine (PDP) and the AuthZEN API are strictly responsible for step 4: "Query AuthZ Decision."

OAuth 2.0 and AuthZEN operate on different layers. OAuth is about passing tokens between a client and a resource server. AuthZEN is about the application asking a policy engine for a decision. I see articles conflating these two all the time, but they are entirely different beasts.

2. The Cambrian Explosion of Authorization Engines

Let’s look at reality. As of April 2026, here is what the major authorization engine landscape looks like.

That's a lot. And while they might look similar from the outside, their foundational design philosophies are radically different.

3. You Can't Choose If You Don't Know the Models

The very first thing to understand when picking an authorization engine is the underlying access control model. If you skip this, you will inevitably hit a wall where the engine simply cannot express your use case.

RBAC: Managing by Roles

The simplest approach. Assign roles to users, and bind permissions to those roles.

Kubernetes RBAC is a perfect example. It's simple, but as conditions grow, you suffer from Role Explosion. Try expressing "Only full-time engineers in the Tokyo office assigned to Project A can access the production environment" in strict RBAC. The number of role permutations becomes unmanageable.

ABAC: Deciding by Attributes

Decisions are evaluated based on the attributes of the user, the resource, and the environment.

This is where OPA (Rego) and Cedar shine. It’s highly flexible, but the policies themselves can get complicated very quickly.

ReBAC: Deciding by Relationships

Coined by the Google Zanzibar paper. It manages relationships as a graph—for example, "alice is a viewer of doc:readme," or "all members of the eng group are viewers."

SpiceDB, OpenFGA, and Permify implement this model. It operates identically to how sharing works in Google Drive, making it the most natural fit for collaborative apps. However, it struggles with attribute-based conditions like "allow access only during business hours."

So, Which One Should You Use?

Roughly speaking:

What you want to do	Model	Candidates
Simple role management	RBAC	Casbin, Spring Security, Kubernetes RBAC
Complex branching logic (Attributes)	ABAC	OPA, Cedar, Cerbos
Google Drive-style sharing / Hierarchies	ReBAC	SpiceDB, OpenFGA, Permify
Kubernetes policy control	ABAC/RBAC	OPA Gatekeeper, Kyverno

In reality, you often end up with a hybrid of RBAC + ABAC or a combination of ReBAC + ABAC. Cedar natively supports both RBAC and ABAC, while Aserto's Topaz combines Zanzibar-style ReBAC with an OPA engine for ABAC.

4. AuthZEN: Standardizing the AuthZ API

All the authorization engines we’ve looked at share a glaring problem: Their APIs are completely fragmented.

OPA wants {"input": {...}} sent via POST /v1/data/.... Cedar uses a different API entirely. SpiceDB expects a gRPC CheckPermission call. They are all different.

This means if you ever decide to swap engines, you have to rewrite all of your application code. We successfully separated PDP (decision) from PEP (enforcement), but we never standardized the protocol between them.

In January 2026, the OpenID Foundation officially approved the AuthZEN Authorization API 1.0 as a Final Specification. It standardizes the communication between the PEP and PDP, allowing you to use the exact same JSON API regardless of which underlying engine is running.

// Request: Can this subject perform this action on this resource?
POST /access/v1/evaluation
{
  "subject": { "type": "user", "id": "alice" },
  "action": { "name": "read" },
  "resource": { "type": "document", "id": "doc-123" }
}

// Response
{
  "decision": true
}

Why does this matter? It decouples your engine choice from your application code. Starting with OPA and later swapping it out for Cedar as your use case evolves is suddenly a realistic option.

Making OPA AuthZEN-Compatible

I built a plugin that makes OPA natively speak AuthZEN.

opa-authzen-plugin

OPA is a generic policy engine with its own REST API. Its paths, request structures, and response structures are entirely different from AuthZEN's. There was an authzen-proxy built in Node.js sitting in the contrib repo, but running a separate proxy process alongside OPA felt less than ideal for production.

So, I used OPA’s plugin architecture to run an AuthZEN server directly inside the OPA process itself. It’s the exact same pattern used by the opa-envoy-plugin.

Engines like Cerbos and Topaz have already started natively supporting AuthZEN. As more engines adopt it, the switching costs between them will continue to drop.

5. Why the Existing awesome-authorization Failed

warrant-dev/awesome-authorization has around 420 stars and decent visibility. But looking closely at the content, there are obvious gaps.

It focuses heavily on articles and concepts, lacking actual tools. OPA gets exactly one line. Major engines like Cedar, OpenFGA, SpiceDB, Casbin, and Cerbos are entirely absent.

It completely ignores modern standards. The authorization spec world doesn’t end with OAuth 2.0. We have AuthZEN, SPIFFE, UMA, and GNAP reshaping the space, but none of them are covered.

It feels like a vendor proxy. The repo puts the Warrant company banner right at the very top. It’s hard to call it a vendor-neutral community resource.

So, I decided to build a better one.

6. Curating awesome-authorization

I designed kanywst/awesome-authorization to cover the entire authorization landscape through the following sections:

The biggest differentiator from the old list is the Policy Engines section. I explicitly categorized them into General Purpose, Zanzibar-based, Kubernetes Native, and AuthZEN-compatible. I wanted to create a place where anyone looking for an auth engine could instantly understand the entire current market.

The Standards section is just as comprehensive, covering AuthZEN, OAuth/OIDC, SPIFFE/SPIRE, XACML, and GNAP. You can't grasp the "big picture" of authorization by just looking at tools—you need to understand the underlying specifications driving them.

Conclusion

There are too many authorization engines, and no place to make sense of them all. So I fixed that.

kanywst/awesome-authorization

Whether you are trying to select a policy engine, research a standard specification, or find that one specific engineering blog post you read months ago, treat this repository as your starting point.

PRs are absolutely welcome. If a good tool or article is missing, please add it.

AuthZEN Authorization API 1.0 Deep Dive : Deep Dive into the AuthZEN Spec
I Built an OPA Plugin That Turns It Into an AuthZEN-Compatible PDP : Design and Implementation of opa-authzen-plugin
Google Zanzibar Deep Dive : Explaining the Zanzibar Paper
RBAC vs ABAC vs ReBAC : Comparing Access Control Models

RFC 7523 Deep Dive: JWT Profile

kt — Mon, 13 Apr 2026 11:20:54 +0000

Introduction

I perfectly understand how human users authenticate in modern web apps via OAuth 2.0. A browser opens, the user clicks "Allow" on a consent screen, and an access token is issued.

But the other day, while looking at a backend architecture involving dozens of microservices, a fundamental question hit me: "How does machine-to-machine (M2M) authentication actually work when there is no human sitting in front of a browser?"

For a long time, the answer was passing around a client_secret—essentially a static password. However, in 2026, hardcoding access keys in CI/CD pipelines like GitHub Actions or configuration files is considered a risky, legacy practice. In its place, mechanisms that dynamically generate temporary credentials—most notably Workload Identity Federation—have become the standard.

Do you know the protocol specification that underpins this "secretless" M2M authentication infrastructure? That would be RFC 7523 (JSON Web Token (JWT) Profile for OAuth 2.0).

In this article, I will dissect RFC 7523 to deeply explore why we are finally being liberated from the technical debt of client_secret.

1. The Relationship Between RFC 7521 and 7523: The Box and Its Contents

To understand RFC 7523, we must first look at its parent, RFC 7521.

RFC 7521 defines a "framework" stating that, "In OAuth 2.0, you may use an assertion (verifiable data containing a claim) for client authentication or authorization grants." However, this specification does not dictate the actual data structure of the assertion.

So, the rulebook that materialized this by saying, "Well, let's use the easily handled JWT (JSON Web Token) as the data format for that assertion," is RFC 7523.

Role	Corresponding RFC	Summary
Abstract Framework	RFC 7521	Common rules for using assertions (The Box).
JWT Profile	RFC 7523	The star of this article. Specific implementation rules using JWT (The Contents).
SAML Profile	RFC 7522	For SAML XML, often seen in enterprise legacy systems.

2. The "Two Powerful Use Cases" Brought by JWT

To integrate JWT into the OAuth 2.0 paradigm, RFC 7523 clearly defines two independent use cases. Mixing these up will invariably lead to pitfalls during implementation, so pay close attention.

JWT as an Authorization Grant
JWT as Client Authentication

These are completely different concepts. They can be used separately or both at the same time. Let's look at the raw mechanics of each.

Use Case 1: Using JWT as an "Authorization Grant" (The Secret of M2M Communication)

Imagine a log aggregation worker for a batch process running late at night. There is no human sitting in front of a browser to click the "Allow Access" button.

The standard Authorization Code Grant relies on human interaction. However, by using the JWT grant defined in RFC 7523, the client (such as a batch server) can cryptographically sign a JWT itself using its private key, hurl it directly at the authorization server, and pillage an access token.

Flow Diagram

It is an incredibly simple, almost violently streamlined flow with all the fat trimmed off.

At this point, the HTTP request looks like the following. The most striking detail is that there is absolutely no client_secret included in the request (assuming the authorization server's policy allows this). The signed JWT itself serves as a rock-solid proof of "who I am and what I am asking for."

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=eyJhbGciOiJSUzI1NiIsImtp...[Signed_JWT]...

Use Case 2: Using JWT for "Client Authentication" (Goodbye, client_secret)

The other use case is substituting the infamous client_secret with a JWT as proof of identity in a standard flow (e.g., when exchanging an authorization code for an access token). If you've ever implemented backend communication for "Sign in with Apple," you've undoubtedly gone through this exact flow.

In this case, the JWT is bundled into the client_assertion parameter. Because you no longer need to save static passwords in network routing paths or GitHub environment variables, the security risk dramatically plummets.

3. The Validation "Claims" You Must Never Compromise On

"If throwing a JWT gets you a token, how do we block an attacker who just makes up a random JWT?"

Section 3 of RFC 7523 lays out absolutely merciless, strict validation rules for the claims that must be included in the JWT payload. The authorization server MUST reject immediately any JWT that breaks even a single one of these rules.

Claim	Required	The Truth of Implementation & Attack Vectors
`iss` (Issuer)	Required	"Who issued this?" For client authentication, this is your own `client_id`. The comparison is done via Simple String Comparison based on RFC 3986.
`sub` (Subject)	Required	"Who is this claim about?" For authorization grants, this must match the entity delegating authority (e.g., user). For client authentication, it must match the `client_id`.
`aud` (Audience)	Required	"Who is this addressed to?" This must contain the token endpoint URL of the authorization server. Forgetting to validate this leads to a fatal vulnerability where a legitimate JWT issued for a different service is intercepted and diverted to yours.
`exp` (Expiration)	Required	"The expiration date." If it's in the past, reject it. In realistic cloud deployments, setting an extremely short window of 5–15 minutes is standard practice to minimize risk if intercepted.

Furthermore, the following properties are critical for security:

jti (JWT ID): A unique identifier for the JWT. By caching this alongside the exp claim, the authorization server can memorize used jtis and refuse to accept them again, perfectly preventing replay attacks. While technically MAY (optional) by spec, it is virtually mandatory in production.
Cryptographic Algorithm: RFC 7523 Section 5 explicitly states that RS256 (RSA signature) is Mandatory-to-Implement. Lazy implementations that try to get away with none or HS256 (which requires sharing a secret key) are strictly forbidden under this specification.

Conclusion

RFC 7523 is not just "one of the ways to use JWT." It represents the final end to the endless, agonizing game of "where do we hide the static passwords?" that we've suffered through for years.

Accidentally pushing a Google Cloud service account key (JSON) to GitHub, only to have a Bitcoin mining cluster spun up seconds later leading to thousands of dollars in damages—such tragedies could be completely prevented with RFC 7523 and the Workload Identity architectural patterns built on top of it.

The era of manually pasting client_secret into source code and CI/CD environment variables is over. If your system is still executing legacy password-based authentication, you should immediately consider transitioning to a modern architecture utilizing public-key cryptography and JWT grants.

Resources

RFC 7636 Deep Dive: How PKCE Kills Authorization Code Interception Attacks

kt — Sun, 12 Apr 2026 05:31:58 +0000

Introduction

Last time, we tore apart the core mechanics of RFC 6749 (Authorization Code Grant).

RFC 6749 Deep Dive: Understanding OAuth 2.0 Design Decisions from the Specification

Hopefully, those fundamentals clicked. But here’s the thing: the second you try writing your own OAuth client or start poking around IdP dashboards, you almost inevitably smash into this weird, lingering mystery.

"So... what exactly does this 'PKCE' thing protect against? Isn't the state parameter enough?"

You'll see that "Require PKCE" toggle sitting right there in the console. An alarming number of developers blindly flip it to "ON" just because it sounds like a sensible security upgrade.
But if you can't instantly explain why you MUST use S256, or how exactly your access tokens would get hijacked without PKCE, then congrats. You're essentially just praying to a magic internet spell.

The true identity of this "feature everyone checks but nobody actually understands" is a clever cryptographic trick purposely built to shield authorization codes from the completely unhinged routing behavior of mobile OSes. It perfectly kills interception attacks. It is RFC 7636.

Consider this article the sequel to our RFC 6749 deep dive.
We’re going to rip through the original RFC 7636 spec, uncover the beautifully simple cryptography behind PKCE, and expose the "don't ever do this" configurations that could ruin your app.

Scoping It Out

Where exactly does RFC 7636 fit in the sprawling OAuth 2.0 universe?

While RFC 6749 tells you "how to get a token," RFC 7636 tells you "how to stop people from stealing it while you're trying to get it." We'll assume you already know how the standard Authorization Code Grant works.

1. The Problem: Auth Code Interception Attacks

1.1 The Gap Between Server-Side Strictness and Mobile OS Chaos

If you've spent your career in backend web dev, you probably think, "As long as the IdP strictly validates the redirect_uri, we're bulletproof." And for server-side apps redirecting to a dedicated, TLS-secured https://myapp.example.com/callback, you'd be right.

But the minute you step into native mobile apps (iOS / Android), everything falls apart. To receive the callback (the auth code) from the browser, native apps rely on custom URI schemes like this:

myapp://oauth/callback?code=AUTH_CODE

There’s a fatal, gaping vulnerability here. The moment the auth server tells the browser to redirect to myapp://, it completely surrenders control over which app on that phone actually catches the URL. The ball gets thrown out of your safe, locked-down server environment and straight into the lawless wasteland of the mobile OS.

And guess what? Android and iOS do not guarantee custom URI schemes are unique.
A malicious app doesn’t have to pull off an Ocean's Eleven heist on your auth server. It just sits there. When it gets installed, it casually tells the OS (via a few lines of text in Info.plist or AndroidManifest.xml): "Hey, I can open myapp:// too."

When the browser fires that redirect with your precious authorization code, the OS can't tell which app is the "real" one. The routing decision is a complete coin toss. If the OS capriciously hands it to the malicious app, your auth code is gone.

1.2 The Attack Sequence

RFC 7636 §1 sketches this out vividly.

You might think, "Does this actually happen in the wild, or is it just academic paranoia?" RFC 7636 §1 delivers a cold reality check:

While this is a long list of pre-conditions, the described attack has been observed in the wild.

1.3 Why Not Just Use Existing Defenses?

I know what you're thinking: "Why not just authenticate with a client_secret?"
Because Public Clients (like mobile apps and SPAs) cannot keep a secret. If you ship a hardcoded secret in a mobile binary, it will be extracted before you finish your morning coffee.

Since the attacker and the real app both show up at the Token Endpoint holding the exact same credentials (code + client_id), the auth server is blind. It has absolutely no way to tell the good guys from the bad guys.

2. The Core Concept of PKCE

The fix for this mess is so simple it almost feels anticlimactic.

The app starting the authorization request generates a "one-time, highly random secret string," hashes it, and sends the hash with the request.
The auth server issues the code, tying it to that stored hash.
When exchanging the code for a token, the app must prove it's the real deal by presenting the original, unhashed secret string.

The attacker doesn't know the original string. It only lives in the RAM of the legitimate app. You can steal the code, but without the secret string, the auth server will slam the door in your face. That is PKCE.

3. PKCE Protocol Details

We can step right through the actual protocol (RFC 7636 §4) to see how this works.

3.1 Generating the code_verifier (§4.1)

The code_verifier is a cryptographically secure random string that the client generates freshly for every single request.

Length: 43 to 128 characters
Characters allowed: [A-Z], [a-z], [0-9], -, ., _, ~
Entropy: Recommended 256 bits

import secrets
import base64

# Generate 32 bytes (256 bits) of pure randomness
random_bytes = secrets.token_bytes(32)

# base64url encode (remove padding)
code_verifier = base64.urlsafe_b64encode(random_bytes).rstrip(b'=').decode('ascii')

print(code_verifier)
# Example output: dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

⚠️ Never use predictable pseudo-random number generators like Math.random(). Just don't.

3.2 Calculating the code_challenge (§4.2)

Next up, we derive the code_challenge from that code_verifier. The industry standard is S256.

code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

The spec says you MAY use plain (i.e., no hashing) if some technical constraint absolutely prevents S256. To put it bluntly: In the modern era, there is zero excuse to use plain. Ever.

3.3 Hands-On: Auth & Token Requests

Staring at Mermaid diagrams gets boring fast. Let’s simulate the raw PKCE flow using your terminal and curl.

① Authorization Request (via browser)
The client includes code_challenge and code_challenge_method as parameters and redirects the user.

# The URL actually hit in the browser's address bar
curl -i "https://auth.example.com/authorize?\
response_type=code&\
client_id=my-native-app&\
redirect_uri=myapp://callback&\
state=xyz123&\
code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&\
code_challenge_method=S256"

Behind the scenes, the server ties E9Melhoa... to the issued code, stores it, and returns a redirect back to the app.

② Token Request
The app, having caught the incoming authorization code, sends the code_verifier (which it kept safely tucked away in its own memory) straight to the Token Endpoint.

curl -X POST "https://auth.example.com/token" \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "grant_type=authorization_code" \
     -d "client_id=my-native-app" \
     -d "redirect_uri=myapp://callback" \
     -d "code=AUTH_CODE_RECEIVED" \
     -d "code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"

The server hashes the received code_verifier with SHA-256 and checks if it matches the stored code_challenge. If they match, congratulations—you get the access token.
If an attacker intercepted the code and sends it here, their code_verifier will be empty or garbage, and the server will mercilessly kick them out with an invalid_grant.

4. The Fatal Flaw of the "plain" Method

Why am I relentlessly telling you to avoid plain?
Because plain literally means code_challenge = code_verifier. You are passing your secret completely unhashed.

If the smartphone's HTTP history leaks, or if the auth request gets intercepted over a compromised TLS proxy, the attacker instantly sees your code_challenge. If you're using plain, they just got your code_verifier for free. Once they snatch the auth code, they have all the pieces, and your entire PKCE defensive wall collapses.

With S256, even if they intercept every single auth request and steal the code_challenge, trying to reverse-engineer the original code_verifier out of that SHA-256 hash requires a pre-image attack. Good luck with that. They'll be crunching hashes until the sun burns out.

Using plain is essentially opting out of security while pretending you didn't.

5. PKCE vs. The 'state' Parameter

"Wait, doesn't the state parameter prevent CSRF? Why do I need both?"
Simply put: They block attacks coming from totally opposite directions.

Feature	`state` (RFC 6749)	PKCE (RFC 7636)
What it stops	CSRF (Auth code injection)	Auth code interception
Attack direction	Attacker → Victim (Forces the attacker's code into your session)	Victim → Attacker (Steals your code for the attacker's session)
Where it's verified	Client-side (Your app checks the callback)	Server-side (Token Endpoint validates the verifier)

state ensures nobody shoves a sketchy auth code into your app. PKCE ensures nobody takes your auth code and uses it elsewhere. They aren't mutually exclusive. You absolutely must use both.

6. Security Design Details

Why Doesn't S256 Use a Salt? (§7.3)

If you know anything about passwords, you know you need a salt. So why doesn't PKCE use one for its hashes?
Because the base entropy is already at lethal levels.

Passwords need salts because human-readable passwords have pathetically low entropy, leaving them wide open to pre-computation (rainbow table) attacks. A code_verifier, however, is 256 bits of pure cryptographic randomness. Brute-forcing it is physically impossible in our universe. Adding a salt achieves absolutely nothing except making your code messier.

Surviving Downgrade Attacks (§7.2)

RFC 7636 has a strict rule:

Clients MUST NOT downgrade to "plain" after trying the "S256" method.

If you send S256 and the auth server throws an error, do not try to be helpful and resend the request using plain. That’s exactly how a Man-In-The-Middle attacker strips away your security (a downgrade attack). If S256 fails, the flow is compromised. Kill it immediately.

Conclusion

RFC 7636 is a breezy 20-page specification, but it fundamentally fixed one of the scariest vulnerabilities in the OAuth 2.0 ecosystem: delivering the authorization code.

To sum it up:

Custom URI schemes on native apps are a free-for-all. Anyone can register them.
PKCE locks down the code using a mathematical secret only the request initiator knows.
Use S256. Anyone telling you to use plain is reckless.

PKCE was initially pitched as an "optional extension for Public Clients." Today, under the current OAuth 2.0 Security Best Current Practice (BCP), it is strictly mandatory for everyone, even Confidential Clients sitting on secure backend servers.

Skipping PKCE in a modern system isn't an "option." It's just plain wrong.

References

Why Do SSL/TLS Certificate Lifetimes Keep Getting Shorter?: Everything You Need to Know for the 47-Day Era

kt — Sat, 11 Apr 2026 05:16:18 +0000

Introduction

The other day, I was casually scrolling through my server's certificate renewal logs when something caught my eye.

"...Wait, this renewed again? Didn't it just do that?"

Let's Encrypt certificate renewals hit every 90 days. Since I've automated the process, I don't usually think about it—but looking at the logs, certbot was running practically every month. And then it hit me. Just a few years ago, certificate lifetimes were 1 year. Go further back, and they were 3 years. Why did they get so short?

Down the rabbit hole I went, and the story was far deeper than I expected.

In April 2025, the CA/Browser Forum unanimously passed Ballot SC-081v3. Here's what it says:

By March 2029, the maximum validity period for SSL/TLS certificates will be reduced to 47 days.

47 days. For anyone who remembers buying "3-year certificates," this sounds absurd. But behind this decision lies a fatal problem that Web PKI has carried for years: certificate revocation is structurally broken.

The first half of this article explains why certificates need to be shorter. The second half covers what that means for us as engineers.

1. What Even Is a "Certificate Validity Period"?

Before we can talk about shortening lifetimes, we need to understand what the validity period actually does.

An SSL/TLS certificate has two fields: Not Before (start date) and Not After (end date). You can check them with openssl:

echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
# notBefore=Jan 30 00:00:00 2025 GMT
# notAfter=Mar 1 23:59:59 2026 GMT

The span between notBefore and notAfter is the "validity period." Browsers categorically refuse to trust certificates outside this window.

So why does a validity period exist in the first place?

Certificate trust depends on the private key. Because the server holds the private key, it can prove it's the legitimate owner of that certificate. But what if the private key leaks? An attacker can impersonate the legitimate server using that certificate.

The validity period is the last line of defense against private key compromise. Even if nobody notices the leak, the certificate automatically becomes worthless once it expires.

In other words: validity period = the maximum window an attacker can exploit a compromised key. The shorter it is, the smaller the blast radius.

2. The History of Validity Periods: 10 Years → 47 Days

Certificate maximum validity has been shrinking consistently since the 2000s. Understanding this history makes it clear that the current trend isn't a sudden policy shift—it's the continuation of a 20-year trajectory.

Period	Max Validity	Trigger
~2011	8–10 years	Early SSL era. Long-lived certificates were the norm
2012	5 years (60m)	CA/Browser Forum establishes Baseline Requirements
2015	3 years (39m)	Baseline Requirements amendment
Mar 2018	2 years (825d)	Ballot 193
Sep 2020	1 year (398d)	Apple unilaterally enforced in Safari. Google and Mozilla followed
Mar 2026	200 days	SC-081v3 Phase 1 (※ we are here now)
Mar 2027	100 days	SC-081v3 Phase 2
Mar 2029	47 days	SC-081v3 Phase 3 (final target)

The 2020 event deserves extra context. A vote within the CA/Browser Forum failed to reach consensus, yet Apple unilaterally announced that Safari would refuse to trust any certificate with a validity exceeding 398 days. Google and Mozilla followed suit, making it a de facto industry standard.

This revealed the power dynamics of Web PKI in stark terms. No matter how many long-lived certificates a CA issues, if the browsers say "we don't trust it," that's the end of the discussion. A certificate that Safari, Chrome, and Firefox reject is effectively useless on the internet.

3. Revocation Is Broken — The Real Reason Behind Shorter Lifetimes

Here's the core of this article.

"If a private key leaks, can't you just revoke the certificate immediately? Why bother shortening the validity period itself?"

Fair question. But here's the thing: the "just revoke it" mechanism barely works in practice. This is the single biggest reason certificate lifetimes are being pushed shorter.

Let's walk through it.

3.1 What Is Revocation?

First, the basics.

Certificate revocation means a CA (Certificate Authority) declares that a still-valid certificate should no longer be trusted. This is used when a private key is compromised, domain ownership transfers, or a certificate was mis-issued—situations where trust needs to be withdrawn before the natural expiration date.

The problem is: how do you communicate this "declaration" to clients (browsers)? Historically, two mechanisms were built for this: CRL and OCSP.

3.2 The Problem with CRL (Certificate Revocation Lists)

CRL is the oldest revocation-checking mechanism. The CA periodically publishes a file containing serial numbers of all revoked certificates, and browsers download it to cross-check.

Sounds simple enough, but it has three fatal flaws:

The file gets enormous. When a major CA revokes a large number of certificates, the CRL can balloon to tens of megabytes. Downloading this every time a user visits an HTTPS site is wildly impractical
Update frequency is low. A CRL specifies a "Next Update" date, and the stale list is cached until then. Any certificates revoked in the interim are not reflected
If the CA's infrastructure goes down, you can't fetch it. If the CRL Distribution Point (CDP) is overloaded or experiencing an outage, revocation checking becomes flat-out impossible

3.3 The Problem with OCSP (Online Certificate Status Protocol)

If CRL is "downloading the entire phone book," OCSP is "calling to ask about one number at a time." The browser queries the CA's OCSP responder in real time for each individual certificate: "Is this certificate still valid?"

Looks better than CRL, but this is where Web PKI's most critical design flaw lives. Look at the "else" branch above.

3.4 Soft-fail: Revocation Fails Exactly When You Need It Most

What happens when the browser can't reach the OCSP responder?

Nearly every browser chooses to "trust it anyway" (soft-fail).

Why? If browsers hard-failed (refused the connection when OCSP is unreachable), a single outage on a CA's OCSP server would make every website issued by that CA inaccessible worldwide. You couldn't even reach a hotel Wi-Fi captive portal to log in. That user experience is unacceptable, so browser vendors chose soft-fail.

But soft-fail is trivially exploitable by attackers.

Consider a MITM (Man-in-the-Middle) attack scenario:

The attacker uses a leaked private key to present a revoked certificate to the victim
The victim's browser attempts to verify revocation status via OCSP
The attacker controls the network and blocks the OCSP request
The browser gets no response—soft-fail triggers, and it "trusts it anyway"
The attacker maintains the impersonation using a revoked certificate, intercepting and modifying traffic at will

Revocation checking fails precisely in the scenario where it's needed most—when you're under attack. This is a design-level contradiction. It looks like a seat belt, but it's actually a harness that's not attached to anything.

3.5 OCSP Stapling — A Partial Fix

OCSP Stapling was created to address this. Instead of the browser reaching out to the CA, the web server itself pre-fetches a CA-signed OCSP response and delivers it to the client during the TLS handshake, bundled with the certificate.

This eliminates the attacker's ability to block OCSP requests. It also sidesteps the privacy issue of browsers leaking browsing history to the CA.

Must-Staple, a certificate extension, takes this further by instructing the browser: "Reject the connection if OCSP Stapling is not present."

However, Must-Staple adoption is extremely low. If a server operator fails to fetch the OCSP response, even a legitimate site becomes inaccessible. Most sites don't take that risk.

3.6 Browser Vendors' Response: "We Gave Up on Revocation Checking"

Faced with these problems, major browsers went their own way.

Browser	Approach	Description
Chrome	CRLSets	Google curates a high-risk revocation list bundled with and pushed to the browser. Real-time OCSP was discontinued in 2012
Firefox	CRLite	A Bloom filter–based compressed revocation database distributed to the browser. Covers all certificates
Safari	OCSP-based	Routes through Apple's proprietary OCSP proxy. Privacy concerns remain

Chrome dropped real-time OCSP checks entirely in 2012. In Adam Langley's words (then Chrome's security engineer), OCSP was "a seat belt that looks like it works but isn't actually attached to anything."

3.7 So the Only Option Is to Make Them Shorter

If revocation is broken, just build a world that doesn't rely on revocation.

Make certificate lifetimes short enough that even if a private key is compromised, the certificate naturally dies within days to weeks. It doesn't matter if OCSP is broken. The certificate expires on its own.

This is the essence of short-lived certificates. It's not "shortening them because it's convenient." It's "shortening them because revocation is broken and there's no other viable path."

4. CA/Browser Forum Ballot SC-081v3: The Phased Transition to 47 Days

With the shared understanding that "revocation is broken," the CA/Browser Forum unanimously passed SC-081v3 in April 2025. Apple, Google, Mozilla, Microsoft—all major browser vendors—along with major CAs like DigiCert, Sectigo, and Let's Encrypt signed on.

4.1 Phased Transition Schedule

Effective Date	Max Certificate Validity	DCV Reuse Period
March 15, 2026	200 days	200 days
March 15, 2027	100 days	100 days
March 15, 2029	47 days	10 days

4.2 What Is DCV and Why Is It Being Shortened Too?

DCV (Domain Control Validation) is the process by which a CA verifies that the applicant actually owns or controls the domain they're requesting a certificate for. In Let's Encrypt's ACME protocol, this corresponds to HTTP-01 challenges (proving you can place a file at a specific path) or DNS-01 challenges (proving you can add a TXT record to DNS).

Currently, once DCV succeeds, the result can be reused for up to 398 days—meaning certificates can be renewed without re-validation during that window.

SC-081v3 shortens the DCV reuse period to 10 days by 2029. Why? If domain ownership changes, stale DCV results could allow a certificate to be issued for the previous owner. The shorter the DCV reuse period, the more accurately it reflects current ownership.

In practice, this means every certificate renewal will effectively require re-proving domain ownership.

4.3 Why Specifically 47 Days?

The number 47 originated from Apple's initial proposal (45 days) and was finalized after discussion within the CA/Browser Forum.

No official formula has been published, but from an operational standpoint, the number is rational:

Item	Days
Certificate validity period	47 days
Recommended renewal point (2/3 elapsed)	~Day 31
Recovery window if renewal fails	~16 days

Renew once a month, and even if it fails a couple of times, you've still got roughly two weeks of recovery cushion.

5. Let's Encrypt's Foresight: 90 Days, Then 6

Let's Encrypt has been leading this short-lived revolution ahead of the industry.

5.1 Why Let's Encrypt Started at 90 Days

When Let's Encrypt launched in 2015, the industry standard was 2–3 year certificates. They deliberately chose 90 days, and explained their reasoning in an official blog post ("Why ninety-day lifetimes for certificates?"):

Limiting the damage window from a compromise: Even if a private key leaks, the certificate automatically becomes invalid after at most 90 days
Forcing automation: 90 days is too short for comfortable manual management. This effectively made automated renewal via ACME (RFC 8555) a requirement, not an option
Reducing dependence on revocation: Exactly the problem covered in Section 3. When certificates are short-lived, broken OCSP is far less of an issue

The 90-day choice was strategic. 60 days was too close to manual renewal cycles, causing frequent mishaps. 120 days left room for the "I can still do this manually" mentality. 90 days hit the sweet spot: "painfully tight without automation, but with the recommended 60-day renewal interval, you can run it monthly."

5.2 6-Day Certificates Arrive (January 2026)

In January 2026, Let's Encrypt went even further with 6-day (160-hour) certificates, now generally available.

# Requesting a 6-day certificate with certbot
certbot certonly --preferred-profile shortlived -d example.com

Key points about 6-day certificates:

Validity period of 160 hours (~6.7 days)
Requested by specifying the shortlived certificate profile in ACME
Also supports certificate issuance for IP addresses (short-lived only)
Opt-in; coexists with standard 90-day certificates
No OCSP response embedding needed. The certificate dies naturally in 6 days, making revocation checking meaningless

6-day certificates are the current cutting edge of the "world without revocation" described in Section 3.

6. The Other Goal of Shorter Lifetimes: Preparing for Post-Quantum

The primary driver behind shorter certificate lifetimes is "revocation is broken," but there's another critical context: Crypto Agility.

Crypto agility is the ability to rapidly switch cryptographic algorithms without causing widespread disruption.

Why does this matter? Current SSL/TLS certificates are signed with RSA or ECDSA, but when practical quantum computers arrive, both RSA and ECDSA are theoretically broken (Shor's algorithm efficiently solves large integer factorization and discrete logarithm problems). When that happens, the entire web's certificates will need to migrate to NIST-standardized post-quantum algorithms (ML-KEM, ML-DSA, etc.).

What separates organizations here is their "migration muscle":

Organization State	Response During Algorithm Migration
Auto-renewing every 47 days	Apply the new algorithm on the next renewal cycle. Full migration in weeks
Manually renewing once a year	Manually inventory and replace every certificate. Months-to-years emergency work

Automating short-lived certificates isn't just about "automating a chore"—it's a structural hedge against future cryptographic crises.

7. Operational Problems Created by Shorter Lifetimes

Up to this point, I've been making the case for why shorter lifetimes are necessary. Now let's be honest about the downsides.

7.1 The End of Manual Management

With 47-day certificates, you need roughly 8 renewals per year. Humans will absolutely drop the ball at that frequency.

Validity	Renewals/Year	Manual Management
1 year (398d)	~1	Barely manageable
200 days	~2	Doable
100 days	~4	Getting painful
47 days	~8	Physically impossible

ACME (RFC 8555) automation becomes the de facto standard. The tools already exist—certbot, acme.sh, Caddy's automatic HTTPS. The problem is the environments that haven't adopted them yet.

7.2 Certificate Expiry Outages — Even Microsoft and SoftBank Got Burned

"Forgetting to renew a certificate" happens inevitably when humans are in the loop. This isn't theoretical.

Year	Incident	Cause	Impact
2017	Equifax data breach	An expired certificate on a network monitoring device caused attack traffic to go undetected for 10 months	150 million individuals' personal data exposed
2018	SoftBank nationwide outage	An expired certificate embedded in Ericsson's telecom switch software	~4-hour outage across 11 countries including Japan
2020	Microsoft Teams outage	Forgotten authentication server certificate renewal	~3 hours of worldwide inaccessibility

Even Microsoft—one of the largest tech companies on Earth—"forgot to renew a certificate." The SoftBank outage wasn't even their fault: it was an expired certificate embedded in vendor (Ericsson) switch software. When a certificate rots somewhere in the supply chain, everything downstream collapses.

With renewal frequency increasing 8x in the 47-day era, the opportunities for these incidents multiply. Any system without automation becomes a ticking time bomb.

7.3 Systems That Can't Support ACME

Not every system supports ACME.

The categories that cause the most pain:

Hardware load balancers (F5 BIG-IP, etc.): Many older models don't support ACME. Certificate installation is limited to manual upload via web UI
Firewall / VPN appliances: Entirely dependent on vendor ACME support
IoT / embedded devices: Firmware updates alone can be challenging
Legacy systems: The "pickled" systems you can neither update nor decommission

Manually uploading certificates to these devices every 47 days is, to put it mildly, torture.

7.4 DCV Reuse Period Shrinking to 10 Days

As covered in Section 4.2, but worth emphasizing: after 2029, the DCV reuse period drops to 10 days.

If you're using DNS-01 challenges, you'll be rewriting DNS TXT records on every certificate renewal. If your DNS API is unreliable or DNS propagation is slow, the renewal failure risk shoots up. In environments spanning multiple DNS providers, renewal script complexity explodes.

8. Surviving the Short-Lived Certificate Era

8.1 Full ACME Adoption

This is the bare minimum, but it's worth periodically verifying that certbot's auto-renewal is actually working.

# Check if the systemd timer is active
systemctl status certbot.timer

# Rehearse to see if renewal actually succeeds
certbot renew --dry-run

8.2 At Scale: Introducing CLM

Once you're managing dozens to hundreds of servers, certbot alone isn't enough. You need a CLM (Certificate Lifecycle Management) platform to centrally manage certificates across the organization.

Capability	What It Does
Discovery	Automatically detect all certificates on the network. Visualize "what's where"
Expiry Monitoring	Alert on certificates approaching expiration. Slack / PagerDuty integration
Auto-renewal	Execute automated renewal across ACME-compatible systems in bulk
Policy Enforcement	Enforce rules like "RSA 4096+ only" or "no key reuse"
Reporting	Compliance dashboard. Audit-ready reporting

9. Public vs. Private Certificates

One more critical clarification. SC-081v3 only applies to "publicly trusted" TLS certificates—those issued by CAs in browsers' trust stores.

Certificate Type	SC-081v3 Scope	Examples
Public certificates	✅ In scope	Public-facing websites, external APIs, mail servers
Private certificates	❌ Out of scope	Internal PKI-issued certs, inter-service mTLS, IoT device certs, dev/staging environments

Certificates issued by your organization's private CA can have whatever validity period your policies dictate.

That said, the best practices proven with public certificates—short lifetimes and automation—should be applied to private PKI as well. Workload identity frameworks like SPIFFE/SPIRE default to certificate lifetimes of roughly 1 hour, which sits squarely on this same trajectory.

Conclusion

The reason certificate lifetimes keep shrinking can be summed up in one sentence: "Because revocation is broken."

CRL and OCSP are structurally broken. OCSP's soft-fail, in particular, harbors a fatal contradiction: it stops working precisely when you're under attack—the exact moment revocation checking matters most
CA/Browser Forum SC-081v3 mandates a maximum validity of 47 days by March 2029. DCV reuse periods are also being cut to 10 days
Let's Encrypt led the charge with 90-day certificates and launched 6-day certificates in 2026
Shorter lifetimes directly support post-quantum migration readiness (Crypto Agility)
In the 47-day era, full ACME automation becomes a survival requirement. Manual management is physically impossible
SC-081v3 only applies to public certificates. Private PKI can operate under its own policies

Phase 1 (200 days) took effect in March 2026. It's already here. If your organization hasn't adopted automated certificate renewal yet, you'd better start moving before Phase 2 (100 days) arrives in 2027.

References

Why I Built opa-authzen-interop: Verifying OPA on AuthZEN Interop

kt — Sun, 05 Apr 2026 13:14:55 +0000

Introduction

In my earlier post, I Built an OPA Plugin That Turns It Into an AuthZEN-Compatible PDP, I covered how I added AuthZEN API support (POST /access/v1/evaluation) directly to OPA.

When I looked at the interop results page, I saw multiple projects already validating on the same scenario.

That became the main reason I started this repo: I wanted to put my implementation on the same field and verify it there too.

So I built opa-authzen-interop.

Repo: https://github.com/kanywst/opa-authzen-interop

What This Article Covers

Why I separated an interop-focused repo from the plugin repo
How other projects are participating in OpenID AuthZEN interop
Where opa-authzen-interop stands today and what comes next

The article assumes basic familiarity with PDP/PEP and the AuthZEN Authorization API.

Why A Separate Repo

opa-authzen-plugin is responsible for one thing: implementing the AuthZEN API in OPA.

interop is responsible for something different: locking scenario-specific policy/data/tests and validating compatibility.

If both live in one repo, the boundary between product implementation and spec-validation tests gets blurry.

In short: plugin is product code, interop is verification infrastructure.

Are Other Projects Doing Interop Too?

Yes, absolutely.

According to the official AuthZEN Interop Introduction, seven formal interop events were organized from June 2024 through December 2025.

On the Todo 1.1 (authorization-api-1_0-02) results pages, OPA appears alongside Cerbos, Topaz, OpenFGA, Aserto, Axiomatics, WSO2, and others.

One concrete public implementation example:

aserto-dev/authzen-topaz-proxy

So this “interop-focused verification repo” approach is not unique to my project; it's already a practical pattern in the ecosystem. I aligned with that approach and split out verification assets for opa-authzen-plugin.

Current Status (as of April 5, 2026)

Based on the opa-authzen-interop README:

authorization-api-1_0-01 (single evaluation): 40/40 PASS
POST /access/v1/evaluations (batch): not implemented yet, returns 404

So there is still a clear gap.

At the same time, the official OPA interop results page for Todo 1.1 already shows authorization-api-1_0-02 runs.

That makes the next goal straightforward: stabilize 1_0-02 support in my own repo as well.

Next Action

The next three steps are clear:

Implement POST /access/v1/evaluations in opa-authzen-plugin
Make opa-authzen-interop green for authorization-api-1_0-02
Add interop tests to CI so regressions are caught at PR time

Longer-term, as interop scenarios evolve, Search/IdP paths (/access/v1/search/*) should also become tracking targets.

Authorization Model In The Todo Scenario

The Todo scenario is “5 users × 5 actions”.

Action	admin (Rick)	editor (Morty, Summer)	viewer (Beth, Jerry)
`can_read_user`	allow	allow	allow
`can_read_todos`	allow	allow	allow
`can_create_todo`	allow	allow	deny
`can_update_todo`	allow (any)	allow (own only)	deny
`can_delete_todo`	allow (any)	allow (own only)	deny

In Rego, input.subject.id is mapped through data.users, roles are evaluated, and ownership-scoped actions check ownerID.

# can_create_todo: allow for admin or editor roles
allow if {
  input.action.name == "can_create_todo"
  some role in user.roles
  role in {"admin", "editor"}
}

# can_update_todo: editor can update only their own todos
allow if {
  input.action.name == "can_update_todo"
  "editor" in user.roles
  input.resource.properties.ownerID == user.email
}

How To Run

Shortest path:

make test

If you want to run the official harness directly:

make up

git clone https://github.com/openid/authzen.git
cd authzen/interop/authzen-todo-backend
yarn install && yarn build
yarn test http://localhost:8181 authorization-api-1_0-01 console

make test flow:

Final Note (Issue / PR)

There are still many parts I need to improve. If you spot anything, feedback would really help.

Bug reports: Issue with reproducible steps
Spec mismatches: Issue with the relevant scenario URL
Improvements / implementation changes: Pull Request

evaluations support is still in progress, so suggestions and fixes are both very welcome.

I Built an OPA Plugin That Turns It Into an AuthZEN-Compatible PDP

kt — Wed, 01 Apr 2026 17:10:01 +0000

Introduction

In my previous article, I did a deep dive into the AuthZEN Authorization API 1.0 spec. It standardizes communication between PEPs and PDPs. You send a JSON request asking "can this subject do this action on this resource?" and get back {"decision": true/false}.

So the spec makes sense. But how do you actually use OPA as an AuthZEN-compatible PDP?

OPA already has a REST API (POST /v1/data/...), but it doesn't match the AuthZEN API.

Different path: AuthZEN uses POST /access/v1/evaluation
Different request structure: OPA requires wrapping in {"input": {...}}
Different response structure: OPA returns {"result": ...}

There's an authzen-proxy in contrib, a Node.js proxy, but it requires a separate process.

So I built a plugin that runs the AuthZEN API directly inside the OPA process using OPA's plugin mechanism.

Repo: github.com/kanywst/opa-authzen-plugin

The OPA Community Discussion

Before getting into the code, some context on why this ended up as a plugin.

I opened an issue (#8449) on the OPA repository and brought it up in the #contributors Slack channel.

The Initial Proposal: Route Aliases

server:
  route_aliases:
    /access/v1/evaluation: /v1/data/authzen/allow

The idea was to add configurable path mapping to the OPA server. I also put up a PR (#8451).

But path mapping alone can't handle request/response transformation, so it wouldn't fully satisfy the AuthZEN spec.

What the Community Said

The conclusion was:

Not in OPA core. OPA is a general-purpose policy engine used beyond just authorization. Adding use-case-specific features increases the surface area.
Plugin / distribution is the right approach. Same pattern as opa-envoy-plugin. Single binary, OPA + AuthZEN server.
Evaluation API is enough. The only REQUIRED endpoint in the well-known metadata is access_evaluation_endpoint. Evaluations (batch) and Search APIs are all OPTIONAL.

Nobody was against AuthZEN support itself. The stance was: start as a plugin, and if demand grows, it can move closer to core later.

There aren't many production AuthZEN users yet, so adding it to core didn't have strong justification at this point.

Architecture

Just like opa-envoy-plugin bundles OPA + Envoy External Authorization (gRPC) into a single binary, opa-authzen-plugin bundles OPA + an AuthZEN HTTP server into one.

Key points:

The AuthZEN request body (subject, resource, action, context) becomes OPA's input as-is. No wrapping needed.
The plugin evaluates data.<path>.<decision> (default: data.authzen.allow) and returns the bool result as {"decision": ...}.
OPA's REST API (:8181) still works. Bundles, decision logs, and all other OPA features are available.

OPA's Plugin Mechanism

OPA lets you register plugins at runtime. Call runtime.RegisterPlugin with a Factory, and OPA will instantiate and start your plugin based on the config file.

The entrypoint is just this:

func main() {
    runtime.RegisterPlugin(plugin.PluginName, plugin.Factory{})

    if err := cmd.RootCommand.Execute(); err != nil {
        os.Exit(1)
    }
}

opa-envoy-plugin uses the exact same pattern. runtime.RegisterPlugin to register a gRPC server plugin.

How AuthZEN Requests Reach OPA

An AuthZEN Access Evaluation API request looks like this:

{
  "subject": {"type": "user", "id": "alice", "properties": {"role": "admin"}},
  "resource": {"type": "document", "id": "doc-123"},
  "action": {"name": "delete"},
  "context": {"time": "2026-04-01T12:00:00Z"}
}

The plugin passes this body directly as OPA's input. In Rego, you reference it like:

package authzen

default allow = false

allow if input.subject.properties.role == "admin"

allow if {
    input.action.name == "read"
    input.subject.id != ""
}

With OPA's Data API, you'd need to wrap it as {"input": {...}} and POST /v1/data/authzen/allow. The plugin handles that conversion internally.

Same for the response. OPA returns {"result": true}, and the plugin converts it to {"decision": true}.

Policy Dispatch

AuthZEN uses a single endpoint (/access/v1/evaluation) for all authorization decisions. If you want to route to different policies per resource type or action, you do that in Rego by checking input.resource.type or input.action.name.

package authzen

default allow = false

# anyone can read todolists
allow if {
    input.resource.type == "todolist"
    input.action.name == "read"
}

# only editors can create todolists
allow if {
    input.resource.type == "todolist"
    input.action.name == "create"
    input.subject.properties.role == "editor"
}

# only admins can manage accounts
allow if {
    input.resource.type == "account"
    input.action.name == "manage"
    input.subject.properties.role == "admin"
}

As mentioned in the community discussion, PDP-specific hints (like which policy to evaluate) can also be passed via the context object:

{
  "subject": {"type": "user", "id": "alice"},
  "action": {"name": "read"},
  "resource": {"type": "todolist", "id": "1"},
  "context": {"policy_hint": "todolist"}
}

Well-Known Metadata

The PDP metadata endpoint defined in Section 9 of the spec. PEPs can use it to dynamically discover which endpoints are available.

$ curl -s http://localhost:9292/.well-known/authzen-configuration | jq .
{
  "policy_decision_point": "http://localhost:9292",
  "access_evaluation_endpoint": "http://localhost:9292/access/v1/evaluation"
}

OPTIONAL endpoints (access_evaluations_endpoint, search_*) aren't returned since they're not implemented. Per the spec, parameters with no value MUST be omitted.

Try It Out

Build and Run

git clone https://github.com/kanywst/opa-authzen-plugin.git
cd opa-authzen-plugin
make build
./opa-authzen-plugin run --server \
  --config-file example/config.yaml \
  example/policy.rego

Also works with Docker:

make docker-build
make docker-run

Send Requests

Admin user deleting a document (allowed):

$ curl -s -X POST http://localhost:9292/access/v1/evaluation \
  -H "Content-Type: application/json" \
  -d '{
    "subject": {"type": "user", "id": "alice", "properties": {"role": "admin"}},
    "resource": {"type": "document", "id": "doc-123"},
    "action": {"name": "delete"}
  }'
{"decision":true}

Regular user deleting a document (denied):

$ curl -s -X POST http://localhost:9292/access/v1/evaluation \
  -H "Content-Type: application/json" \
  -d '{
    "subject": {"type": "user", "id": "bob", "properties": {"role": "viewer"}},
    "resource": {"type": "document", "id": "doc-123"},
    "action": {"name": "delete"}
  }'
{"decision":false}

The X-Request-ID header is echoed back in the response (Section 10.1.3):

$ curl -si -X POST http://localhost:9292/access/v1/evaluation \
  -H "Content-Type: application/json" \
  -H "X-Request-ID: req-abc-123" \
  -d '{
    "subject": {"type": "user", "id": "alice", "properties": {"role": "admin"}},
    "resource": {"type": "document", "id": "1"},
    "action": {"name": "read"}
  }'
HTTP/1.1 200 OK
Content-Type: application/json
X-Request-Id: req-abc-123

{"decision":true}

What's Next

This is a PoC with just the Evaluation API.

Evaluations API (batch): OPTIONAL, but there's demand. Topaz has 1000+ edge users asking for it.
Search APIs: Hard to implement generically on top of OPA (ABAC). Partial evaluation might work, but nobody has explored that yet.
gRPC: There's interest in having gRPC alongside REST, but REST comes first.

Depending on how the OPA community responds, this could move to contrib or be integrated with opa-envoy-plugin.

Google Zanzibar Deep Dive: Handling 2 Trillion ACLs in Under 10ms

kt — Wed, 01 Apr 2026 13:58:38 +0000

Introduction

Spend any time in the authorization space and you'll notice that SpiceDB and OpenFGA both claim to be "inspired by Google Zanzibar." I got curious and pulled up the 2019 USENIX ATC paper — "Zanzibar: Google's Consistent, Global Authorization System" — to see what the fuss was about.

My first reaction after reading it: the data model is almost offensively simple. Over two trillion ACLs, ten million authorization checks per second, p95 latency under 10ms — and the whole thing runs on a single string: object#relation@user.

Why does something this minimal hold up at planetary scale without falling apart? This post is my attempt to answer that.

Scope

First, let's place Zanzibar in the authorization stack.

Layer	What it does	Examples
Authentication	Verifies who the user is	OpenID Connect, SAML
Token issuance	Hands out access tokens	OAuth 2.0 (RFC 6749)
Authorization	"Can this user access this resource?"	Zanzibar (this post), XACML, OPA

Zanzibar is purely about authorization decisions. It's a different layer from OAuth. If OAuth is "handing someone a key," Zanzibar is "deciding which rooms that key opens."

Prerequisites:

Basic access control concepts (who, what, can do what)
A rough idea of how RBAC works

1. The Problem Zanzibar Solves

1.1 Why Google Needed a Unified Authorization System

When dozens of services each implement their own access control, things get messy fast:

Problem	Why it hurts
Inconsistency	"Sharing" behaves differently in Drive vs. Photos — confusing for users
Cross-service coordination	A Google Photos image embedded in a Docs file: whose ACL applies?
Access-aware search	Building a search index that respects permissions across services is a nightmare if every team solves it separately
Engineering waste	Every team reinventing consistency and scalability from scratch

Zanzibar solves all of this by acting as a single unified ACL store + evaluation engine for all Google services.

1.2 Design Goals

The paper lists five goals:

Goal	Description	Concrete target
Correctness	Respect user intent	Prevent the "New Enemy" problem (Section 5)
Flexibility	Support diverse access control policies	RBAC, ReBAC, hierarchical ACLs, etc.
Low latency	Authorization shouldn't slow down user interactions	p95 < 10ms
High availability	If authorization is down, everything is down	99.999%+
Scale	One system for all of Google	2T+ ACLs, 10M+ requests/sec

"Correctness" is where the New Enemy problem comes in — it's not just about returning the right answer, it's about respecting the causal order of changes.

2. Relation Tuples — The Data Model

Zanzibar's core is a data model so simple it almost looks wrong: the Relation Tuple.

2.1 Syntax

⟨object⟩#⟨relation⟩@⟨user⟩

"This user has this relation to this object." That's it.

Some examples:

Tuple	Meaning
`doc:readme#owner@alice`	alice is an owner of doc:readme
`group:eng#member@bob`	bob is a member of group:eng
`doc:readme#viewer@group:eng#member`	Every member of group:eng is a viewer of doc:readme
`doc:readme#parent@folder:A#...`	doc:readme lives inside folder:A

Look at the third row. The @ side isn't a user ID — it's group:eng#member. This is called a userset: "all users who have the member relation to group:eng." It lets ACLs point to groups, and it lets groups contain other groups.

The neat consequence: ACLs and groups are the same data structure. A group is just an object that uses "member" semantics.

2.2 What Relation Tuples Can Express

All four of these common patterns fit the same one-line format:

Direct access — doc:readme#viewer@alice (alice is a viewer)
Group membership — group:eng#member@alice (alice is in the eng group)
Indirect access — doc:readme#viewer@group:eng#member (everyone in eng is a viewer)
Object hierarchy — doc:readme#parent@folder:A#... (readme is inside folder:A)

No special syntax. One format for everything.

2.3 Why Tuples?

Traditional ACLs are usually stored per-object. Zanzibar switched to a tuple-based model for three reasons:

Efficient reads: "What groups is user X a member of?" is just a reverse lookup on tuples
Incremental updates: Adding or removing access means writing or deleting one tuple, not rewriting an entire ACL
Unified model: ACLs and groups don't need separate data structures

3. Namespace Configuration — Defining Policies

Tuples alone can't express rules like "editors are automatically viewers too." That's what Namespace Configuration is for.

3.1 Userset Rewrites

Here's the namespace config from Figure 1 of the paper (written in a Protocol Buffers-style config language):

name: "doc"

relation { name: "owner" }

relation {
  name: "editor"
  userset_rewrite {
    union {
      child { _this {} }                              // directly added editors
      child { computed_userset { relation: "owner" } } // + all owners
    }
  }
}

relation {
  name: "viewer"
  userset_rewrite {
    union {
      child { _this {} }                               // directly added viewers
      child { computed_userset { relation: "editor" } } // + all editors
      child { tuple_to_userset {                        // + viewers of the parent folder
        tupleset { relation: "parent" }
        computed_userset {
          object: $TUPLE_USERSET_OBJECT
          relation: "viewer"
        }
      } }
    }
  }
}

The structure is concentric: owner ⊂ editor ⊂ viewer. And the "inherit viewer permissions from the parent folder" rule is defined in one place, globally, with no per-object tuples needed.

3.2 The Three Leaf Node Types

Userset rewrite rules are trees built from three kinds of leaf nodes:

Leaf node	Meaning	Example
`_this`	Users directly assigned this relation on this object	Someone explicitly added as `doc:readme#editor`
`computed_userset`	Another relation on the same object	"owners are automatically editors"
`tuple_to_userset`	Follow a relation to another object and inherit	"look up the parent folder and take its viewers"

Leaf nodes can be combined with union, intersection, and exclusion. This gives you RBAC, ReBAC, and ABAC-style policies — all from the same config language.

4. API

Zanzibar exposes five API methods:

API	Purpose	Description
Check	Authorization check	"Does user U have relation R to object O?"
Read	Tuple lookup	Returns raw tuples as stored (does not expand rewrites)
Write	Tuple modification	Add or remove tuples
Watch	Change streaming	Stream tuple changes in real time
Expand	Effective userset	Returns the full tree of users who have a relation, following rewrites

4.2 How Check Works

Check is the core API. Under the hood:

Spanner is the underlying storage — covered in Section 6. Check requests can also carry a Zookie to control consistency — explained in Section 5.

The key thing happening here is recursive pointer chasing. To check viewer, Zanzibar looks at editor. To check editor, it looks at owner. Deeply nested groups make this recursion expensive. The Leopard index (Section 7) exists specifically to solve that.

One gotcha with Read: it does not expand userset rewrites. Reading the viewer relation won't return owners or editors, even if the namespace config says they're viewers. For that, use Expand.

5. The "New Enemy" Problem

Zanzibar's most distinctive feature is external consistency. The guarantee: if transaction A commits before transaction B starts, B will always see A's result. The causal order of real-world events is reflected in the database.

This matters because of the "New Enemy" problem.

5.1 What Is the New Enemy Problem?

The paper walks through two examples.

Example A: Ignoring ACL update order

Example B: Old ACL applied to new content

Alice removes Bob from a document's ACL
Alice asks Charlie to add new content to the document
Bob shouldn't be able to see the new content. But if the ACL check evaluates against the pre-removal ACL, Bob gets through

This is the New Enemy problem: ignoring the causal ordering between ACL changes and content changes breaks access control in ways that are hard to reason about.

5.2 Zookie — Encoding Causality in a Token

Zanzibar fixes this with Zookies.

How it works:

When content is modified, the client sends a content-change check to Zanzibar
Zanzibar encodes the current global timestamp into a Zookie and returns it
The client stores the Zookie alongside the new content
Subsequent ACL checks include the Zookie — telling Zanzibar: "evaluate using a snapshot at least as fresh as this timestamp"

Zookies are opaque byte strings by design. Clients can't set arbitrary timestamps; they can only pass back what Zanzibar gave them.

Why not always evaluate at the latest snapshot? That would require global synchronization across all replicas — wrecking latency and availability. The Zookie's "at-least-as-fresh" semantics let Zanzibar pick any snapshot newer than the encoded timestamp. In practice, most checks use already-replicated local data and never wait on cross-region round trips.

6. Architecture

To understand the architecture, you first need to know Spanner. It's Google's globally distributed database: data is replicated across data centers worldwide, and it provides external consistency (the same guarantee Zanzibar builds on). The mechanism is TrueTime — a time API backed by GPS and atomic clocks that produces timestamps with bounded error, allowing causally ordered commits across the globe.

Zanzibar is built on top of Spanner's consistency guarantees.

6.1 System Overview

Component	Role
aclserver	Core server. Handles Check, Read, Expand, Write. Fans out work to other aclservers in the cluster
watchserver	Handles Watch requests. Tails the changelog and streams changes in near real time
Spanner	ACL storage. Provides external consistency and snapshot reads
Leopard	Specialized index for deeply nested group membership evaluation
Periodic batch pipeline	Offline jobs: snapshot dumps, tuple garbage collection, etc.

6.2 Storage

Each namespace's relation tuples live in a separate Spanner database. The primary key is (shard ID, object ID, relation, user, commit timestamp).

The critical detail: commit timestamp is part of the primary key. Multiple versions of the same tuple are stored as separate rows. This lets Zanzibar do snapshot reads at any timestamp within the GC window — which is the foundation for Zookie semantics.

6.3 Replication

Zanzibar replicates all ACL data to 30+ locations worldwide. Geographic partitioning doesn't work here — you can't predict which region will check which object's ACL.

Write consensus uses Paxos (a distributed consensus protocol where multiple nodes agree on a single value). The 5 voting replicas sit in 3 metropolitan areas in the eastern and central US, within 25ms of each other, keeping Paxos commit latency predictable.

7. How They Hit 10ms

Two trillion ACLs. Ten million requests per second. p95 under 10ms. Here's how.

7.1 The Leopard Index

Recursive pointer chasing breaks down when groups are deeply nested or have huge numbers of sub-groups. Leopard preprocesses this.

Leopard maintains two index types:

GROUP_2_GROUP(G): All direct and indirect descendant groups of group G (pre-expanded)
MEMBER_2_GROUP(U): All groups user U is a direct member of

"Is user U a member of group G?" becomes a single set intersection:

MEMBER_2_GROUP(U) ∩ GROUP_2_GROUP(G) ≠ ∅

Visualized:

No deep recursion. The index is stored as skip lists, and set intersection runs in O(min(|A|,|B|)).

Leopard uses a two-tier design: an offline batch layer that periodically rebuilds the full index from a Spanner snapshot, and an online incremental layer that watches for changes via the Watch API and keeps the index current. The incremental layer is what makes Leopard queries consistent at any given snapshot timestamp.

7.2 Hot Spot Handling

When Google Drive shows search results, it fires dozens to hundreds of ACL checks simultaneously. If those documents all share a common group (say, group:all-employees), you get a hot spot on the data backing that group.

Technique	What it does
Distributed cache	aclservers form a consistent-hash cache cluster. Both the caller and callee of delegated RPCs cache results
Lock table	Deduplicates concurrent requests for the same cache key. One request runs; the rest wait for the result
Timestamp quantization	Rounds evaluation timestamps up to 1-second or 10-second boundaries, dramatically increasing cache hit rate
Hot object prefetch	When a specific object sees a burst of checks, prefetch all its tuples into cache
Request hedging	If a Spanner or Leopard request is slow, send the same request to a second server and use whichever responds first

Timestamp quantization deserves special mention. Spanner timestamps have microsecond resolution, but Zanzibar rounds them up to 1s or 10s at evaluation time. This means the vast majority of requests land on the same handful of timestamps and share cache results. Rounding up doesn't break consistency — a Spanner snapshot read at timestamp T includes all writes up to T, and if T is in the future, Spanner just waits.

7.3 Performance Isolation

In a shared service, one bad client can drag everyone down. Zanzibar's isolation mechanisms:

Per-client CPU budget (throttled if exceeded and system is under load)
Per-server limit on outstanding RPCs
Per (object, client) limit on concurrent Spanner reads
Per-client lock table keys (so one client's throttling doesn't block others)

8. Production Numbers (December 2018)

Metric	Value
Namespaces	1,500+
Relation tuples	2 trillion+ (~100 TB)
Replication	30+ locations worldwide
Servers	10,000+
Check QPS (peak)	~4.2M
Read QPS (peak)	~8.2M
Check Safe p50	3ms
Check Safe p95	~10ms
Check Safe p99	~15ms
Check Recent p95	~60ms
Availability	99.999% (sustained over 3 years)

Two request categories:

Safe: Zookie is older than 10 seconds → serves from local replica (fast)
Recent: Zookie is within the last 10 seconds → may require cross-region round trips (~60ms)

Safe requests outnumber Recent by roughly 100:1. That gap is entirely by design — Zookies make the common case local.

9. Lessons from the Paper

Section 4.5 of the paper (Lessons Learned) is unusually candid for a systems paper. Five years of production, written honestly.

9.1 Flexibility Comes Later

The initial userset rewrite only had _this. computed_userset and tuple_to_userset were added later, in response to actual client requirements from Drive and Photos. Google didn't design the perfect abstraction upfront — they extended it as real use cases showed up.

9.2 Most Freshness Requirements Are Loose

The majority of clients are fine with slightly stale ACL evaluations. Zanzibar's Zookie protocol was designed around this: default to loose freshness, tighten only when necessary. That's the key to hitting p95 10ms — most requests never need cross-region coordination.

9.3 You Can't Skip Hot Spot Mitigation

The Drive search case — hundreds of simultaneous ACL checks that all fan into the same popular group — created hot spots that general caching couldn't fully absorb. They added targeted optimizations: hotness detection, full-tuple prefetch, delayed cancellation of secondary checks when waiters are queued. Hot spot handling wasn't nice-to-have; it was essential.

9.4 ReBAC as a Paradigm

Zanzibar has effectively become the reference implementation for Relationship-Based Access Control (ReBAC). The comparison:

Model	Decision basis	Example
RBAC	User's role	"admin role → can delete"
ABAC	User and resource attributes	"same department + business hours → access granted"
ReBAC	Relationship between user and resource	"owner of the doc, or viewer of its parent folder"

ReBAC's advantage is that real-world organizational structure — folder hierarchies, team memberships, org charts — maps directly to the authorization model. Google Drive's "share this folder with your team" is a textbook ReBAC problem.

10. The OSS Ecosystem

The paper landed in 2019 and immediately spawned a cluster of projects:

Project	By	Notes
SpiceDB	AuthZed	The most faithful OSS implementation. Founded by former Zanzibar team members. Uses its own schema language (Zed)
OpenFGA	Okta / Auth0	Zanzibar-inspired ReBAC engine. CNCF incubating (2024). Integrated into the Auth0 ecosystem
Ory Keto	Ory	Zanzibar-based authorization service, part of Ory's auth stack
Google Cloud IAM	Google	Explicitly built on top of Zanzibar (stated in the paper itself)

It's not just OSS. Airbnb built an internal system called "Himeji" directly inspired by Zanzibar. Carta and Notion have both adopted Zanzibar-style approaches.

Conclusion

The key ideas from Zanzibar:

object#relation@user — a single tuple format that unifies ACLs and groups. The same structure handles direct permissions, group membership, and object hierarchies
Userset Rewrites for flexible policy definition. owner ⊂ editor ⊂ viewer and folder-to-document inheritance, all declared in one namespace config
Zookies solve the New Enemy problem. An opaque token encodes a causal timestamp; subsequent checks respect that ordering
Built on Spanner's external consistency. TrueTime (GPS + atomic clocks) makes causally ordered commits possible at global scale
Leopard makes deep nesting fast. Pre-expand group-to-group relationships; membership checks become a set intersection in O(min(|A|,|B|))
Timestamp quantization + distributed caching absorb hot spots. Hundreds of simultaneous checks from a single search query don't blow up the system
Zanzibar defined the ReBAC landscape. SpiceDB, OpenFGA, and Ory Keto are all downstream of this paper

Think of Zanzibar as the GFS of authorization systems. GFS established the design patterns for distributed storage. Zanzibar did the same for relationship-based access control.

References

AuthZEN Authorization API 1.0 Deep Dive: The Standard API That Separates Authorization Decisions from Enforcement

kt — Mon, 30 Mar 2026 12:08:40 +0000

Introduction

In the authentication space, OpenID Connect has become the de facto standard, centralizing identity around Identity Providers. In the authorization space — specifically delegated authorization — OAuth 2.0 stands as a robust standard.

But what about a standard API for fine-grained authorization within applications?

In the era of microservice architectures, everyone eventually hits the same wall: "Where and how should we evaluate authorization?"

Service A uses OPA (Open Policy Agent)
Service B adopted Cedar
Service C is still dragging around a legacy in-house authorization library

When authorization logic is scattered across services like this, maintaining a consistent view of "who can do what on which resource" across the entire system becomes extremely difficult — auditing and policy changes become a nightmare.

The established best practice is to separate the decision (PDP) from the enforcement (PEP). But there was another problem: no standard protocol existed to connect PDP and PEP. While excellent policy engines like OPA, Cedar, and Topaz kept emerging, the communication interface between applications (PEP) and policy engines (PDP) remained proprietary — an era without a standard.

This situation has finally been resolved by the AuthZEN Authorization API 1.0, developed by the AuthZEN Working Group under the OpenID Foundation. Published as a Standards Track specification in March 2026, this simple JSON-based API is the long-awaited standard protocol for asking "Can who do what on which resource?" between PDP and PEP.

Scope of This Article

First, let's clarify where the Authorization API fits in the landscape.

OAuth 2.0 is a mechanism for "a client to obtain tokens to access a resource server." AuthZEN Authorization API is a mechanism for "externalizing whether a given request should be allowed or denied within an application." They operate at different layers.

OAuth deals with Client-AS-RS communication. AuthZEN deals with PEP-PDP communication within applications. It's crucial not to confuse the two.

The Authorization API is version 1.0, and endpoints SHOULD include v1 in their paths (e.g., /access/v1/evaluation). Future revisions MUST NOT modify the existing API — only augment it. This means methods and parameters may be added, but the semantics of existing fields will never change. Additionally, receivers MUST ignore unknown fields, ensuring forward compatibility when old and new PDPs/PEPs coexist.

This article assumes the following prerequisite knowledge:

Basics of HTTP / REST APIs (request-response structure)
Reading and writing JSON
Basic access control concepts (who, what, on which resource)

1. Why Separate Authorization Decisions?

1.1 The Limits of Embedded Authorization Logic (Silos and Technical Debt)

In a monolithic application, middleware could handle access control in one place. However, in modern microservice environments, authorization logic often gets embedded directly in each service's application code, creating silos.

This pattern of "distributed and embedded authorization" causes increasingly severe problems as systems grow:

Problem	Real-World Impact
Policy Silos	The conditions for "who can view a document" are scattered across multiple services, and no one can grasp the consistent policy across the entire system.
High Cost of Change	A business requirement change like "restrict external collaborator permissions" requires modifying multiple repositories and redeploying each one.
Inconsistency	Different languages and implementation approaches (DB lookups, JWT evaluation, etc.) per service lead to permission bypass or contradictions in edge cases.
Audit Difficulty (Compliance)	Proving "who can access what" requires reading through each codebase, making security audits and SOC2 compliance requirements practically impossible.

1.2 PDP/PEP Model — Separating Decision from Enforcement

The solution is to externalize authorization decisions to a dedicated service.

The terminology for this model is defined in XACML and NIST SP 800-162 (ABAC):

Term	Full Name	Role
PDP	Policy Decision Point	Decides whether to allow access based on policy
PEP	Policy Enforcement Point	Enforces the PDP's decision
PAP	Policy Administration Point	Manages policies (out of AuthZEN's scope)
PIP	Policy Information Point	Provides attribute information needed for decisions (out of AuthZEN's scope)

The AuthZEN Authorization API standardizes the PEP -> PDP communication.

1.3 Why a Standard API Is Needed

The PDP/PEP model itself is not a new concept. So why is a standard API needed now?

Because the PDP implementation landscape is highly fragmented.

PDP Implementation	Developer	Policy Language	API
OPA	Styra / CNCF	Rego	Proprietary REST API
Cedar	AWS	Cedar	Proprietary API
Topaz	Aserto	Rego / OPA-compatible	Proprietary REST / gRPC
Axiomatics	Axiomatics	ALFA / XACML	Proprietary REST API
SpiceDB	AuthZed	Zanzibar-style	Proprietary gRPC

Since each PDP has its own API, applications become tightly coupled to a specific PDP. If you want to switch PDPs, you need to rewrite all authorization call code on the application side.

The AuthZEN Authorization API aims to standardize the PDP-PEP interface, making PDP implementations interchangeable.

2. The Information Model of the Authorization API

The core of the Authorization API is the information model called the "4-tuple." An Access Evaluation request consists of four elements.

Let's examine each one in detail.

2.1 Subject (Who)

A Subject represents the user or machine principal (such as a service account) requesting access.

Field	Required	Type	Description
`type`	REQUIRED	string	The type of Subject (`user`, `service`, `device`, etc.)
`id`	REQUIRED	string	Unique identifier for the Subject (unique within its `type`)
`properties`	OPTIONAL	object	Additional attributes (department, IP address, device ID, etc.)

{
  "type": "user",
  "id": "alice@acmecorp.com",
  "properties": {
    "department": "Sales",
    "ip_address": "172.217.22.14",
    "device_id": "8:65:ee:17:7e:0b"
  }
}

The properties field is important. Many authorization systems operate statelessly, so the PEP needs to pass all attributes required for policy evaluation at request time. For example, if there's a policy stating "only Sales department users can access," the PEP must include department in properties — otherwise the PDP cannot make a decision.

2.2 Resource (On What)

A Resource represents the target of the access request.

Field	Required	Type	Description
`type`	REQUIRED	string	The type of Resource (`document`, `account`, `book`, etc.)
`id`	REQUIRED	string	Unique identifier for the Resource
`properties`	OPTIONAL	object	Additional attributes

{
  "type": "book",
  "id": "123",
  "properties": {
    "library_record": {
      "title": "AuthZEN in Action",
      "isbn": "978-0593383322"
    }
  }
}

Since properties can contain nested JSON objects, resource metadata can be expressed flexibly.

2.3 Action (What)

An Action represents the operation the Subject intends to perform on the Resource.

Field	Required	Type	Description
`name`	REQUIRED	string	Name of the action
`properties`	OPTIONAL	object	Additional attributes

{
  "name": "can_read",
  "properties": {
    "method": "GET"
  }
}

The specification defines common action names corresponding to CRUD operations:

Action	Description
`can_access`	Generic access (when not distinguishing by type)
`can_create`	Create
`can_read`	Read (including list retrieval)
`can_update`	Update (partial or full replacement)
`can_delete`	Delete

These are recommended common names, but application-specific action names (e.g., can_approve, can_publish) can be freely used.

2.4 Context (Under What Circumstances)

Context is an arbitrary JSON object representing environmental information or circumstances of the request.

{
  "time": "1985-10-26T01:22-07:00"
}

Time, network information, risk scores, and other information needed for decisions but not belonging to Subject, Action, or Resource go here.

3. Access Evaluation API — Request and Response

Now that we understand the information model, let's look at the actual API.

3.1 Request

Assemble the 4-tuple into JSON and send it to the PDP.

{
  "subject": {
    "type": "user",
    "id": "alice@acmecorp.com"
  },
  "resource": {
    "type": "account",
    "id": "123"
  },
  "action": {
    "name": "can_read",
    "properties": {
      "method": "GET"
    }
  },
  "context": {
    "time": "1985-10-26T01:22-07:00"
  }
}

In plain language, this query asks:

Can the user alice@acmecorp.com read (can_read) account #123? (At time 1985-10-26T01:22-07:00)

3.2 Response — Decision

The simplest response is just a JSON with a decision field:

{
  "decision": true
}

decision is a boolean — true = allow, false = deny. That's it. The specification is intentionally designed to be simple.

3.3 Response — Additional Context

The PDP can return additional information via a context field alongside the decision. Use cases cited by the specification:

"Advice" or "obligations" — Additional instructions like "record this access in the audit log" (a concept from XACML; Section 9 compares XACML in detail)
UI rendering hints — "This operation is not permitted, so gray out the button"
Step-up authentication instructions — "This operation requires additional authentication"

{
  "decision": false,
  "context": {
    "id": "0",
    "reason_admin": {
      "en": "Request failed policy C076E82F"
    },
    "reason_user": {
      "en-403": "Insufficient privileges. Contact your administrator",
      "es-403": "Privilegios insuficientes. Póngase en contacto con su administrador"
    }
  }
}

reason_admin provides administrator-facing reasons (not to be shown to end users), while reason_user provides user-facing reasons. Multi-language support is also possible.

An example returning step-up authentication hints:

{
  "decision": false,
  "context": {
    "acr_values": "urn:com:example:loa:3",
    "amr_values": "mfa hwk"
  }
}

In this case, the PEP can instruct the user to "re-authenticate at LOA 3 or higher (MFA + hardware key) and retry."

Notably, even when decision: true, if the PEP does not understand the context, it MAY choose to reject the access. Conversely, decision: false is strict — the PEP MUST NOT permit access.

4. Access Evaluations API — Batch Evaluation

The Access Evaluation API in Section 3 was "one request = one decision." But in real applications, there are scenarios where you need to check permissions for multiple resources simultaneously when rendering a screen.

For example, on a document list screen, checking "can this user read?" for each of 30 documents individually would mean 30 API calls — highly inefficient.

The Access Evaluations API (note the trailing s) is a batch evaluation API that solves this problem.

4.1 Batch Request

Bundle multiple evaluation requests in an evaluations array:

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "action": {
    "name": "can_read"
  },
  "evaluations": [
    {
      "resource": {
        "type": "document",
        "id": "boxcarring.md"
      }
    },
    {
      "resource": {
        "type": "document",
        "id": "subject-search.md"
      }
    },
    {
      "resource": {
        "type": "document",
        "id": "resource-search.md"
      }
    }
  ]
}

The key mechanism here is default values. Top-level subject, action, resource, and context serve as defaults for each element in the evaluations array. In the example above, all three evaluations use the same subject and action, so they're specified at the top level to avoid duplication.

Individual evaluations can override defaults:

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "action": {
    "name": "can_read"
  },
  "evaluations": [
    {
      "resource": { "type": "document", "id": "1" }
    },
    {
      "resource": { "type": "document", "id": "2" }
    },
    {
      "action": { "name": "can_edit" },
      "resource": { "type": "document", "id": "3" }
    }
  ]
}

Only the third evaluation overrides the action to can_edit.

4.2 Batch Response

The response also uses an evaluations array, corresponding to the request in the same order:

{
  "evaluations": [
    { "decision": true },
    { "decision": false, "context": { "reason": "resource not found" } },
    { "decision": false, "context": { "reason": "Subject is a viewer of the resource" } }
  ]
}

4.3 Evaluation Semantics — Three Execution Modes

Batch evaluation supports three execution modes via options.evaluations_semantic:

Semantic	Behavior	Programming Analogy
`execute_all`	Execute all requests and return all results (default)	Array `map`
`deny_on_first_deny`	Short-circuit on first denial	`&&` operator
`permit_on_first_permit`	Short-circuit on first permit	`\

Let's see how they work with a concrete example. Suppose we check {% raw %}read permissions for three documents (doc#1, doc#2, doc#3), with results of true, false, true respectively:

execute_all: Evaluates all three -> returns [true, false, true]
deny_on_first_deny: doc#1 -> true, doc#2 -> false, stops here. doc#3 is not evaluated -> returns [true, false]
permit_on_first_permit: doc#1 -> true, stops here. doc#2 and doc#3 are not evaluated -> returns [true]

deny_on_first_deny is useful for scenarios where "all checks must pass." For example, sequentially verifying that a user has a specific role AND is the resource owner AND it's within business hours. permit_on_first_permit is for scenarios where "matching any one rule is sufficient."

4.4 Error Handling

Batch evaluation has two types of errors:

Transport-level errors — Errors affecting the entire request (HTTP 4XX / 5XX)
Individual evaluation errors — A specific evaluation within the evaluations array fails. Returns decision: false + error information in context

{
  "evaluations": [
    { "decision": true },
    {
      "decision": false,
      "context": {
        "error": { "status": 404, "message": "Resource not found" }
      }
    },
    { "decision": false, "context": { "reason": "Subject is a viewer" } }
  ]
}

Individual errors default to deny (false), and the overall request does not fail.

5. Search APIs — Reverse Lookups for "Who?" and "What?"

The Access Evaluation API was a forward lookup: "Can Alice read document#123?" But real applications also need reverse lookups:

"Who can read document#123?" — Display in sharing settings
"Which documents can Alice read?" — Filter the document list
"What operations can Alice perform on document#123?" — Control UI button visibility

These are the Search APIs. By omitting the id of one element from the 4-tuple in the request, the PDP returns a list of permitted entities.

5.1 Three Types of Search APIs

API	Omitted Element	Question	Endpoint
Subject Search	Subject's `id`	"Who can perform this action on this resource?"	`/access/v1/search/subject`
Resource Search	Resource's `id`	"Which resources can this user perform this action on?"	`/access/v1/search/resource`
Action Search	The entire Action	"What actions can this user perform on this resource?"	`/access/v1/search/action`

5.2 Subject Search Example

// Request: Which users can can_read account#123?
{
  "subject": {
    "type": "user"
  },
  "action": {
    "name": "can_read"
  },
  "resource": {
    "type": "account",
    "id": "123"
  }
}

The subject has a type but no id. This signals "search for Subjects."

// Response
{
  "results": [
    { "type": "user", "id": "alice@example.com" },
    { "type": "user", "id": "bob@example.com" }
  ]
}

5.3 Resource Search Example

// Request: Which accounts can alice can_read?
{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "action": {
    "name": "can_read"
  },
  "resource": {
    "type": "account"
  }
}

5.4 Pagination

Search APIs can return large result sets. Pagination is designed around opaque tokens.

Field	Direction	Description
`page.limit`	Request	Maximum items per page
`page.token`	Request	`next_token` from the previous response (for page 2+)
`page.next_token`	Response	Token for the next page. Empty string means final page
`page.count`	Response	Number of items in this page
`page.total`	Response	Total item count (estimate, may fluctuate)
`page.properties`	Both	Implementation-specific attributes such as sorting or filtering (optional)

Important constraint: During pagination, subject, action, resource, and context MUST NOT be changed. If changed, the PDP SHOULD return an error.

5.5 Search API Semantics

Important rules defined by the specification:

Results from a Search API, when passed to the Access Evaluation API, SHOULD yield decision: true. However, this is not guaranteed since the decision may depend on time-varying factors
Searches SHOULD be performed transitively. For example, if user U is a member of group G, and group G is a viewer of document D, then user U should appear in Subject Search results for document D

6. PDP Metadata — The PDP's Self-Description

PDP Metadata is the mechanism by which a PDP tells its clients (PEPs) which endpoints it supports.

The mechanism follows the .well-known URI pattern (RFC 8615) — a web convention for publishing server configuration at a known URL. For example, OAuth authorization servers publish their configuration at /.well-known/oauth-authorization-server. AuthZEN PDPs follow the same pattern.

6.1 Discovery Endpoint

GET /.well-known/authzen-configuration HTTP/1.1
Host: pdp.example.com

In multi-tenant environments, tenant-specific metadata can be provided:

GET /.well-known/authzen-configuration/tenant1 HTTP/1.1
Host: pdp.example.com

6.2 Metadata Response

{
  "policy_decision_point": "https://pdp.example.com",
  "access_evaluation_endpoint": "https://pdp.example.com/access/v1/evaluation",
  "access_evaluations_endpoint": "https://pdp.example.com/access/v1/evaluations",
  "search_subject_endpoint": "https://pdp.example.com/access/v1/search/subject",
  "search_resource_endpoint": "https://pdp.example.com/access/v1/search/resource",
  "search_action_endpoint": "https://pdp.example.com/access/v1/search/action",
  "capabilities": ["urn:ietf:params:authzen:some-capability"]
}

Parameter	Required	Description
`policy_decision_point`	REQUIRED	PDP identifier (URL)
`access_evaluation_endpoint`	REQUIRED	Single evaluation API endpoint
`access_evaluations_endpoint`	OPTIONAL	Batch evaluation API endpoint
`search_subject_endpoint`	OPTIONAL	Subject search endpoint
`search_resource_endpoint`	OPTIONAL	Resource search endpoint
`search_action_endpoint`	OPTIONAL	Action search endpoint
`capabilities`	OPTIONAL	List of URNs for capabilities supported by the PDP

If an optional parameter is absent, the PEP can determine that the corresponding API is not supported. For example, if search_subject_endpoint is missing, Subject Search is not available.

6.3 Signed Metadata

Metadata can also be provided as a JWT (JSON Web Token, RFC 7519) via the signed_metadata parameter, enabling tamper detection through its header-payload-signature structure.

Requirements for signed metadata in the specification:

The JWT MUST be signed with JWS (RFC 7515)
The JWT MUST contain an iss (issuer) claim
Values in signed metadata take precedence over plain JSON metadata
signed_metadata itself SHOULD NOT appear as a claim within the JWT
If the PEP does not support signature verification, it MAY ignore signed_metadata

This enables metadata integrity verification independent of TLS/PKI. This is particularly valuable in environments with intermediate proxies, where TLS alone cannot guarantee end-to-end integrity.

6.4 Validation

The PEP MUST verify that the policy_decision_point value in the metadata matches the PDP identifier used to construct the .well-known URL. If they don't match, the metadata MUST NOT be used. This is the same mix-up attack countermeasure used in OAuth AS Metadata.

7. HTTPS Binding — The Actual HTTP Requests

While the Authorization API itself is designed to be transport-agnostic, the specification defines the HTTPS binding as mandatory (with potential future additions for gRPC, CoAP, etc.).

7.1 Endpoint List

All requests are sent via HTTPS POST.

API	Default Path	Metadata Parameter
Access Evaluation	`/access/v1/evaluation`	`access_evaluation_endpoint`
Access Evaluations	`/access/v1/evaluations`	`access_evaluations_endpoint`
Subject Search	`/access/v1/search/subject`	`search_subject_endpoint`
Resource Search	`/access/v1/search/resource`	`search_resource_endpoint`
Action Search	`/access/v1/search/action`	`search_action_endpoint`

If endpoint URLs are provided via PDP Metadata (Section 6), use those. Otherwise, use the default paths.

7.2 Request Example

POST /access/v1/evaluation HTTP/1.1
Host: pdp.mycompany.com
Content-Type: application/json
Authorization: Bearer <myoauthtoken>
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "subject": {
    "type": "user",
    "id": "alice@acmecorp.com"
  },
  "resource": {
    "type": "todo",
    "id": "1"
  },
  "action": {
    "name": "can_read"
  },
  "context": {
    "time": "1985-10-26T01:22-07:00"
  }
}

7.3 Response Example

HTTP/1.1 200 OK
Content-Type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "decision": true
}

7.4 Error Responses

The critical point here is that authorization "denial" and HTTP errors are entirely different things.

Status Code	Meaning
200 + `decision: false`	The authorization request was processed successfully; the result is "deny"
400	Malformed request
401	PEP is not authenticated to the PDP (e.g., invalid Bearer token)
403	PEP is not authorized to use the PDP
500	PDP internal error

In other words, 401 means "the PEP failed to authenticate to the PDP," while 200 + decision: false means "the PDP denied access based on policy." These two must not be confused.

7.5 Request ID

The PEP can assign a unique ID to requests via the X-Request-ID header. The PDP MUST include the same ID in the response. This is used for tracing and debugging in distributed systems.

8. Mapping to Authorization Models

The Authorization API does not assume a specific authorization model. It works with RBAC, ABAC, ReBAC, or any other model.

8.1 Usage with Each Authorization Model

Authorization Model	Subject Usage	Resource Usage	Context Usage
RBAC	Include role information in `properties`	Type and ID	Often unused
ABAC	Include attribute information in `properties`	Include attribute information in `properties`	Environmental info: time, location, etc.
ReBAC	Resolve relationships via ID	Include owner/relationship information in `properties`	Often unused

The flexibility of properties and context in the Authorization API enables this model-agnostic design.

9. Comparison with XACML

The Authorization API is not a successor to XACML, but addresses the same problem domain. Let's compare.

Comparison	XACML	AuthZEN Authorization API
Era	2003 (1.0), 2013 (3.0)	Published March 2026 (Standards Track)
Data Format	XML	JSON
Decision Values	Permit / Deny / NotApplicable / Indeterminate	true / false
Policy Language	XACML (XML-based) defined	Not defined (uses OPA, Cedar, etc.)
Batch Evaluation	Multiple Decision Profile	Access Evaluations API + evaluation semantics
Search	None (PDP-dependent)	Search APIs (Subject / Resource / Action)
Discovery	None	PDP Metadata (`.well-known/authzen-configuration`)
Transport	SOAP / HTTP	HTTPS (+ future gRPC)
Complexity	Very high	Intentionally simple
Adoption	Large enterprises / government	Designed for modern cloud-native environments

The biggest difference is that XACML standardized both the decision method (policy language) and the communication protocol, while AuthZEN deliberately avoids the decision method and standardizes only the communication protocol.

This is an intentional design decision. Given that OPA (Rego), Cedar, Topaz, and others already have mature policy languages, standardizing only the interface that connects PDPs to PEPs is more practical than also standardizing a policy language.

10. Security Considerations

The PEP-PDP communication is the very foundation of access control. If this communication is attacked, the authorization decisions themselves can be tampered with.

10.1 Communication Integrity and Confidentiality

TLS (HTTPS) is REQUIRED for PEP-PDP communication. The reasons are clear:

Integrity: An attacker modifying requests or responses could rewrite decision: false to true
Confidentiality: Requests contain "who is trying to access what," and leakage would expose internal structure and behavioral patterns

10.2 PEP Authentication

The PDP SHOULD authenticate the PEP. Without authentication, attackers could flood the PDP with requests for:

DoS attacks — Taking down the PDP and disabling all authorization decisions
Policy probing — Testing various request patterns to infer internal policies

Authentication methods are out of scope for the specification, but the following are cited:

mTLS
OAuth-based authentication (Bearer Token)
API keys

10.3 JSON Payload Considerations

The specification RECOMMENDS that JSON payloads follow the I-JSON profile (RFC 7493):

UTF-8 encoding (no invalid Unicode sequences)
Numeric values within IEEE 754 double-precision range
Unique member names after escape processing
Null-valued properties SHOULD be omitted

10.4 Trust Model

The specification states clearly: The PDP must trust the PEP.

This may seem surprising at first, but it makes sense when you think about it. The PEP is ultimately the one that allows or denies access, and no PDP can be effective if the PEP ignores its decisions. The PDP trusting the attribute values sent by the PEP is part of this trust relationship.

10.5 Response Integrity

The PDP MAY add digital signatures to responses. While TLS provides transport-layer protection, signatures provide application-layer non-repudiation and integrity verification. This is particularly valuable in environments with intermediate proxies.

10.6 Availability and DoS Countermeasures

If the PDP goes down, access control for the entire application ceases to function. The specification recommends the following defenses for PDPs:

Payload size limits
Rate limiting
Protection against invalid JSON and deeply nested JSON
Memory consumption limits

11. The Ecosystem in Practice

11.1 AuthZEN Working Group

AuthZEN (Authorization Zone) was established as a Working Group under the OpenID Foundation in 2023. Key contributors and companies:

Company	Contribution
Aserto	Specification editor (Omri Gazitt), Topaz PDP
Axiomatics	Specification editor (David Brossard), XACML/ALFA expertise
SGNL	Specification editor (Atul Tulshibagwale), contributor
Styra	Developer of OPA
AWS	Developer of Cedar
AuthZed	Developer of SpiceDB (Zanzibar)
Okta / Auth0	Developer of OpenFGA (ReBAC engine)

11.2 Interop Demo — Can You Really Swap PDPs?

"Standardize the API and PDPs become interchangeable" might sound idealistic. However, the AuthZEN WG has demonstrated this at Interop events.

At Identiverse 2024 (June 2024), a demo "Todo App" operated with a single PEP implementation that connected to 5+ different PDPs (Topaz, Axiomatics, OpenFGA, etc.) by simply switching endpoint URLs. It was proven that PDPs can be swapped without any code changes.

11.3 Relationship to Zero Trust Architecture

AuthZEN directly aligns with NIST SP 800-207 (Zero Trust Architecture). Zero Trust is not just about "not trusting the network boundary" — it also demands that "every request is individually authorized." AuthZEN provides exactly this "per-request authorization decision" through a standard API.

11.4 Current Status

Authorization API 1.0 was officially published as Standards Track on March 11, 2026. After progressing through the Implementer's Draft stage, all the APIs discussed in this article are defined:

Access Evaluation API (single evaluation)
Access Evaluations API (batch evaluation)
Search APIs (Subject / Resource / Action search)
PDP Metadata (discovery)

The specification also includes the establishment of IANA registries (PDP Metadata, PDP Capabilities, Well-Known URI authzen-configuration, URN sub-namespace authzen).

Conclusion

Key takeaways of AuthZEN Authorization API 1.0:

A standard API that separates authorization decisions (PDP) from enforcement (PEP). Externalize authorization logic from application code
The 4-tuple information model (Subject / Action / Resource / Context). Express "who," "what," "on which resource," and "under what circumstances" in simple JSON
Decision is boolean (true / false). Intentionally simpler than XACML's 4 possible values
Access Evaluations API for batch evaluation. Supports default values and 3 evaluation semantics (execute_all / deny_on_first_deny / permit_on_first_permit)
Search APIs for reverse lookups. Search "who can access," "what can be accessed," and "what actions are allowed" with pagination
PDP Metadata for discovery. Advertise PDP capabilities via .well-known/authzen-configuration
Does not define a policy language. Existing PDPs like OPA, Cedar, XACML, and Topaz work as-is. Only the API is standardized
HTTPS binding is mandatory. gRPC and others may be added in the future. PEP-PDP communication is protected with TLS + authentication
Authorization "denial" and HTTP errors are distinct. 200 + decision: false is a policy-based denial; 401 is a PEP authentication failure
Developed by the AuthZEN WG under the OpenID Foundation, officially published March 2026. Major authorization engine developers participated, and interoperability was demonstrated at Interop events

If XACML was "the XML of the authorization world," AuthZEN is "the JSON REST API of the authorization world." They do the same thing — connect PDPs and PEPs via a standard protocol — but AuthZEN has been redesigned for simplicity to match the modern development experience.

References

RBAC vs ABAC vs ReBAC: How to Choose and Implement Access Control Models

kt — Sun, 29 Mar 2026 12:02:44 +0000

Introduction

With the shift toward microservices and the widespread adoption of multi-tenant SaaS, requirements that cannot be expressed by traditional access control are rapidly increasing.

Have you ever heard the term Role Explosion?

RBAC alone is not enough. So, is ABAC the answer? Or ReBAC, which we hear a lot about lately? What exactly is the difference?

In this article, we will compare three access control models—RBAC, ABAC, and ReBAC—by looking at practical policy examples from actual products (AWS IAM, Kubernetes, Cedar, OpenFGA, and SpiceDB).

1. RBAC — Role-Based Access Control

1.1 The Basic Structure of RBAC

Let's start with RBAC. It is the simplest model and likely the first one everyone encounters.

What it does is straightforward: Assign roles to users, and assign permissions to roles. Users do not hold permissions directly; they acquire them through their roles.

The reasons this became so widespread are:

For a new user, you only need to assign one role.
If you ask, "Who has the Editor role?", you can get an answer immediately.
It is easy for non-engineers to understand.

1.2 NIST RBAC Model — The 4 Levels

Although I said it's just "assigning roles," RBAC actually has stages. NIST defines four levels.

Level	Name	Added Functionality	Example
Level 1	Flat RBAC	Basic structure: User → Role → Permission	Most applications fall here
Level 2	Hierarchical RBAC	Role inheritance. Higher roles include lower ones	A Manager also has Member permissions
Level 3	Constrained RBAC	Separation of Duties (SoD). Mutually exclusive roles	"Approver" and "Applicant" cannot be the same person
Level 4	Symmetric RBAC	Reverse lookup from Permission → Role	"Which roles have S3 write permissions?"

In practice, Levels 1 and 2 are the most common. Level 3 (Separation of Duties) is required in highly regulated fields like finance and healthcare.

1.3 RBAC in Real Products

Kubernetes RBAC

Kubernetes RBAC is essentially NIST Level 1 (Flat RBAC) with the addition of Namespace scoping. It uses four main resources.

# Permission definition (ClusterRole)
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

---
# Assignment to user (RoleBinding)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

A key characteristic of Kubernetes RBAC is that it is Allow-only (explicit denys do not exist). Permissions are purely additive; if multiple RoleBindings overlap, all allowed actions are combined.

The Role-Based Part of AWS IAM

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

This policy is attached to an IAM Role (e.g., S3-ReadWrite-Role), and users or services assume that role (AssumeRole). This is the RBAC portion.

However, AWS IAM is not pure RBAC. As we will see later, it also allows ABAC-like controls via the Condition block.

Azure RBAC

Azure provides over 120 built-in roles (Owner, Contributor, Reader, etc.) and features a hierarchical scope structure.

Roles assigned at a higher scope are inherited by lower scopes. This is different from NIST Level 2 role hierarchies; this is inheritance through the resource hierarchy. This concept of "permission inheritance via resource hierarchy" is actually quite close to ReBAC principles.

2. Role Explosion — The Limits of RBAC

2.1 What is Role Explosion?

RBAC works well at a small scale. However, as an organization or system grows, the number of roles increases exponentially. This is Role Explosion.

Let's look at five causes identified in Evolveum's documentation.

2.2 Cause 1: The Cartesian Product Effect

This is the most typical cause. When there are multiple "axes" determining access rights, the combinations multiply the number of roles.

For example, assume we have these three axes:

Job Function: Sales, Engineering, HR (3 types)
Location: Tokyo, Osaka, Fukuoka (3 locations)
Project: Project A, B, C (3 projects)

3 × 3 × 3 = 27 roles. Just three axes yield 27 roles.

In a real enterprise: 50 Job Functions × 20 Locations × 10 Projects = 10,000 roles. Managing 10,000 roles like "Sales-Tokyo-ProjA", "Sales-Tokyo-ProjB", "Sales-Osaka-ProjA"... is an administrative nightmare.

2.3 Cause 2: Atomization

In an attempt to make roles reusable, they are broken down into granular pieces. This creates a massive amount of fine-grained shared component roles like "Basic Access," "Email Usage," or "VPN Access." The total number of roles to manage actually increases.

2.4 Cause 3: The "One Role Per User" Problem

As cases of "this person needs special access" pile up, you end up with effectively as many roles as there are users. The very purpose of using roles is defeated.

2.5 Causes 4 & 5: Lack of Policy and Lifecycle Management

There are no criteria for creating roles, and obsolete roles are never deleted. As Evolveum points out: "Roles are created as needed, but rarely deleted."

2.6 The Core of Role Explosion

Ultimately, the root of role explosion is the limitation of RBAC's expressive power. RBAC can only express "Who → Role → Can do what". But in reality, questions like these arise:

When? — I only want to allow access during business hours.
From where? — I only want to allow access from the corporate network.
Whose resources? — Users should only be able to edit resources they own.
In what relationship? — Contents of a folder should inherit the parent folder's permissions.

When you try to express these in RBAC, you have to create a new role for every condition. That is why roles explode.

ABAC and ReBAC break through this limitation.

3. ABAC — Attribute-Based Access Control

3.1 The Basic Structure of ABAC

ABAC (Attribute-Based Access Control) solves RBAC's inability to answer "When? From where?". Instead of roles, access decisions are based on Attributes.

The attributes used for decisions fall into four categories.

Do you see the difference from RBAC? Actually, a "role" can be treated as just another attribute in ABAC (like role == "Manager").

The fundamental difference is that while RBAC requires static pre-classification ("assigning a role beforehand"), ABAC evaluates dynamically based on the facts (attributes) available at that exact moment.

Instead of creating a role for "Sales Manager in the Tokyo Office", you write a policy: department == "Sales" AND location == "Tokyo" AND role == "Manager". If a new branch opens or an external contractor temporarily joins, the policy remains unchanged; only the attribute values change.

3.2 XACML Architecture — The Reference Model for ABAC

When implementing ABAC, there is an unavoidable architectural concept to understand. It comes from XACML (eXtensible Access Control Markup Language). While XACML itself is XML-based and rarely used today, its core concepts of the PEP / PDP / PAP / PIP components live on in engines like OPA and Cedar.

Component	Role	Modern Implementation Examples
PEP	Intercepts the request and enforces the PDP's decision.	API Gateway, Middleware
PDP	Evaluates the policy and makes the Permit/Deny decision.	OPA, Cedar, AWS Verified Permissions
PAP	Creates and manages policies.	Admin UI, Git Repository
PIP	Fetches necessary attributes at runtime.	LDAP, Database, External APIs

3.3 RBAC vs ABAC — Eliminating Role Explosion

Let's solve the "50 Job Functions × 20 Locations × 10 Projects = 10,000 roles" problem using ABAC.

With RBAC: 10,000 roles are required.

With ABAC:

Policy 1:
  IF subject.department == resource.allowed_department
  AND subject.location == resource.allowed_location
  AND subject.project IN resource.allowed_projects
  THEN permit

It takes exactly one policy. Where RBAC needed 10,000 roles, ABAC handles it with a single policy. If new locations or projects are added, the policy does not need to change.

3.4 ABAC in Real Products

AWS IAM Conditions (Tag-Based ABAC)

AWS IAM implements ABAC through the Condition block in policies. Using tags as attributes is the typical pattern.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["ec2:StartInstances", "ec2:StopInstances"],
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "ec2:ResourceTag/Department": "${aws:PrincipalTag/Department}"
      }
    }
  }]
}

This policy reads: "Allow starting and stopping EC2 instances if the resource's Department tag matches the user's Department tag." Sales personnel can only operate Sales instances. Developers can only operate Developer instances. You only need one policy.

Even the official AWS documentation explicitly states: "ABAC requires fewer policies."

OPA / Rego

OPA (Open Policy Agent) is a CNCF Graduated project and policy engine (v1.14 as of March 2026). You write policies in a declarative language called Rego.

package httpapi.authz

default allow = false

# Users can read their own resources
allow = true {
    input.method == "GET"
    input.path = ["resources", resource_id]
    input.user == data.resources[resource_id].owner
}

# Managers can read their subordinates' resources
allow = true {
    input.method == "GET"
    input.path = ["resources", resource_id]
    data.resources[resource_id].owner == subordinate
    subordinate in data.reports_to[input.user]
}

# The admin role can do anything
allow = true {
    input.user_attributes.role == "admin"
}

OPA allows you to freely mix RBAC-like evaluations (role == "admin") and ABAC-like evaluations (owner == user) within policies. It is highly flexible, but because you can do almost anything, it can become chaotic if the team doesn't standardize how policies are written.

[!TIP]
When adopting OPA in production, structural best practices are essential. For example, using a common input JSON schema (user, method, path, resource, etc.) across all endpoints, and separating base common packages from microservice-specific packages using directory structures.

3.5 Challenges of ABAC

ABAC solves role explosion, but introduces new challenges.

Challenge	Description
Policy Complexity	As the combinations of attributes grow, the policies themselves become complex.
Auditing Difficulty	Answering "Can User X access Resource Y?" requires runtime attribute values.
Attribute Reliability (PIP)	The biggest weakness. If the PIP goes down or returns false data, the control system collapses.
Debugging Difficulty	It is difficult to trace exactly why a request was permitted or denied.

Particularly, reverse lookup queries like "Who has access to this resource?" are extremely difficult, which is a major weakness. In RBAC, you just list "users with this role." In ABAC, you would have to re-evaluate the attributes of every single user. You also must account for network latency to the microservice (PIP) fetching user info from the API Gateway (PEP).

4. ReBAC — Relationship-Based Access Control

4.1 Understanding ReBAC through Google Drive

While ABAC solved role explosion, it struggles with chains of relationships, such as "files within a folder should have the same permissions as the folder." Enter ReBAC (Relationship-Based Access Control), a model that determines access based on the relationships between objects.

The easiest way to understand this is by thinking of Google Drive.

Breaking down what is happening here:

Group Membership: Tanaka, Sato, and Suzuki are members of engineering-team.
Folder Permission: engineering-team is a viewer of the Engineering folder.
Permission Inheritance: Documents inside the Engineering folder inherit viewer permissions from the folder's viewers.
Individual Addition: Tanaka has been individually added as a viewer to the Meeting Notes.

This is neither RBAC nor ABAC. "I can see it because it's in the folder" and "I can see it because I'm in the group"—access rights are derived by traversing chains of relationships. This is ReBAC.

4.2 ReBAC Data Model — The Relation Tuple

At the core of ReBAC is a simple data model called the Relation Tuple, a format popularized by Google Zanzibar.

object#relation@user

It simply states: "A specific user (or user set) belongs to a specific relationship of a specific object."

Tuple	Meaning
`folder:eng#viewer@group:engineering#member`	Members of the `engineering` group are viewers of `folder:eng`.
`doc:design#parent@folder:eng`	The design doc is a child (belongs to parent) of `folder:eng`.
`group:engineering#member@user:tanaka`	Tanaka is a member of the `engineering` group.
`doc:minutes#viewer@user:tanaka`	Tanaka is a viewer of the minutes doc (individually added).

4.3 Permission Derivation — Graph Traversal

The most defining characteristic of ReBAC is that permissions are derived through graph traversal. Let's look at the process to answer "Can Tanaka view the design doc?".

The key point here is that the policy contains a defined rule stating "viewers of a folder are also viewers of the documents inside." Based on this rule, the engine traverses the graph to ultimately derive the permission.

4.4 Problems Solved by ReBAC

ReBAC naturally solves the problems that RBAC and ABAC struggle with.

Problem	RBAC	ABAC	ReBAC
Hierarchical Permission Inheritance Folder → File	Impossible (Flat structure)	Difficult (Hard to express hierarchy via attr)	Naturally Expressive Traverses `parent` relations
Reverse Lookups "Who can access this resource?"	Handled via role lists	Extremely difficult Requires full re-eval	Naturally Supported Reverse graph traversal
Sharing / Collaboration "Share this doc with Alice"	Requires creating a new role	Requires assigning attributes	Just add 1 tuple `doc:X#viewer@user:Alice`
Adapting to Org Changes Team A moves under Team B	Reassign roles entirely	Bulk attribute updates	Update 1 relation Repoint the `parent` relation

4.5 Google Zanzibar — Planetary-Scale ReBAC

Google Zanzibar is a system that implements ReBAC at a planetary scale. A paper on it was published at USENIX ATC in 2019, revealing it manages over 2 trillion Relation Tuples and processes 10 million requests per second with a p95 latency of less than 10ms.

[!CAUTION]
The biggest hurdle when implementing ReBAC in distributed systems is consistency dilemmas like the "New Enemy Problem." If a request to "access a resource" arrives before the information that "permissions were revoked" propagates, the revoked user might gain access. Zanzibar solves this using consistency tokens called Zookies (similar to timestamped Cookies).

I will do a deep dive into Zanzibar's architecture another time.

From here on, we will look at practical policy examples from OSS implementations heavily influenced by Zanzibar's design—SpiceDB and OpenFGA. By 2025–2026, both have significantly matured. The concept of Zookies has also been implemented in both as SpiceDB's ZedToken and OpenFGA's Consistency options.

5. ReBAC in Real Products

5.1 SpiceDB (Authzed)

SpiceDB (by Authzed) is the OSS implementation most faithful to Zanzibar's design. As of March 2026, it has reached v1.50, and recent additions focus on the AI agent era, such as LangChain integration (langchain-spicedb) and Postgres FDW-based SQL querying.

Models are defined using a schema language called .zed.

definition user {}

definition group {
    relation member: user | group#member
}

definition folder {
    relation parent: folder
    relation viewer: user | group#member
    relation editor: user | group#member

    permission view = viewer + editor + parent->view
    permission edit = editor + parent->edit
}

definition document {
    relation parent_folder: folder
    relation owner: user
    relation viewer: user | group#member
    relation editor: user | group#member

    permission view = viewer + editor + owner + parent_folder->view
    permission edit = editor + owner + parent_folder->edit
    permission delete = owner
}

Let's organize how to read this schema:

Syntax	Meaning	Example
`relation X: user`	Users can be assigned to relationship X.	`relation owner: user`
`permission Y = A + B`	Y is the union (OR) of A and B.	`view = viewer + editor`
`parent_folder->view`	Traverse the `parent_folder` relation and grab its `view`.	Inherit the folder's view perm.
`A & B`	Intersection (AND).	Requires both relations.
`A - B`	Exclusion (Subtract).	Subtract B from A.

SpiceDB Caveats (Conditional Relations)

SpiceDB supports Caveats, combining ReBAC with ABAC-style conditions.

caveat ip_allowlist(user_ip ipaddress, cidr string) {
    user_ip.in_cidr(cidr)
}

definition document {
    relation viewer: user with ip_allowlist
    permission view = viewer
}

This allows expressing conditional relationships like "Is a viewer, but only accessible from the internal corporate network." You can evaluate the ReBAC relationship graph and the ABAC attribute checks simultaneously.

5.2 OpenFGA (Auth0 / Okta)

OpenFGA is a Zanzibar-based OSS developed by Auth0 (Okta) and was promoted to a CNCF Incubating project in October 2025. As of March 2026, it is at v1.13. Contributors have grown by 49% year-over-year to over 6,200, showing strong momentum. Models are defined via DSL.

model
  schema 1.1

type user

type group
  relations
    define member: [user, group#member]

type folder
  relations
    define owner: [user]
    define viewer: [user, group#member]
    define parent: [folder]
    define can_view: viewer or owner or can_view from parent

type document
  relations
    define owner: [user]
    define editor: [user, group#member]
    define viewer: [user, group#member]
    define parent: [folder]
    define can_view: viewer or editor or owner or can_view from parent
    define can_edit: editor or owner
    define can_delete: owner

Summarizing the notational differences from SpiceDB:

Concept	SpiceDB	OpenFGA
Union	`A + B`	`A or B`
Graph Traversal	`parent->view`	`can_view from parent`
Type Constraints	`relation X: user \	group#member`
Intersection	`A & B`	`A and B`
Exclusion	`A - B`	`A but not B`

In terms of expressive power, SpiceDB has an edge, allowing complex models using intersection and exclusion. OpenFGA focuses on unions (or), prioritizing simplicity. The choice depends on your team's specific requirements.

5.3 Writing and Checking Relationship Tuples

Writing tuples and hitting the Check API follows a similar pattern in both engines.

6. Cedar — Integrating RBAC, ABAC, and ReBAC

6.1 What is Cedar?

Cedar is an open-source policy language developed by AWS (v4.9 as of March 2026). It serves as the backend for Amazon Verified Permissions. In June 2025, pricing for Verified Permissions was slashed by 97% ($5 per million requests), drastically lowering the barrier to entry. Furthermore, in March 2026, Amazon Bedrock AgentCore Policy went GA, establishing Cedar as an authorization language for AI Agents.

Cedar's design philosophy is "Integrating RBAC, ABAC, and ReBAC into a single language."

6.2 Cedar Policy Examples

Pattern 1: Pure RBAC

// Members of the Teachers role can submit and answer problems
permit (
    principal in Role::"Teachers",
    action in [
        Action::"submitProblem",
        Action::"answerProblem"
    ],
    resource
);

principal in Role::"Teachers" is the role membership check. Pure RBAC.

Pattern 2: Pure ABAC

// Non-confidential documents can be viewed by anyone
permit (
    principal,
    action == Action::"viewDocument",
    resource
)
when { resource.classification != "confidential" };

Checking resource attributes (classification) inside the when block. Pure ABAC.

Pattern 3: RBAC + ABAC Hybrid

// Allow viewing data if the user is in the viewDataRole,
// is not locked out, is using MFA,
// and the resource belongs to their Tenant
permit (
    principal in Role::"viewDataRole",
    action == Action::"viewData",
    resource
)
when {
    principal.account_lockout_flag == false &&
    context.uses_mfa == true &&
    resource in principal.Tenant
};

RBAC in the scope (in Role::"viewDataRole"), ABAC in when (MFA checks), and ReBAC in resource in principal.Tenant (traversing the tenant relationship)—three models integrated into a single policy.

Pattern 4: ReBAC — Resource Owner

// Owners can view the document
permit (
    principal,
    action == Action::"viewDocument",
    resource
)
when { principal == resource.owner };

// Users in the document's viewACL can view it,
// excluding private documents
permit (
    principal,
    action == Action::"viewDocument",
    resource
)
when { principal in resource.viewACL }
unless { resource.isPrivate };

principal in resource.viewACL traverses the entity graph to see if the user is in the document's Access Control List. This is the ReBAC portion.

6.3 Cedar's Design Principles

Cedar has three core design principles.

Principle	Description
Default Deny	All access is denied unless explicitly permitted by a `permit` policy.
Forbid overrides Permit	If even a single `forbid` policy matches, access is denied, regardless of how many `permit` policies match.
Formal Verification	The ability to answer questions like "Can the admin role access HR data?" via static analysis of the policies.

Formal verification is Cedar's unique strength. You can take a theorem (a property you want to prove), such as "Is there any path where an external user can view a document where isPrivate == true?", and run it through an SMT solver (Automated Theorem Prover). Being able to mathematically prove that unintended access cannot occur before deploying policies is a feature that OPA and SpiceDB do not natively have.

7. Comparison of the 3 Models

7.1 Selection Criteria

7.2 Detailed Comparison

Aspect	RBAC	ABAC	ReBAC
Decision Basis	Roles	Attributes (Subject, Resource, Env)	Relationships between objects
Granularity	Coarse (Role level)	Fine (Combinations of attributes)	Medium to Fine (Chains of relations)
Suitable Use Cases	Internal tools, simple IAM	Compliance, multi-attribute decisions	SaaS, document sharing, hierarchies
Implementation Complexity	Low	Medium to High	High
Performance	Fast (Simple lookups)	Medium (Fetching/evaluating attributes)	Watch out (Depends on graph depth)
Scalability Risks	Role Explosion	Policy Complexity	Massive graph size / Recursion depth
Reverse Lookup "Who has access?"	Easy	Extremely difficult	Supported (Graph Traversal)
Context Control "Time/Location limits"	Impossible	Excellent	Limited natively (Extendable via Caveats)
Auditability	Easy	Difficult	Medium (Long chains are hard to trace)
Representative Implementations	Kubernetes RBAC, Azure RBAC	OPA, AWS IAM Conditions	SpiceDB, OpenFGA, Ory Keto

7.3 Real-World Systems are Hybrids

In the real world of authorization systems, very few rely purely on a single model.

Service	RBAC	ABAC	ReBAC
AWS	IAM Roles / Policies	IAM Conditions / Tags	Verified Permissions (Cedar)
Google	Cloud IAM Roles	—	Zanzibar
Typical SaaS	Admin / Member / Viewer	IP Allowlist, MFA Req	Folder sharing, Workspaces

Almost everyone layers 2 or 3 models. So, what is the practical way to stack them?

RBAC as the baseline — Manage broad roles like Admin / Member / Viewer via RBAC. It's simple and universally understood.
Add ABAC for contextual control — Handle IP restrictions, MFA requirements, and business hour limitations via ABAC.
Introduce ReBAC for resource sharing and hierarchies — Use ReBAC for folder permission inheritance and document sharing.

You don't need to adopt ReBAC from day one. Starting with RBAC, and bringing in ABAC or ReBAC when you see signs of role explosion or complex sharing requirements, is the most practical path.

8. Industry Trends for 2025–2026

As of March 2026, the authorization space is moving rapidly. Here are the key trends to watch.

AI Agent authorization has become the largest theme. Cedar was adopted as the authorization language for AI agents in Amazon Bedrock AgentCore Policy. SpiceDB announced its LangChain integration. Oso released risk control features specifically for "Coding Agents." Cerbos is partnering with Tailscale to provide AI agent authorization. Nearly every player is accelerating support for AI agents.

Market consolidation is accelerating. CrowdStrike acquired SGNL for $740M (January 2026), and FusionAuth acquired Permify (November 2025). Authorization is transitioning from a standalone category to an integrated part of broader security platforms.

Standardization has matured. The OpenID AuthZEN Authorization API 1.0 was approved as a Final Specification in January 2026. With an industry standard for the communication protocol between PDP and PEP, swapping authorization engines or integrating multiple systems is becoming significantly easier.

Conclusion

What you want to achieve	Model to Choose	Products to Consider
Simple role management	RBAC	Kubernetes RBAC, AWS IAM
Fine-grained control via attributes & context	ABAC	OPA (v1.14), AWS IAM Conditions
Document sharing, hierarchical permissions	ReBAC	SpiceDB (v1.50), OpenFGA (v1.13, CNCF Incubating)
The whole package (RBAC + ABAC + ReBAC)	Hybrid	Cedar v4 (Amazon Verified Permissions)

Asking "which model is the strongest" is meaningless. You choose based on "what you want to control." Start with RBAC, add ABAC when roles multiply, and pull in ReBAC when you face resource sharing and hierarchies. You don't need to build the "everything" solution from the start.

WIMSE (Workload Identity in Multi System Environments) Deep Dive: Standardizing Identity Authentication for Microservices

kt — Tue, 24 Mar 2026 16:57:16 +0000

Introduction

Modern systems are wild. A user clicks a single button, and behind the scenes, ten or twenty independent workloads — microservices, containers, functions — fire off in sequence.

Take an e-commerce site. When someone hits "Place Order," here's what actually happens:

The API gateway picks up the incoming request
The order service calls the inventory service to check stock
The inventory service hits the financial system for a risk assessment before payment
Once risk assessment clears, the payment service kicks in
After payment goes through, the notification service fires off a confirmation email

Now here's the real question.

"What happens if you keep passing the user's original auth credentials through this entire request chain?"

The problems stack up fast:

An external token is flowing across the entire internal network: If that token gets stolen, every internal service is exposed
You lose track of who actually initiated the request: Intermediate services can't tell whether a request genuinely came from a user or if someone is hitting them directly
Any service can impersonate another: If the internal network gets compromised, a malicious workload can pretend to be a legitimate request and call other services
Token theft has a blast radius: If the external token leaks, it opens up unauthorized access to external resources too

This is exactly the kind of "inter-workload authentication" problem that the IETF is tackling with WIMSE (Workload Identity in Multi System Environments).

What Is WIMSE?

In one sentence:

WIMSE is a standardized architecture for how workloads — microservices, containers, and the like — authenticate each other and propagate security context.

It's defined in IETF Internet-Draft draft-ietf-wimse-arch-07 (March 2026 edition). The authors are security engineers from CyberArk, Zscaler, and Hochschule Bonn-Rhein-Sieg.

What WIMSE is trying to standardize:

How workloads authenticate each other: X.509 certificates? JWTs? What format?
How security context gets propagated: How do you pass user info, authorization info, and audit data to downstream services?
Cross-domain communication: When you need to talk to another organization's systems, how do you verify a workload is trustworthy?

Basically, it's an effort to take the scattered, bespoke implementations across different companies and projects, and unify them under one standard.

Three Core Concepts of WIMSE

The WIMSE architecture is built on three pillars.

1. Trust Domain

A trust domain is a group of systems that share common security policies and controls.

Think of it as "all the workloads within a given organization's environment." For example:

All microservices in Company A's production environment = one Trust Domain
All containers in Company B's dev environment = a different Trust Domain

Trust Domains are typically identified by a fully qualified domain name (FQDN) — like a.example.com or prod-us-west.mycompany.com. This makes them globally unique.

2. Workload Identifier

A workload identifier is an ID that uniquely identifies a single workload within a Trust Domain.

It takes the form of a URI and includes the Trust Domain. For example:

spiffe://a.example.com/paymentService
spiffe://a.example.com/orderService/v2
spiffe://prod-us-west.mycompany.com/ml-training-job-001

These often follow SPIFFE (Secure Production Identity Framework for Everyone), a spec that already has widespread adoption.

Key points:

The same identifier value issued under different Trust Domains is a completely different workload
An identifier can refer to a "logical workload" or a "specific workload instance" (like this particular container boot)
Identifiers must remain stable throughout the workload's lifetime

3. Workload Identity Credentials

Workload identity credentials are what a workload uses to prove "I am who I say I am."

There are two main formats:

X.509 Certificate

-----BEGIN CERTIFICATE-----
MIIDpzCCApugAwIBAgIBATANBgkqhkiG9w0BAQsFADAz...
...
-----END CERTIFICATE-----

The same certificate format used in TLS. When you're doing Mutual TLS (mTLS), this is what gets used. The client-side workload presents its certificate, and the server-side verifies it.

Strengths:

Already supported by a huge number of systems
Authentication completes at the TLS layer
Strong cryptographic binding to the key

JWT / Workload Identity Token

Here's what a JWT SVID (Workload Identity Token) payload looks like — similar to what gets issued by something like SPIRE:

{
  "iss": "https://a.example.com",
  "sub": "spiffe://a.example.com/orderService",
  "exp": 1710432000,
  "iat": 1710428400,
  "aud": "spiffe://a.example.com/paymentService"
}

This is an application-layer token. It usually travels in HTTP headers:

Authorization: Bearer eyJhbGc...

Strengths:

Easy to integrate when HTTP is your baseline
You can pack arbitrary attributes into the token
Great fit for microservices and API gateways

Important: These Are Not Bearer Tokens

WIMSE authentication tokens are not bearer tokens. A bearer token means "whoever holds this token can use it." WIMSE tokens are different — you need to prove you possess the private key that corresponds to the token's public component.

With mTLS, for instance, the private key is used to create a signature during the TLS handshake. With JWTs, the WIMSE Workload Proof Token (WPT) mechanism has the workload sign the request message with its private key, proving possession.

In other words:

Stolen token ≠ attacker can use it immediately

Private key is also required → proof of key possession is mandatory

This is one of WIMSE's real strengths.

WIMSE Scenarios: How It Works in Practice

Let's look at how WIMSE actually functions in a real microservice environment across a few scenarios.

Scenario 1: Basic Workload Identity System

Here's what's happening at each step:

(1) Distributing workload identity credentials

When a workload boots up, it first obtains its identity credential from the CA / Certificate Authority. This isn't a one-time thing — credentials get automatically renewed before they expire (auto rotation).

Short-lived credentials (say, valid for one hour) are used deliberately. If one gets stolen, the damage window is tiny.

(2) Request from the external client

A standard HTTPS request arrives from a user or application. The gateway handles it with normal Server Transport Authentication (STA).

(3) Gateway to workload

When the gateway forwards the request to Workload 1, it uses mTLS (Mutual TLS). The gateway presents its own identity credential to prove "I'm the gateway," and Workload 1 verifies the gateway in return.

(4) Workload-to-workload communication

Workload 1 needs something from Workload 3, so it makes a call. Again, Workload 1 uses its own identity credential to connect. Workload 3 verifies that credential — confirms "this is coming from Workload 1" — and only then processes the request.

Scenario 2: Security Context Propagation

So far we've only looked at authentication — workloads confirming each other's identities. But in the real world, you also need to pass along:

User info: "Who originally made this request?"
Authorization info: "What is this user allowed to do?"
Audit info: "When did what happen?"

This is called security context.

The important bits:

External token (a) stops at the gateway: It never enters the internal network
An internal context (c) is created instead: A short-lived internal token containing user info and other details
Each workload checks (c): They use it to determine what the user is allowed to do

A common pattern here is for the gateway to receive an OAuth 2.0 access token and convert it into an internal Transaction Token. I want to do a separate deep dive on Transaction Tokens, but the gist is: think of it as "cryptographic proof of authorization context for this request chain."

Scenario 3: Cross-Domain Communication

Scenarios 1 and 2 were both within a single Trust Domain. But in practice, you often need to talk to systems in different organizations or environments. How does that work?

Walking through the flow:

(1)-(2) Normal flow within Company A

A user request arrives, the gateway forwards it to Workload 1, passing along the context.

(3) Workload 1 needs to reach an external service

Workload 1 decides it needs to access Company B's service. But Company A's internal credentials won't cut it — it needs a token in a format Company B trusts.

So it asks Company A's token service for an externally-facing token, presenting its own identity credential (c). This lets the token service verify that Workload 1 is actually Workload 1.

(4)-(5) Cross-domain handshake

The token service, armed with Company A's auth info, reaches out to Company B's external token service: "Company A's Workload 1 wants to access your external service."

Company B's token service evaluates whether Company A's Workload 1 can be trusted, based on policy. If it checks out, it issues an external access token (a) that Workload 1 can use within Company B.

(6) Accessing the external service

Workload 1 uses the token from Company B to access Company B's service. From Company B's service perspective: "This token is in a format we trust — access granted."

Key takeaways:

Company A's workload credential (c) never reaches Company B
Instead, it gets converted into a token (a) that Company B understands
Workload 1's identity is preserved while being safely propagated across domains

[!TIP]
Fun fact: Egress Identity Generalization
When crossing trust boundaries, exposing granular instance-level IDs (like spiffe://a.example.com/order-service/pod-123) to the outside would leak internal scaling and deployment details to potential attackers. That's why the token service (or gateway) is recommended to generalize the ID to something like spiffe://a.example.com/order-service before sending it externally. This technique is also recommended in the RFC (draft-07, section 3.3.8.1).

WIMSE Implementation Formats

The WIMSE architecture defines what authentication should look like, but there are multiple ways to actually implement it.

Authentication Method 1: mTLS (Transport Layer)

Both sides present certificates during the TLS handshake.

Strengths:

Everything stays in the TLS layer
Wide existing support across systems

Weaknesses:

If an intermediate proxy or load balancer terminates the TLS session, you lose the end-to-end guarantee
Can get complicated in serverless or multi-tenant environments

Authentication Method 2: HTTP Signatures (Application Layer)

Sign the HTTP request itself. Defined in RFC 9421.

POST /api/order HTTP/1.1
Host: paymentservice.a.example.com
Content-Digest: sha-256=:...
Signature: sig1=:...:
Signature-Input: sig1=(...; created=1710428400; keyid="spiffe://a.example.com/orderService"; alg="rsa-pss-sha512")

{"order_id": 12345}

The signature covers:

HTTP method (POST)
Path (/api/order)
Headers
Hash of the body

Strengths:

Signatures survive proxy hops
Guarantees message integrity

Weaknesses:

Higher computational cost
More complex to implement than mTLS

Authentication Method 3: WIMSE Workload Proof Token (WPT)

A JWT-based mechanism that signs specific request information with a private key.

{
  "alg": "RS256",
  "typ": "WPT",
  "kid": "key-id-123"
}
{
  "iss": "spiffe://a.example.com",
  "sub": "spiffe://a.example.com/orderService",
  "aud": "spiffe://a.example.com/paymentService",
  "iat": 1710428400,
  "exp": 1710428700,
  "cnf": {
    "txn": "base64(hash(request_context))"
  }
}

The txn (transaction) claim contains a hash of the request's context info. This lets the receiver confirm the token was actually created for this specific request.

Sent via HTTP header:

Workload-Proof-Token: eyJhbGc...

Use Cases: Problems WIMSE Actually Solves

Let's get concrete about what WIMSE fixes in the real world.

Use Case 1: Credential Distribution at Workload Startup

A new container just spun up. It needs to know who it is.

Without WIMSE:

Developers manually stick secret keys in config files
Keys are long-lived (months, years)
Risk of keys getting baked into the container image

With WIMSE:

At startup, the container uses proof like a Kubernetes Projected Service Account Token
Requests an identity credential from the CA
Gets a short-lived certificate (minutes to hours) distributed automatically
Auto-renews before expiry

Use Case 2: Service Authentication

When Workload A calls Workload B, B wants to confirm "is this really Workload A?"

Without WIMSE:

Workload A's secret key lives in Workload B's config file
If multiple workloads are calling in, B needs to hold every single one of their secrets
Management becomes a nightmare

With WIMSE:

Workload A presents its short-lived identity credential
Workload B verifies it against the Trust Domain's CA
Policy check determines if the call is trusted

Use Case 3: Rich Audit Logging

When something goes wrong, you want complete traceability: "Which workload did what, from where?"

Without WIMSE:

Logs show something happened, but you can't verify whether a request was actually legitimate
Hard to distinguish between stolen-credential abuse and genuine access

With WIMSE:

Every request carries "from which workload, to which workload" information
Full traceability of workload-to-workload communication
By following the security context propagation, you can trace exactly how far a user's request traveled

Use Case 4: Delegation and Impersonation

User A sends a request. Workload 1 processes it and needs to ask other workloads to "do something on behalf of User A."

Without WIMSE:

Pass User A's token from Workload 1 to other workloads
Other workloads process it as "User A's token"
But you can't trace who actually initiated the request — was it Workload 1 or something else?

With WIMSE:

The security context carries a history: "original user is A, currently being processed by Workloads 1 and 2"
Audit logs give you the full picture: "Under User A's authority, across the Workload 1 → Workload 2 chain, here's exactly what happened"

Use Case 5: AI Agent-to-Agent Communication

This one was newly added in the latest spec (draft-ietf-wimse-arch-07), and it's squarely aimed at the current trend.

Autonomous AI agents are increasingly calling various workloads on behalf of users, and AI agents are delegating tasks to other AI agents, forming processing chains.

How WIMSE handles it:

AI agents are treated as a special case of "delegated workloads"
"Which AI agent, acting under which user's authority, is permitted to do what" gets cryptographically bound into tokens with scoped permissions
This prevents the "privilege escalation" scenario where AI-to-AI communication chains accidentally accumulate massive permissions — WIMSE's framework shuts that down completely

Security Considerations

WIMSE is powerful, but a sloppy implementation will create vulnerabilities instead of eliminating them. Here are the critical things to get right.

1. Traffic Interception

Without TLS, workload identity credentials flowing across the network can be intercepted.

Mitigations:

Always use TLS: Even for workload-to-workload communication within a Trust Domain, TLS is non-negotiable
mTLS is even better: Both sides verify each other
Use short-lived tokens: Even if stolen, the usable window is tiny

2. Information Disclosure

If security context or identity credentials contain sensitive information, unauthorized workloads could access it.

Mitigations:

Include only the minimum necessary information
Use reference pointers for sensitive data — don't send the actual data
Never output identity credentials in logs or error responses

3. Credential Theft

Even short-lived credentials can be weaponized if stolen.

Mitigations:

Protect private keys with Hardware Security Modules (HSMs) or TPMs
Isolate workloads from their private keys (separate memory pages, processes, etc.)
Keep lifetimes ultra-short (minutes)

4. Workload Compromise

If malicious code compromises a workload, its identity credential could be abused.

Mitigations:

Ensure only legitimate workloads can obtain identities (Attestation)
Detect tampering in workloads
Policy-based access control: Fine-grained restrictions like "this workload can only call this API"

Wrapping Up

WIMSE is a standardized architecture for tackling workload authentication in the microservice era, head-on.

The key points:

Trust Domain: A group of workloads sharing common security policies. Identified by FQDN.
Workload Identifier: A URI that uniquely identifies a single workload within a Trust Domain. Usually follows the SPIFFE ID format.
Workload Identity Credentials: The auth material a workload uses to prove its identity. Either X.509 certificates or JWT tokens. Cryptographic binding to a private key is mandatory.
Short-lived with auto-renewal: Credentials live for minutes to hours and get automatically rotated before they expire.
Security context propagation: User and authorization info gets converted from external formats (OAuth tokens) into internal formats (Transaction Tokens, etc.) and flows through each workload.
Cross-domain support: Even when communicating with systems in different organizations or environments, tokens get converted into trusted formats for safe interoperability.

The WIMSE spec is still an IETF Internet-Draft, but implementations (SPIFFE, Kubernetes, Istio, and others) are already well underway, with adoption across many cloud-native projects.

With microservice architectures being the default now, how you design workload-to-workload authentication is a strategic decision. Understanding WIMSE gives you a clearer picture of how to build microservice systems that are both secure and actually operable.

DEV Community: kt

xDS Deep Dive: Dissecting the "Nervous System" of the Service Mesh

Introduction

0. Prerequisites: Why use an "API" to push configurations?

Envoy and Protocol Buffers

1. The Despair of Static Configuration and the Awakening of xDS

2. The Core 5 Discovery Services

① LDS → Pointing to RDS

② RDS → Pointing to CDS

③ CDS → Pointing to EDS

④ Touching Down at EDS

⑤ Encrypting via SDS (mTLS) and Zero-Downtime Rotation

3. Surviving Broken Configs: The ACK/NACK Flow

4. Why We Need ADS (Aggregated Discovery Service)

The Fix: Bundling the Streams (ADS)

5. SotW vs Delta: Taming the Infinite Endpoint Explosion

The Limits of State of the World (SotW)

The Dawn of Incremental (Delta) xDS

6. Beyond Routing: Advanced xDS Use Cases

6.1 Dynamic Injection of Extensions (ECDS)

6.2 Streaming Runtime Variables (RTDS)

6.3 Building Proprietary Control Planes (go-control-plane) & Case Studies

6.4 The "Proxyless gRPC" Paradigm

Conclusion

References

Why Can We Use "Shorter" Keys?: Key Length vs Security Bits, the Real Story

1. Background: Symmetric vs Public Key Cryptography

2. "Key Length" and "Security Bits" Are Different Things

3. Each Cipher Has Different Attack "Shortcuts"

AES: No shortcuts, so key length = security bits

RSA: Integer factorization is a powerful shortcut

ECC: Has shortcuts, but they are far less efficient than RSA's

4. Equivalent Security Key Lengths (NIST SP 800-57)

5. RSA-2048 Gets Deprecated in 2030

NIST Transition Timeline

The Gap Between 112 and 128 Bits Is Not "Just 16"

6. Quantum Computers: Why Longer Keys Will Not Save You

Shor's Algorithm: Breaks Public Key Crypto at the Root

Grover's Algorithm: Halves Symmetric Crypto Security

7. Harvest Now, Decrypt Later: Today's Data, Broken Tomorrow

8. Post-Quantum Cryptography (PQC) Key Sizes

ML-KEM (FIPS 203): Key Encapsulation

ML-DSA (FIPS 204): Digital Signatures

SLH-DSA (FIPS 205): Hash-Based Signatures

Comparing Legacy Crypto and PQC Key Sizes

9. What to Do in 2026

Start with a Crypto Inventory

Build Crypto Agility into Your Architecture

Takeaways

References

Why I Built awesome-authorization: Mapping the World of Auth Engines onto a Single Page

Introduction

1. Setting the Stage: PEP vs. PDP

2. The Cambrian Explosion of Authorization Engines

3. You Can't Choose If You Don't Know the Models

RBAC: Managing by Roles

ABAC: Deciding by Attributes

ReBAC: Deciding by Relationships

So, Which One Should You Use?

4. AuthZEN: Standardizing the AuthZ API

Making OPA AuthZEN-Compatible

5. Why the Existing awesome-authorization Failed

6. Curating awesome-authorization

Conclusion

Related Articles

RFC 7523 Deep Dive: JWT Profile

Introduction

1. The Relationship Between RFC 7521 and 7523: The Box and Its Contents

2. The "Two Powerful Use Cases" Brought by JWT

Use Case 1: Using JWT as an "Authorization Grant" (The Secret of M2M Communication)

Flow Diagram

Use Case 2: Using JWT for "Client Authentication" (Goodbye, client_secret)

3. The Validation "Claims" You Must Never Compromise On

Conclusion

Resources

RFC 7636 Deep Dive: How PKCE Kills Authorization Code Interception Attacks

Introduction

Scoping It Out

1. The Problem: Auth Code Interception Attacks

1.1 The Gap Between Server-Side Strictness and Mobile OS Chaos

6.3 Building Proprietary Control Planes (`go-control-plane`) & Case Studies