DEV Community: RuntimeStack

How Passkeys Work: Why a Perfect Phishing Page Gets Nothing (Plus Lost Phones and the "Trap" Debate)

RuntimeStack — Wed, 28 Oct 2026 17:02:30 +0000

This login page is fake... and it's perfect. Your password would walk right in.

So how do you log in, when the site never gets a secret?

One analogy makes it click: a signet ring.

What passkeys replace

First, what passkeys replace: the password. Whoever has your password logs in as you, from anywhere.

The ring and the impression

Picture a signet ring and its wax impression. A passkey works the same way, with a pair of keys.

Passkey	Signet ring
private key	the ring: it stays on your devices, never with the site
public key	the impression: that's all the site stores
signature	the stamp
challenge	a blank card with a random number
site address (RP ID)	the engraving on the ring

Where the analogy breaks: a real ring can be copied from wax.

Creating a passkey

The site gets the impression, the public key, and that's ALL it stores.

So if that server gets breached, the attacker gets a pile of impressions.

But if the site never gets anything secret... how does it know it's really you?

Signing in

The site sends a challenge: a blank card with a random number it's never sent before.

Your device stamps it with the ring. That stamp is the signature.

The site checks the stamp against the impression on file. Match? You're in.

runtimebank.com  --  blank card: 8f3a…c91  -->  your phone
runtimebank.com  <--  signature (the stamp)  --  your phone
checked against the public key  ->  you're in
secrets sent: 0

Why the fake page gets nothing

Every ring is engraved with the site it was made for: runtimebank.com.

And your browser, not the ring, checks the real address before it brings one out.

The fake site is runtimebank-secure.com. One word off, so no ring matches... so there's nothing to offer. Your passkey can't be phished.

And even if a stamp somehow got made there, the browser writes the address onto the card first... so it carries the fake address, and the real site rejects it.

origin:   runtimebank-secure.com
rings:    runtimebank.com ≠   shop.com ≠   mail.com ≠
passkey secrets sent: 0

Who shows the popup?

So your browser picks the ring. But who's holding them, and who's showing you that popup?

That popup is your browser or phone, not the website.

The website asks your browser, and your browser asks your passkey provider. That's whatever holds your rings: iCloud Keychain, Google Password Manager, 1Password, Bitwarden, or a hardware key.

Signing in on a laptop with your phone? You scan a QR code, and Bluetooth checks it's nearby.

Lost phone: synced vs device-bound

But here's the catch with a ring that lives on one phone. Lose the phone, lose the ring.

So passkeys made on a phone or in a password manager are usually synced. Your provider copies them, end-to-end encrypted, to your other devices.

Phone gone? Sign in to your provider on a new one, and your rings come back.

That makes your provider account the master key, so protect it well.

A hardware key is device-bound, with no copies. So register two... and keep one in a drawer.

![Lost phone: the provider restores end-to-end encrypted passkeys to a new phone; the provider account is the master key; a hardware key is device-bound]

Face, fingerprint, PIN

Your face or PIN unlocks the ring box, right there on the device.

Your fingerprint and face never leave the phone, and the site never sees them.

Stolen phone

A leaked password works for anyone, from anywhere, without ever touching your phone. So the phone itself is what to protect.

Here's what to actually do: a long passcode, not four digits, and remote lock and wipe turned on.

The password fallback

One more honest catch... most sites still keep a password or an email reset as a backup.

That's a spare key under the mat, and attackers always check the mat.

So if a site where you use a passkey suddenly asks for your password... stop. Assume it's the fake page, and type the address yourself.

And if a site lets you remove the password, do it.

Lock-in

And switching providers? The FIDO Alliance, the group behind passkeys, is rolling out Credential Exchange. It's a standard way to move passkeys between managers, encrypted.

Are passkeys a trap?

The viral argument is about one optional feature, attestation.

A site can ask for proof of what made your passkey, signed by the maker.

Now the fact check. Synced passkeys from Apple, Google, 1Password and Bitwarden send no signed proof at all.

So it's worth watching... but a consumer site that required it today would lock out almost everyone.

Recap

