Why Stow Moved to Asymmetric RS256/ES256 Key Verification

There are two ways to verify a JWT: look up a shared secret and check the signature with it, or fetch a public key from a JWKS endpoint and verify the signature cryptographically. The first approach is simpler. The second approach is fundamentally more secure — and it's what Stow uses. Here's why that distinction matters for AI platform security.

Symmetric vs. Asymmetric Token Verification

The Specific Risk Asymmetric Verification Eliminates

With symmetric verification, the shared secret has to live somewhere accessible to the verification code. On a server, that usually means an environment variable, a secrets manager, or a configuration file. Any of those storage locations is a potential exposure point.

More critically: if a symmetric secret leaks, an attacker can use it to sign new tokens, not just verify existing ones. They can create a valid JWT claiming to be any user in the system. The secret that was meant to protect the system becomes the tool to impersonate anyone in it.

Asymmetric verification breaks this. The private key that signs tokens never leaves Supabase's key management infrastructure. The public key that verifies them is published openly at the JWKS endpoint — it can be fetched by anyone, but it can only verify signatures, never create them.

What JWKS Is and How It Works

JWKS (JSON Web Key Set) is a standard format for publishing public keys. Supabase exposes a JWKS endpoint that contains the current public key(s) used to sign JWTs. When Stow needs to verify a token:

1. The JWT's header contains a kid (Key ID) identifying which key signed it
2. Stow fetches the JWKS endpoint and finds the matching public key
3. The JWT signature is verified against the public key using RS256 or ES256
4. If the signature is valid and the claims (expiry, audience, subject) check out, the token is accepted

The verification step uses no secrets that Stow stores — only the public key, which is public by design.

RS256 vs. ES256: The Two Algorithms

Supabase uses RS256 as the default and supports ES256. Stow's verification layer handles both, accepting whatever algorithm the JWKS endpoint declares for the signing key.

Key Rotation Without Downtime

With symmetric secrets, key rotation requires updating the secret everywhere it's deployed — every service, every environment variable, every container — simultaneously. A mismatch causes verification failures.

With JWKS, rotation is transparent. Supabase can add a new key to the JWKS endpoint while keeping the old key valid for a transition period. Services automatically pick up the new key when they next fetch from the endpoint. No coordination, no downtime, no simultaneous deploys.

This is why Stow can guarantee that credential rotation — for agents, for Supabase keys, for service connections — doesn't cause outages. The asymmetric key infrastructure handles the transition.

What This Means for Agent Authentication

When a Cursor agent connects to Stow using SSE credentials, the agent_secret is used to establish the initial trust and set the Security Baseline. That secret is verified server-side against an encrypted record, not a shared symmetric secret that needs to be distributed. When a Claude Desktop agent connects via OAuth, the resulting Bearer token is verified using JWKS — the same asymmetric path.

In both cases, the credential that matters most (the ability to sign new tokens) never leaves the issuing authority. What's distributed — public keys, OAuth tokens — can be revoked and rotated without coordinating across multiple systems.