AWS KMS-backed CryptoKey signing

[panva]

Note

This integration is experimental. Both @keyobject/aws-kms and the Node.js OpenSSL STORE URL-key support it relies on are experimental / active development and may change.

Previous discussions #66 and #466 covered signing with keys held by external systems. This is now possible in Node.js without a custom signer callback or a jose-specific integration.

I've released @keyobject/aws-kms, an OpenSSL provider that loads AWS KMS asymmetric signing keys and makes them available as provider-backed Web Crypto CryptoKey instances through .toCryptoKey(). Private key material remains in AWS KMS.

import '@keyobject/aws-kms/register'
import {
  createPrivateKey,
  createPublicKey,
} from 'node:crypto'
import { SignJWT, jwtVerify } from 'jose'

const kmsKey = createPrivateKey({
  key: new URL(
    'aws-kms:key-id=alias/jose-signing-key;region=eu-central-1',
  ),
})

const algorithm = {
  name: 'RSA-PSS',
  hash: 'SHA-256',
}

const signingKey = kmsKey.toCryptoKey(
  algorithm,
  false,
  ['sign'],
)

const verificationKey = createPublicKey(kmsKey).toCryptoKey(
  algorithm,
  true,
  ['verify'],
)

const jwt = await new SignJWT({ sub: '123' })
  .setProtectedHeader({ alg: 'PS256' })
  .setIssuedAt()
  .setExpirationTime('5m')
  .sign(signingKey)

const { payload } = await jwtVerify(
  jwt,
  verificationKey,
  { algorithms: ['PS256'] },
)

jose receives ordinary CryptoKey instances and continues using its existing Web Crypto implementation. Signing is asynchronous and invokes AWS KMS, while verification uses the locally cached public key and makes no KMS request.

The provider maps AWS KMS RSA, NIST ECDSA, Ed25519, and ML-DSA signing keys to the corresponding Web Crypto algorithms used by RS*, PS*, ES*, Ed25519, and ML-DSA-* JOSE algorithm identifiers.

Operationally:

• Node.js 26.7.0 or newer is required. (24.x backport is pending)
• Loading the backing key performs a synchronous KMS GetPublicKey request, so it should be done once during startup and the resulting CryptoKey should be cached.
• Every signature is a remote, billable KMS Sign request. Applications should use bounded concurrency appropriate for their KMS quota.
• The provider supports signing and public-key export, not JWE decryption or key agreement.
• Prebuilt packages cover macOS arm64 and Linux arm64/x64 with glibc or musl.

jose remains unaware of AWS KMS—or any other external signing system. Its input is a regular CryptoKey, its signing path remains Web Cryptography, and the OpenSSL provider loaded into Node.js performs the remote operation behind that boundary. This pattern works with any external system so long as an OpenSSL provider is provided for loading the key, exposing its public half, and forwarding signing operations.