Your private key is the ring. It stays on your devices, never with the site.

The public key is the impression. That's all the site stores.

The honest part: lock your phone down, and never type a password where your passkey should be.

That fake page? Your password would've walked right in. Your passkey never even showed up.

What's still stopping you from turning passkeys on? Tell me in the comments.

More in this series: JOSE and JWT, PKCE, Device Flow.

This is the written version of a 7-minute animated explainer on RuntimeStack. Sources: passkeys.dev: What are passkeys?, passkeys.dev: Terminology, W3C Web Authentication Level 3, FIDO Alliance: Passkeys, FIDO Alliance: Credential Exchange specifications, "Passkeys are a trap" (nonfunctional), Scott Helme: "Passkeys are not a trap".

How AI Reverse Engineering Really Works: REA, Ghidra and angr on One 17-Byte Function

RuntimeStack — Sun, 25 Oct 2026 10:58:22 +0000

AI doesn't read machine code.

So what's it actually reading? And those viral Adobe clones? Their builder says they never used REA.

There are two ways to copy an app, like those Adobe clones: watch it from the outside, or open it up. We'll open one up, one real function at a time, and see exactly where the AI comes in. Plus the two places it quietly breaks.

Compiling is baking

Think of compiling as baking.

Your source code is the recipe. The compiler bakes it into a binary.

Comments never make it into the cake. And for a release, most apps strip out the function names too.

Here's the recipe we'll bake:

int price(int qty) {
    if (qty > 10)
        return qty * 90;
    return qty * 100;
}

gcc -O1 -o app main.c
strip app
nm app
# nm: app: no symbols

So you ship the cake. Not the recipe. You can't get the recipe back. But a good food lab gets surprisingly close.

Inside the binary: seventeen bytes

So let's open the cake. This is that exact function, from the stripped app.

The whole thing is seventeen bytes:

f3 0f 1e fa 83 ff 0a 7f 04 6b c7 64 c3 6b c7 5a c3

To you, it's noise. To the CPU, it's a list of instructions. The only question is: where does each instruction start?

The disassembler: bytes to assembly

A disassembler maps them to instructions.

The first four are a security marker. Skip those. 83 ff 0a: compare the input with 10. 7f 04: if it's bigger, jump. Otherwise multiply by a hundred, and after the jump, by ninety.

$ objdump -d app
1169:  f3 0f 1e fa   endbr64                  # landing marker, skip
116d:  83 ff 0a      cmp    $0xa,%edi         # compare qty with 10
1170:  7f 04         jg     1176              # if bigger, jump
1172:  6b c7 64      imul   $0x64,%edi,%eax   # times 100
1175:  c3            ret
1176:  6b c7 5a      imul   $0x5a,%edi,%eax   # times 90
1179:  c3            ret

The decompiler: assembly to C

Assembly's still slow to read. So, tool two: a decompiler.

The famous one is Ghidra, from the NSA. Here we'll use another free one, called angr. Same idea.

First, each instruction becomes tiny steps, every side effect spelled out. Ghidra calls it P-code. That one compare? Ten steps:

unique[78b00:4] = EDI
CF = unique[78b00:4] < 0xa
OF = sborrow(unique[78b00:4], 0xa)
unique[78d00:4] = unique[78b00:4] - 0xa
SF = unique[78d00:4] s< 0x0
ZF = unique[78d00:4] == 0x0
unique[58300:4] = unique[78d00:4] & 0xff
unique[58400:1] = popcount(unique[58300:4])
unique[58500:1] = unique[58400:1] & 0x1
PF = unique[58500:1] == 0x0

Then it throws away the ones nothing uses. Then it spots the patterns. Compare plus jump is an if, and out comes C:

unsigned int sub_401169(int a0)
{
    if (a0 > 10)
        return a0 * 90;
    return a0 * 100;
}

What came back: the logic, but no names

Look at what came back, though.

The logic is exactly right. But angr calls the function sub_401169. The input is called a0. And nothing says why 90, and not 100.

Every ingredient, every step. Not one note from the recipe.

Now picture thousands of functions like that.

What the AI adds: the chef's guesses

