Support namespace scoping via JWT claims

[angel-manuel]

Problem

When running sqld with --enable-namespaces in a multi-tenant setup, there's no way to restrict a JWT token to a specific namespace (or set of namespaces) using claims. Currently:

• A valid JWT grants access to all namespaces at the specified access level (rw or ro)
• The namespace is selected by the client via the x-namespace header
• A compromised token can access any namespace

Existing Work

Issue #500 proposes per-namespace signing keys, which solves key isolation but requires managing N keys for N namespaces. This proposal is complementary — it uses a single signing key with claim-based scoping.

Proposal

Add support for an optional ns (or namespace) claim in the JWT payload that restricts which namespace(s) the token can access:

// Token scoped to a single namespace
{
  "a": "rw",
  "ns": "workspace-abc123",
  "exp": 1710200000
}

// Token scoped to multiple namespaces
{
  "a": "ro",
  "ns": ["workspace-abc123", "workspace-def456"],
  "exp": 1710200000
}

// Token with no ns claim = current behavior (access all namespaces)
{
  "a": "rw",
  "exp": 1710200000
}

When ns is present, sqld would validate that the requested namespace (from x-namespace header, host header, or gRPC metadata) matches the claim. Mismatches return 403.

Use Case

We're building a platform where ephemeral VMs each own a workspace backed by a sqld namespace. An orchestrator mints short-lived JWTs for each VM. Without namespace scoping in the JWT, a compromised VM could push/pull to any workspace. With this feature, each VM's token is locked to its own namespace.

This is simpler to operate than per-namespace keys (#500) when there's a single trusted token issuer (our orchestrator) but many namespaces.

Backward Compatibility

Fully backward compatible — tokens without the ns claim behave exactly as today.

[vanchaxy]

I think it's already supported?

libsql/libsql-server/src/auth/authorized.rs

Line 181 in e4beaca

pub namespaces: Option<HashSet<NamespaceName>>,

e.g. look at the jwt used in tests: https://github.com/tursodatabase/libsql/blob/main/libsql-server/assets/test/auth/example1.jwt

{
  "p": {
    "ro": {
      "ns": [
        "example1a",
        "example1b",
        "example1c"
      ]
    }
  },
  "exp": 1001714852853
}