So if the tools did the hard part, what's the AI for?

Reading. The model has seen millions of functions that look a lot like this one. So it renames a0 to qty, the function to price, and 90 to a bulk discount:

- unsigned int sub_401169(int a0)
+ int price(int qty)
  {
-     if (a0 > 10)
-         return a0 * 90;
-     return a0 * 100;
+     if (qty > 10)
+         return qty * 90;   // bulk discount?
+     return qty * 100;
  }

Those names are guesses. Good ones. But guesses.

In the kitchen, that's the chef reading the lab report and saying: brown butter.

So what is REA?

REA is an MCP server: a standard plug that lets an agent like Claude Code drive those tools.

agent  <-> MCP <->  REA  <->  Ghidra | Hopper | IDA

For native apps, it drives Ghidra, Hopper or IDA. It doesn't ship a decompiler of its own.

The analysis runs locally. The model, cloud or local, only sees the findings REA sends back.

Rebuild, test, repeat

But a guess isn't proof. So the agent rebuilds the function from its renamed copy:

int price(int qty) {
    if (qty >= 10)        // bulk = 10 or more?
        return qty * 90;
    return qty * 100;
}

Then it runs both, the original and the rebuild, on the same inputs:

Input	Original	Rebuild
5	500	500 ✓
10	1000	900 ✗

Bulk discount sounded like ten or more, so it wrote that. Its own guess leaked in.

The test catches it. Decompile, guess, rebuild, test, repeat.

= 10, run next to the original: input 10 gives 1000 vs 900" width="800" height="450">

Where it breaks, part one: obfuscation

Decompilers work because compilers write code in familiar patterns. Protectors break them on purpose.

VMProtect turns your code into bytecode for a made-up CPU, and ships the interpreter inside the app.

It's not a cake anymore. It's a cake baked inside another cake.

Where it breaks, part two: the agent's own report

The second place is quieter. It's the agent's own report. Picture a summary that says: tested every edge case, matches the original. (The video labels this report as illustrative.)

Did it? The log says five and eleven. That's it:

$ cat test.log
5  -> 500 ✓
11 -> 990 ✓
# no line for 10: it never ran

A summary isn't evidence. The test log is. So you still steer, and you ask for the edge cases.

Is it worth the tokens?

Not always. In one informal test, a plain agent working from screenshots finished first. And its copy was only slightly behind. Nobody's published a token count yet.

If it's all visible on screen, watching is often enough.

The Adobe clones: they watched

According to their builder, that's exactly what the Adobe clones did. They watched. Public specs and the apps' visible behaviour. No decompiling, by their own rules.

That's the idea behind clean-room design: build from the spec, never from the original code.

In kitchen terms? They tasted the cake in the shop, and never sent it to the lab.

Is it legal?

Decompiling the original and shipping what you find is a much riskier legal story.

REA's own readme limits it to lawful research, interoperability, and software you're authorized to examine.

This isn't legal advice, but know which kitchen you're cooking in.

Recap

Kitchen	Reverse engineering
the cake	the binary
reading its ingredients, exactly	the disassembler
rebuilding the steps, but not the names	the decompiler
the chef, guessing the names and the why	the AI
the taste test	the tests: the only part you should really trust

And for the Adobe clones: would you have watched, or opened it up? Tell me in the comments.

More in this series: AI agent sandboxing, reward hacking, Pi 1.0 and Pi Durable.

This is the written version of a 7-minute animated explainer on RuntimeStack. Sources: REA README, MindStudio blog, Ghidra README, Ghidra (Wikipedia), P-code reference, Springer chapter, pypcode, angr decompiler, KuCoin news: ArtCraft founder and REA, innFactory: AI rebuilt Photoshop, PetaPixel, TweakTown, Clean room design, x86 reference, ENDBR64, back.engineering blog.

AI Agent Identity Explained: SPIFFE, SPIRE and OPA Instead of API Keys

RuntimeStack — Sat, 24 Oct 2026 23:07:00 +0000

Many AI agents still run on a static API key: long-lived, and hard to rotate.

It's a bearer secret, not bound to anything. Whoever copies it can act as your agent.

The fix is a passport that expires within the hour.

SPIFFE, SPIRE, SVIDs, OPA, Rego. Alphabet soup. One airport analogy makes it click, plus why a perfect ID won't stop your agent wiping a database.

Two questions: who are you, and may you board?

An airport asks two questions: who are you, and may you board?

SPIFFE and SPIRE issue the passport that answers the first. OPA runs the gate.

SPIFFE is the standard. SPIRE implements it; meshes like Istio issue SPIFFE IDs too.

The SPIFFE ID: the name in the passport

Your agent's name is a SPIFFE ID:

spiffe://example.org/agents/billing
         └─────────┘└─────────────┘
         trust domain     path

First, the trust domain: the trust root, like the country that issues a passport. Then the path, naming this workload.

The SVID: the passport

So what makes a name proof? A signature.

Signed, it becomes an SVID: a SPIFFE Verifiable Identity Document. It comes in two forms:

SVID type	Used for	Lifetime in the video
X.509 certificate	mTLS	1 hour
JWT	bearer token	5 minutes

A JWT-SVID looks like any other JWT:

eyJhbGciOiJFUzI1NiJ9.eyJzdWIiOiJzcGlmZmU6Ly9....MEUCIQDx3k...

Prefer the certificate: its private key never leaves the agent. Stolen JWTs replay until expiry.

SPIRE and secret zero: the passport office

But how does the agent get a passport without a password?

You'd need a secret to get a secret: secret zero. SPIRE solves it in two steps.

The SPIRE Server is the passport office. The SPIRE Agent is a desk on every node. Careful: that's not your AI agent.

Step one: the node proves itself with platform evidence, like a cloud instance document.

Workload attestation: the fingerprint check

Step two: your AI agent asks its local desk for a passport. No credentials.

The desk asks the kernel who's calling, then looks up that process: its container, its service account. Those are its selectors:

k8s:ns:agents
k8s:container-image:…/billing-agent
k8s:sa:billing-agent

Those selectors match an entry you registered, like a fingerprint on file, and the SVID streams back. The entry is something you create up front:

spire-server entry create \
    -parentID spiffe://example.org/spire/agent/k8s_psat/demo-cluster/node-1 \
    -spiffeID spiffe://example.org/agents/billing \
    -selector k8s:ns:agents -selector k8s:sa:billing-agent

Unlike a real passport, it's short-lived and auto-rotates before it expires.

mTLS: passport control in both directions

Now the agent calls a tool, a payments API, over mutual TLS (mTLS).

Each side checks the other's stamp against its trust bundle: passport control, in both directions.

No API key anywhere, at least for internal calls. So you're safe, right?

The catch: identity isn't permission

A prompt injection tells the billing agent to clean up. It sends this:

DELETE /customers HTTP/1.1

HTTP/1.1 200 OK

And the tool happily replies: 200 OK.

SPIFFE proved who called. Deciding what it may do was never SPIFFE's job.

OPA: the gate

That's the gate's job. A popular one: OPA, the Open Policy Agent.

OPA checks the request against a Rego policy. Billing may read invoices. DELETE? Denied.

default allow := false

allow if {
  input.principal == "spiffe://example.org/agents/billing"
  input.method == "GET"
  startswith(input.path, "/invoices")
}

default allow := false is the important line: anything not explicitly allowed is denied. OPA returns the decision. Envoy enforces it, usually with a 403 Forbidden.

The twist: agents act for humans

Agents usually act for a human, so the gate also checks a signed permission slip.

The IETF's September 2026 AI-agent draft splits it the same way: SPIFFE-style IDs for agents, OAuth token exchange for users. Policy? Out of scope: that's a job for OPA.

Recap

Airport	Real thing
the name in the passport	SPIFFE ID
the passport	SVID
the passport office	SPIRE Server
a desk on every node	SPIRE Agent
the fingerprint check	attestation
passport control, both ways	mTLS + trust bundle
the gate, on every single call	OPA + Rego

Your agent never needed a forever key. It needed a passport, and a gate that denies by default.

What does your agent use: API key, OAuth, or SPIFFE? Tell me in the comments.

More in this series: AI agent sandboxing, Pi 1.0 and Pi Durable, AI reverse engineering.

This is the written version of a 4-minute animated explainer on RuntimeStack. Sources: SPIFFE ID spec, X509-SVID spec, JWT-SVID spec, SPIFFE Workload API, SPIRE concepts, SPIRE Server, CNCF: SPIFFE and SPIRE graduate, Istio security, OPA docs, OPA-Envoy, Rego, Envoy attribute context, IETF WIMSE AIMS draft, IETF AI agent auth draft, Red Hat: zero-trust identity for AI agents, OWASP LLM01 Prompt Injection.

Is a Docker Container a Sandbox? AI Agent Sandboxing Explained: seccomp, gVisor, Firecracker, Kata and Wasm

RuntimeStack — Thu, 22 Oct 2026 19:08:26 +0000

When headlines say an AI agent "escaped its sandbox"... what wall did it pass?

Some sandboxes are walls. Some are just curtains.

Containers, seccomp, gVisor, Firecracker, Kata, WebAssembly, V8 isolates. They all sort into one ladder, with one question:

How much of the host kernel can the code reach?

And there's one door none of them close. We'll get there.

Why sandbox at all?

Your agent writes code, then runs it. But who really wrote it?

Treat agent code like code from a stranger. Because it might be.

The building and its plumbing: the kernel

Here's the building. Every program lives in its own apartment.

Down in the basement is the kernel: the plumbing every apartment shares.

Open a file, send a packet? You ask the kernel. That request is a syscall. Linux has hundreds of them, and every one is a pipe into the basement.

One bug in that plumbing, and a tenant can flood the whole building.

Containers: a locked room

So what's a container? A locked room in this same building.

Namespaces control what you can see: your own processes, files and network.
cgroups control how much you can use: CPU, memory, how many processes.

On a Mac or Windows, Docker runs a Linux VM, so the shared kernel is that VM's.

seccomp: the list of taps

Next layer: seccomp, a list of taps you're allowed to turn.

It's a tiny filter program that checks each syscall's number and arguments, and answers allow, errno or kill:

read       allow
write      allow
mount      blocked
ptrace     blocked
kexec_load blocked
openat     allow

But the kernel's own docs say it plainly: syscall filtering isn't a sandbox.

Is a Docker container a sandbox?

Not on its own.

In January 2024, a bug in runc, the tool that starts containers, let them reach the host's files. That's CVE-2024-21626. A full container escape.

And that wasn't even the kernel.

The classic own-goal: docker.sock

Mounting the Docker socket into the container:

docker run -v /var/run/docker.sock:/var/run/docker.sock agent

Whoever controls that socket controls the Docker daemon, and the daemon runs as root.

Volumes only, a separate network? Better. But it's still the same kernel.

So the people saying "if it escaped, it wasn't a sandbox"? They're right. If it shares a kernel, it's a curtain, not a wall.

gVisor: hire a concierge

So how do you keep code away from the pipes? Hire a concierge.

That's gVisor: its Sentry is a kernel, written in Go, running in user space. Your code makes a syscall, and the Sentry answers it itself.

It only makes a small, filtered set of host calls. Files go through a helper, the Gofer.

What does the concierge cost? Every syscall takes a detour, so syscall-heavy work slows down. And some programs expect plumbing the Sentry doesn't provide, so compatibility drops.

MicroVMs: your own tiny house

Still nervous about sharing a building? Then move out. Get your own tiny house.

A microVM runs your code on its own guest kernel, with its own plumbing. Firecracker is the VMM, the virtual machine monitor, built on KVM, the hypervisor inside Linux.

The house still has one metered service line into the building's basement: KVM. To escape, code has to get past its own kernel, and then break the VMM or KVM too.

Share a folder in, though, and you've cut a door in that wall.

Isn't a VM slow?

Firecracker's spec says the guest reaches init within 125 ms:

[0.000] InstanceStart
[0.003] guest kernel boots...
[0.125] /sbin/init
/dev/kvm: required

And the VMM itself adds at most about 5 MB of memory. Low-powered machine? The overhead is tiny, if it has KVM. The guest's own memory is the real bill.

Many sandboxes at once? Fine. They only talk to each other if you wire up a network.

That's why platforms like E2B describe a sandbox as a Linux VM made on demand. Even Docker's own agent product, Docker Sandboxes, runs each agent in its own microVM.

Kata Containers: a container's front door

But your tools speak containers, not VMs. So Kata puts a lightweight VM behind the container interface.

Same front door as an apartment, but a tiny house behind it. Your container tools never know they're running a VM.

WebAssembly and V8 isolates: the glovebox

Now flip it. Picture a sealed glovebox in the lobby. You work through the gloves you're handed, and nothing else.

A WebAssembly module's memory is bounds-checked. Step outside it, and the module traps: no pipes to the basement at all.

Same idea for JavaScript. V8 is Chrome's JavaScript engine, and an isolate is one sealed instance of it. It gets its own memory and only the APIs it's handed. Cloudflare Workers run thousands per process. Cloudflare says they start about a hundred times faster than a containerized Node process, using a tenth of the memory.

The glovebox catch

So the glovebox is the strongest rung, right? Not so fast.

Now the wall is the runtime itself, and runtimes have bugs. Break one, and you're a normal host process. In 2024, V8's team said even its newest sandbox wasn't yet a strong boundary.

Side channels, timing the shared CPU, still work too. Even between tiny houses.

The ladder

Sorted by how much host kernel the code can reach:

Rung	Analogy	What the code reaches
Container + seccomp	locked room, list of taps	the shared kernel, filtered by seccomp
gVisor	the concierge	the Sentry, which makes a small, filtered set of host calls
Firecracker microVM / Kata	your own tiny house	only its VMM and the KVM under it
Wasm / V8 isolates	the glovebox	nothing but their imports

And every wall here is software, so any rung can have bugs.

Which rung should you pick?

Your own agent on your own repo? A container-level sandbox is the floor. An injected command's easy win is your network, not a kernel exploit, and the next rule shuts that.
Running strangers' code, or anything multi-tenant? Give it its own kernel: gVisor or a microVM.

The door no rung closes: the network

So what if your agent sat in a perfect microVM, holding real API keys, with open internet?

Without network isolation, one injected instruction and one outbound request, and your keys are gone.

Every wall held. The code just walked out the front door.

Egress: the mailroom

Allowlist destinations: a mailroom that only delivers to addresses on the list.

ALLOWLIST
  pypi.org
  github.com
everything else: DENIED

Can it still leak? If it reads your data and can reach an allowed host, yes. So keep that list as short as the job allows, and lock down DNS too.

Secrets: keep the master keys out of the house

The sandbox gets a placeholder, and the mailroom attaches the real credential on the way out:

inside the sandbox:   Authorization: Bearer PLACEHOLDER
after the mailroom:   Authorization: Bearer sk-live-...

Injected code can read that placeholder all day. Off the box, it's worthless. It can still use the key through the mailroom, so keep the allowlist short.

Agent code is untrusted on your laptop too: review it, or run it sandboxed.

A real example: Claude Code's sandbox

Does anyone build it this way? Here's one example: Claude Code's sandbox.

It's off by default. You turn it on with:

/sandbox

On Linux it uses bubblewrap, the same namespaces trick a container uses. On macOS, Seatbelt, Apple's built-in sandbox.

Commands get no direct route out. A host proxy checks every domain against an allowlist that starts empty. Set up masking, and the proxy swaps a placeholder key for the real one.

Its own docs say it reduces risk, but isn't a complete isolation boundary. For strangers' code, climb.

Recap

One building. The kernel is the shared plumbing. A container is a locked room. seccomp is the list of taps. gVisor is the concierge. A microVM is your own tiny house, and Kata gives it a container's front door. Wasm and isolates are the glovebox. And the mailroom guards the one door no wall closes.

So did that agent escape its sandbox? Ask two things: was it a wall, or a curtain? And which door was open?

Which rung is your agent on right now? Tell me in the comments.

More in this series: AI agent identity with SPIFFE and SPIRE, Pi 1.0 and Pi Durable, AI reverse engineering.

This is the written version of a 10-minute animated explainer on RuntimeStack. Sources: syscalls(2), namespaces(7), cgroups(7), seccomp BPF, Red Hat RHSB-2024-001, CVE-2024-21626, Dirty Pipe, Docker Engine security, Docker Sandboxes architecture, Docker Desktop VMM, gVisor docs, gVisor platforms, Firecracker README, Firecracker specification, Firecracker getting started, Firecracker (NSDI '20), Kata Containers, Kata hypervisors, WebAssembly security, How Workers works, Workers security model, The V8 Sandbox, Claude Code sandboxing, E2B docs, OWASP LLM01.

You've Never Actually Sent a JWT (JOSE, JWS, JWE, JWA and JWK Explained)

RuntimeStack — Thu, 22 Oct 2026 17:51:39 +0000

You've used JWTs a hundred times. But here's the thing: you've probably never actually sent one.

That token in your Authorization header? Technically, it's a JWS.

JOSE, JWS, JWE, JWA, JWK, JWT. It's alphabet soup. Here's one analogy that makes all of it click.

JOSE: the shipping company

Start with JOSE: JSON Object Signing and Encryption. It's not a token. It's a family of IETF standards.

Think of it as a shipping company, with rules for how packages get sealed, locked and delivered.

JWT: the letter

A JWT isn't a container at all. It's the letter inside: a set of claims.

{
  "iss": "auth.example.com",
  "sub": "user_42",
  "aud": "orders-api",
  "exp": 1767225600
}

Who issued it. Who it's about. Who it's for. And when it expires.

But a letter on its own isn't secure. It needs packaging.

JWS: the sealed envelope

Option one: JWS, JSON Web Signature. Picture a clear envelope with a tamper-proof wax seal.

It has three parts, separated by dots: a header that names the algorithm, the payload, and the signature.

eyJhbGciOiJ...  .  eyJzdWIiOiI...  .  SflKxwRJSMe...
    header            payload           signature

The seal proves who sent it, and that nobody changed a single byte.

The gotcha: the envelope is clear

The payload is just Base64URL encoded. Anyone can decode it:

echo 'eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ==' | base64 -d   # Base64URL drops the = padding; add it back for base64
# {"sub":"1234567890","name":"John Doe","iat":1516239022}

So never put secrets inside a signed JWT.

JWE: the locked box

Need privacy? Option two: JWE, JSON Web Encryption. This is a locked metal box, with five parts:

A header
An encrypted key
An initialization vector
The ciphertext
An authentication tag

Only the recipient, holding the right key, can open it.

JWA: the toolbox

So how do you seal or lock it? That's JWA, JSON Web Algorithms. The toolbox.

Signing: HS256, RS256 and ES256
Encryption: RSA-OAEP and A256GCM

The alg field in the header tells the receiver which tool was used.

JWK and JWKS: the keys

And the keys themselves? That's JWK, JSON Web Key. Instead of PEM files, a key is just JSON: a key type (kty), what it's used for (use), a key ID called kid, and the key material.

Put several keys in an array, and you get a JWKS. Auth servers publish it at /.well-known/jwks.json.

Your API reads the kid from the token header, fetches the matching public key, and verifies the signature. That's how keys rotate without redeploying anything.

Nested JWT: both at once

And yes, you can combine them. Sign a JWT, then encrypt the result. That's a nested JWT: a sealed envelope, inside a locked box.

Recap

	Analogy
JOSE	the shipping company	the family of standards
JWT	the letter	the claims
JWS	the sealed envelope	signed, readable by anyone
JWE	the locked box	encrypted, private
JWA	the toolbox	the algorithms
JWK	the keys	keys as JSON

Next time someone says JWT, you can say: well, actually... it's a JWS.

Which of these acronyms confused you the most? Tell me in the comments.

This is the written version of a 3-minute animated explainer on RuntimeStack. Sources: RFC 7519 (JWT), RFC 7515 (JWS), RFC 7516 (JWE).