DEV Community: Tharindu Karunanayaka

How Do You Log Someone Out of a Stateless System? JWT Invalidation on Logout

Tharindu Karunanayaka — Sat, 04 Jul 2026 09:37:35 +0000

JWTs are one of those technologies that feel wonderful right up until you hit your first "log me out" requirement. Then you discover the awkward truth: the very property that makes JWTs attractive — statelessness — is also what makes logout hard.

This post walks through what JWTs actually are, why "invalidating" one is a design problem rather than a one-liner, and the practical methods available to revoke an access token on logout, along with the bottleneck each one introduces.

A quick refresher on JWTs

A JSON Web Token (JWT) is a signed, self-contained token. It carries a JSON payload of claims — who the user is, when the token was issued, when it expires, and often a unique token id (jti) — and a cryptographic signature over that payload. Because the token is signed with a secret (or a private key), any server holding the corresponding key can verify it is authentic and untampered without calling a database.

That last part is the entire point. When a request arrives with a JWT, the server checks the signature and the expiry, reads the claims, and proceeds. No lookup, no shared session store, no round trip. This is what people mean when they call JWT auth stateless: the server keeps no per-user session record. The token itself is the session, and it's valid until it expires.

Access tokens and refresh tokens

In practice you rarely use a single token. The common pattern splits responsibility across two:

The access token is the short-lived workhorse. It's sent on every API request and typically expires in minutes (5–15 is common). Because it's checked statelessly on every call, you want its lifetime short — if it leaks, the damage window is small.

The refresh token is long-lived (days or weeks) and does one job: obtain new access tokens when the current one expires. It is not sent on every request — only to a dedicated token endpoint. This lets the access token stay short and stateless while the user avoids logging in every ten minutes.

The refresh token is easy — the access token is the problem

Here's the key insight that shapes everything below: the refresh token is not the hard part of logout.

Refresh tokens are few, long-lived, and hit a single endpoint. Whoever issues them — your auth provider, or your own token endpoint — already stores them server-side. On logout you simply tell the provider to invalidate that refresh token, and it's done. The user can no longer mint new access tokens. One database write, one endpoint, no impact on your request hot path.

The access token is where the difficulty actually lives. It's stateless by design: no server stored a copy, and its signature stays valid until the exp claim passes. So even after you've killed the refresh token, the user's current access token keeps working until it naturally expires. If you do nothing, a "logged out" user still has a working access token for its remaining lifetime.

So the real question this post answers is narrow: how do we stop an already-issued access token from being accepted, without giving up too much of the statelessness we adopted JWTs for? Every method below is a point on that tradeoff curve.

Method 1: Short expiry and just wait it out

The simplest approach is to not revoke the access token at all. Keep it very short-lived and accept that logout means "invalidate the refresh token, delete the tokens client-side, and let the access token expire on its own."

Because the refresh token is already dead, the user can't get a new access token — so the only exposure is the current one finishing out its few remaining minutes.

Bottleneck: it doesn't actually revoke anything. A leaked or stolen access token works until it expires, and there is no way to kill it early. This is perfectly fine for low-risk apps with genuinely short tokens, but unacceptable when you need immediate, guaranteed revocation of a specific token.

Method 2: Token blocklist (denylist)

Keep a list of access tokens that have been explicitly revoked, identified by their jti. On logout, add the token's jti to the blocklist. On every request, look up the incoming token's jti before honoring it — if it's on the list, reject it even though the signature is valid.

The natural home for this is a cache with a TTL, such as Redis. The crucial detail: you set each blocklist entry's TTL to match the token's own remaining validity. Once the token would have expired anyway, the entry evaporates on its own, so the blocklist never grows unbounded — it only ever holds tokens that are both revoked and not yet naturally expired. Every request does a quick jti lookup against that cache.

Bottleneck: you've reintroduced a lookup on every request, which is exactly the statelessness you were trying to avoid. In practice it's a cheap in-memory hit, but it's now a hard dependency on the auth path — if the cache is down or slow, your authentication is down or slow. At scale it becomes shared infrastructure you must replicate, secure, and keep highly available. You've traded some statelessness for the ability to revoke instantly.

Method 3: Token versioning / "valid-after" timestamp

Store a single small value per user — a token version number or a tokensValidAfter timestamp. Embed the version (or the token's issue time) in the JWT. On each request, compare the token against the user's current value; if the token predates it, reject it. Logging out is just bumping the version, which instantly invalidates every access token issued before the bump.

Bottleneck: you still need a lookup for the user's current version, so it isn't free — but it's a tiny per-user value rather than a per-token list, which makes it far cheaper to store and trivial to cache. The tradeoff is coarser granularity: bumping the version invalidates all of that user's access tokens at once. That's exactly what you want for "log out everywhere," but if you need to revoke a single device while leaving others alive, you'd need per-device versioning, which grows the state again.

Choosing between them: combine Method 1 and Method 2

For most real systems, the best answer is not to pick one method but to combine short expiry (Method 1) with a jti blocklist (Method 2) — on top of invalidating the refresh token at the provider.

Here's why the combination works so well. Method 1 alone can't revoke a specific token early; Method 2 alone would force you to keep a huge, long-lived blocklist if tokens lived for hours. Together they cancel out each other's weaknesses:

Short expiry keeps the blocklist tiny and self-cleaning. Because access tokens only live a few minutes, any blocklist entry's TTL is also only a few minutes. The cache stays small, cheap, and fast no matter how many logouts happen — entries are added on logout and disappear moments later when the token would have expired anyway.
The blocklist closes the gap that short expiry leaves open. Method 1 alone means a logged-out or stolen token keeps working for its full remaining lifetime. Adding the jti blocklist lets you kill that specific token immediately, so you get instant, guaranteed revocation when you need it.
The cost stays bounded. be clear about what you're paying. Every single authenticated request now makes a network call to the cache to check the jti. That adds latency to each request — typically a small amount (often sub-millisecond to a few milliseconds on a Cache), but it's real, it's on the critical path, and it scales with your request volume. You're also now depending on the cache being available: if Cache is slow, every request slows down; if it's unreachable, you have to decide whether to fail open (accept tokens you can't verify against the blocklist) or fail closed (reject everyone), and neither is comfortable. And it's another piece of stateful infrastructure to run, replicate, monitor, and secure. The blocklist staying small thanks to short TTLs is genuinely helpful, but it doesn't remove these costs — it only keeps the memory footprint modest.

Put together, a typical logout flow looks like this: invalidate the refresh token at the provider (so no new access tokens can be minted), add the current access token's jti to the Cache blocklist with a TTL equal to its remaining lifetime (so the existing token dies immediately), and clear the tokens on the client. Every incoming request then verifies the signature and expiry statelessly, plus one fast jti lookup — and short token lifetimes guarantee that lookup table stays small.

The recurring theme is unavoidable: every method that gives you real revocation power reintroduces some state. JWTs let you choose how much state and where it sits. Combining short expiry with a small, TTL-bounded jti blocklist is the sweet spot for most applications — it keeps the request path almost fully stateless while still letting you revoke an access token the instant a user logs out.

Social signing: log in, sign, never touch the key with AWS Nitro Enclaves

Tharindu Karunanayaka — Sat, 04 Jul 2026 08:59:19 +0000

Picture a product where users sign up with a normal social login, get a blockchain wallet without knowing it, and send transactions by clicking a button. No seed phrase, no browser extension, no scary "write down these 12 words or your money is gone forever" screen. To them it feels like any other app. Behind it sits a real on-chain account with a real private key.

The whole thing lives or dies on one question: if a backend is creating and holding private keys for every user, what happens when someone breaks in? A database full of user private keys is about the worst thing you can leak. So the bar is simple to state and annoying to actually meet: even the people running the service shouldn't be able to read the keys. Not the developers, not the on-call engineer at 2am, not an attacker who's popped a shell on the box, not whoever ends up with a copy of the database.

The usual way teams get this experience is to buy it. You integrate a Wallet-as-a-Service provider — Privy, Magic, Web3Auth, Turnkey, etc abd let them handle key creation, custody, and signing behind their SDK. That's a perfectly reasonable choice, and for a lot of teams it's the right one. But it comes with trade-offs: a third party now holds (or co-controls) your users' keys, you're tied to their pricing and uptime, your security story is only as good as their black box, and there's usually a per-wallet or per-signature bill that grows with you. This post is about the other path — building the whole thing yourself, in your own AWS account, so no outside vendor ever touches a private key and the trust boundary is entirely yours.

Doing that used to mean standing up and babysitting your own HSMs, which is exactly why most people reach for a WaaS in the first place. The shortcut is AWS Nitro Enclaves doing the sensitive work, with KMS acting as a bouncer that will only unlock a key for one specific, provable piece of code. You get HSM-grade key protection without running an HSM, on infrastructure you already have. I'll follow the user's journey — sign up, key gets made, log in, send funds — and bring in the security machinery at the points where it actually matters, rather than dumping it all up front.

If you're comfortable with OAuth, EC2, IAM and a bit of Python you'll be fine. The examples are deliberately chain-agnostic: wherever you'd otherwise load a raw private key (ed25519, secp256k1, whatever your chain uses) into memory to sign a transaction, the same pattern applies. Slot in your chain's SDK where the placeholders are.

Here's the shape of it before get into the weeds:

The one thing to hold onto: a plaintext private key only ever exists for a few milliseconds, and only ever in two places — inside a sealed enclave and inside a KMS hardware module. It never lands on the app servers, the database, the logs, or the wire. Not even when it's first created.

Signing up, and letting the enclave make the key

The front door is boring on purpose. User taps "sign up," an OpenID Connect flow runs through the identity provider (Cognito in front of the social providers works well here, but Auth0 or Google directly are the same idea), and back comes a JWT with the usual claims — sub, email, aud, iss, exp.

The sub claim is the important one. It's a stable unique ID for the user, and it becomes the handle everything else hangs off of.

Now, where do you generate the key? The obvious answer is a Lambda, and it works. But it has a nagging problem: for a few milliseconds the raw key sits in ordinary Lambda memory. Nobody's supposed to be able to read it, but "supposed to" is doing a lot of work in that sentence. The stronger option is to generate the key inside the enclave too. Then the raw key is born inside the sealed box and gets encrypted before anything ever leaves. There's no window, however tiny, where it exists somewhere it could theoretically be read.

The parent server just asks the enclave (over the local vsock channel — more on that soon) to make a wallet, and passes along some temporary AWS credentials so the enclave can reach KMS. This code runs inside the enclave:

import boto3
from botocore.config import Config

KMS_KEY_ID = "arn:aws:kms:us-east-1:123456789012:key/abcd-…"

def kms_client(creds: dict):
    # The enclave has no network of its own; it reaches KMS through the
    # local vsock proxy the parent runs (same path used for decryption).
    return boto3.client(
        "kms",
        region_name="us-east-1",
        aws_access_key_id=creds["access_key_id"],
        aws_secret_access_key=creds["secret_access_key"],
        aws_session_token=creds["token"],
        config=Config(proxies={"https": "127.0.0.1:8000"}),
    )

def create_wallet(creds: dict) -> dict:
    """Runs INSIDE the enclave. The plaintext private key never leaves this function."""
    private_key, address = generate_keypair()      # your chain's keygen (ed25519, secp256k1, …)
    ciphertext = kms_client(creds).encrypt(
        KeyId=KMS_KEY_ID,
        Plaintext=private_key,                      # the raw private key material
    )["CiphertextBlob"]
    return {
        "address": address,                         # public address, fine to hand back
        "encrypted_key": ciphertext.hex(),          # only ciphertext leaves the enclave
    }

Once the enclave hands back the public address and the ciphertext, the parent's job is trivial: drop that ciphertext into Secrets Manager under the user's sub.

import json, socket, boto3

secrets = boto3.client("secretsmanager")

def create_account(token: str, aws_creds: dict) -> str:
    claims = verify_jwt(token)                                  # who is this user?
    result = call_enclave({"op": "create", "credential": aws_creds})

    secrets.create_secret(
        Name=f"wallet/user/{claims['sub']}",
        SecretString=json.dumps(result),           # { address, encrypted_key }
    )
    return result["address"]                        # show the user their shiny new address

Where the key actually lives

The encrypted key goes into AWS Secrets Manager, one secret per user, named wallet/user/<sub>. What's stored there is already useless on its own — it's envelope ciphertext that can't be unwrapped without both KMS and the enclave, which is the whole point of the next section. So even if someone dumped every secret in the account, they'd have a pile of garbage.

Secrets Manager is a good fit here for a few reasons beyond just holding bytes. It re-encrypts everything at rest with its own KMS key, so the key ends up wrapped twice: once by the master key inside the enclave, then again by Secrets Manager. It gives you per-secret IAM, CloudTrail on every read, and versioning, all of which are nice to have when the thing you're storing is somebody's wallet. Scope the parent's role so it can only touch wallet/user/* and nothing else in the account.

One detail on cost and key management, since it comes up: use a single KMS master key to encrypt every user's private key. A private key is nowhere near KMS's 4 KB encryption limit, so there's no reason to mint a KMS key per user, and KMS bills per master key, so per-user keys would be financially silly. The per-user isolation that matters doesn't come from having millions of master keys anyway — it comes from each ciphertext being distinct and from the decrypt being gated. Which, finally, brings us to the interesting part.

Sending a transaction by logging in

This is the payoff and also where all the security machinery earns its keep. A returning user logs in, gets a fresh JWT, asks to send some funds, and the system signs the transaction with their key — without that key ever being visible to the servers. To believe that last clause you need to understand three things, so here they are roughly in the order you'd hit them.

The sealed box

A Nitro Enclave is a stripped-down virtual machine carved out of a normal EC2 instance. No disk, no network card, no SSH, and — this is the part that matters — no way for anyone to read its memory, including root on the parent instance. The only channel in or out is a local socket called vsock, addressed by a context ID (think of it like an IP) and a port. Only the key-handling code runs in there: creating wallets and signing. Everything else — the web server, JWT checks, Secrets Manager calls — runs on the parent, outside the box, which you should assume could get compromised.

PCR0, or how KMS knows it's really your code

For KMS to hand a key only to your signing code, it needs some way to recognize that code. That mechanism is PCR0.

PCR is short for Platform Configuration Register. When an enclave boots, the Nitro hypervisor measures the image as it loads it — hashing the contents into a set of registers that the enclave itself can't write to. If you've ever poked at a TPM and secure boot, it's the same idea. Only the hypervisor sets these values, at boot, which is exactly why you can trust them. There are a few of them:

PCR0 is a SHA-384 hash of the entire enclave image, kernel and app and all. That's the one you'll usually use. PCR1 covers just the kernel and bootstrap, PCR2 just the app without the kernel, and PCR8 is the certificate you signed the image with, if you signed it (handy if you'd rather pin "anything the build pipeline signed" than one exact hash).

The thing to internalize about PCR0 is that it's a content hash, so it's completely deterministic and completely unforgiving. Rebuild the exact same image and you get the exact same PCR0. Change one line, bump a dependency, nudge the base image, and it's a totally different value. You see it printed when you build:

nitro-cli build-enclave --docker-uri signing-server:latest --output-file signing_server.eif
# Measurements:
#   "PCR0": "abacc679…cacd9fc0373ecd78c34c3e4cbf78ea9b5b0452a18"

That string is the fingerprint of your exact code, and it's what KMS checks before it will decrypt anything. Two things trip people up here, so consider yourself warned. First, because PCR0 changes on every code change, shipping a new enclave build means updating the KMS policy — allow both the old and new value during a rollout so you don't lock yourself out mid-deploy (signing images and pinning PCR8 is the cleaner long-term answer). Second, if you run with --debug-mode to see console output, attestation is disabled and all the PCRs go to zero. Great for local testing, a disaster if you point it at real keys.

Attestation, and the part everyone gets wrong

When the enclave asks KMS to decrypt, it doesn't send a plain API call. The Nitro SDK wraps the request in a signed attestation document that carries the PCR values and a one-time public key the enclave just generated. KMS checks that the document genuinely came from Nitro hardware and that PCR0 matches the condition in the key policy.

(Worth noting the asymmetry with sign-up: encrypting the key back during account creation needed no attestation at all — anyone with the right IAM can encrypt. Decrypting is the dangerous direction, so that's the one that's locked down.)

Here's the bit that's easy to get wrong, and almost everyone does at first: the decryption happens in two places, not one.

The real decryption happens inside KMS, not in the enclave. The master key never leaves the hardware module; KMS unwraps the ciphertext into the raw key on its side. But it obviously can't just send that plaintext back over the wire, since the reply travels through the untrusted parent to get to the enclave. So instead KMS re-encrypts the plaintext using that one-time public key from the attestation document and returns that (the CiphertextForRecipient field). Then a second decryption happens locally, inside the enclave, using the matching one-time private key that never left it.

You don't hand-roll any of this. The kmstool_enclave_cli binary that AWS ships does both halves — it builds the attested request (that's decryption #1, in KMS) and does the local unseal (decryption #2, in the enclave), and just hands you the plaintext.

The policy condition doing the enforcing is one line, kms:RecipientAttestation:ImageSha384, which reads as "only an enclave whose PCR0 equals this may decrypt":

{
  "Sid": "Allow decrypt only from our enclave",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::<ACCOUNT_ID>:role/ec2-instance-role" },
  "Action": "kms:Decrypt",
  "Resource": "*",
  "Condition": {
    "StringEqualsIgnoreCase": {
      "kms:RecipientAttestation:ImageSha384": "<YOUR_PCR0_VALUE>"
    }
  }
}

So stealing the instance credentials gets you nowhere. Dumping every secret gets you nowhere. To decrypt a key you'd have to be the exact code, running inside a genuine enclave — and even that wouldn't help you, for reasons I'll come back to at the end.

Wiring it together

The full send path: verify the login JWT, pull the user's ciphertext out of Secrets Manager by sub, fill in the public chain data the transaction needs (nonce, fee, gas, chain ID — whatever your chain uses), then push the ciphertext and the unsigned transaction into the enclave to sign.

Verifying the login token on the parent is a few lines of PyJWT:

import jwt
from jwt import PyJWKClient

jwks_client = PyJWKClient("https://YOUR_IDP_DOMAIN/.well-known/jwks.json")

def verify_jwt(token: str) -> dict:
    signing_key = jwks_client.get_signing_key_from_jwt(token)
    return jwt.decode(
        token,
        signing_key.key,
        algorithms=["RS256"],
        audience="your-api-identifier",
        issuer="https://YOUR_IDP_DOMAIN/",
    )                                  # ["sub"] == the user's Secrets Manager key

A note on stepping up to MFA for bigger transfers. The login JWT tells you who the user is, but for a large payment you want fresh proof that the actual human is behind this particular transaction, not just that they logged in an hour ago. The pattern for that is step-up authentication. The parent runs some business logic first — over some value threshold, say, or past a daily cumulative limit, or a destination the account has never sent to — and if the transaction trips that rule it refuses to sign and sends back a challenge instead. The app then prompts for MFA (a TOTP code, a passkey, a push), and on success the IdP mints a second JWT that's scoped to this one transaction: bound to the exact amount and destination, with an expiry measured in a minute or two so it can't be replayed on a different or later transfer. The parent checks both tokens — the session one for identity, the step-up one for this specific transaction — before anything reaches the enclave.
def require_step_up_if_needed(session_claims, amount, to, step_up_token):
    if amount <= LIMIT:                           # small tx: session JWT is enough
        return
    if not step_up_token:
        raise StepUpRequired()                    # tell the app to prompt for MFA
    mfa = verify_jwt(step_up_token)               # same signature/claims checks
    if (mfa["sub"] != session_claims["sub"]       # bind it to THIS user + THIS transfer
            or mfa.get("amount") != amount
            or mfa.get("destination") != to
            or "mfa" not in mfa.get("amr", [])):   # amr = auth methods actually used
        raise Unauthorized()
The nice thing is that it's a completely separate lock that slots in before the key machinery, and it doesn't touch any of it. The enclave, the attestation, the KMS policy — all unchanged. You've just made the "should this transfer happen at all" decision stricter for the transactions that deserve the extra friction.

The parent side, then, authenticates, loads the ciphertext, fills in the public chain data, and relays. It never touches a plaintext key:

import json, socket, boto3

secrets = boto3.client("secretsmanager")
chain = ChainClient("https://your-node.example:PORT")   # your chain's RPC client
ENCLAVE_CID, ENCLAVE_PORT = 16, 5000

def call_enclave(payload: dict) -> dict:
    s = socket.socket(socket.AF_VSOCK, socket.SOCK_STREAM)
    s.connect((ENCLAVE_CID, ENCLAVE_PORT))
    s.send(json.dumps(payload).encode())
    result = json.loads(s.recv(8192).decode()); s.close()
    return result

def send(token: str, to: str, amount, aws_creds: dict) -> str:
    claims = verify_jwt(token)                                   # 401 if invalid
    record = json.loads(
        secrets.get_secret_value(SecretId=f"wallet/user/{claims['sub']}")["SecretString"]
    )

    # Build the unsigned tx and fill in public chain data (nonce, fee, gas, chain id…).
    unsigned_tx = build_tx(from_addr=record["address"], to=to, amount=amount)
    unsigned_tx = fill_chain_params(unsigned_tx, chain)          # public data, no key needed

    signed = call_enclave({
        "op": "sign",
        "transaction": unsigned_tx,
        "encrypted_key": record["encrypted_key"],
        "credential": aws_creds,                                # temp instance creds
    })
    return chain.broadcast(signed["signed_tx"])                 # submit; needs no key

Why does the enclave need AWS credentials handed to it? Because it has no network of its own. It borrows the parent's temporary instance credentials, tunneled through the same vsock proxy, to reach KMS. On their own those credentials are useless for this — without a valid attestation document, KMS just refuses to decrypt.

And the enclave itself, which is a single small server handling both the create from sign-up and the sign here:

import base64, json, socket, subprocess

VSOCK_PORT = 5000

def kms_decrypt(ciphertext_hex: str, creds: dict) -> bytes:
    """kmstool_enclave_cli does decryption #1 (KMS) and #2 (local unseal)."""
    out = subprocess.run(
        ["/app/kmstool_enclave_cli",
         "--region", "us-east-1", "--proxy-port", "8000",
         "--aws-access-key-id", creds["access_key_id"],
         "--aws-secret-access-key", creds["secret_access_key"],
         "--aws-session-token", creds["token"],
         "--ciphertext", ciphertext_hex],
        capture_output=True, check=True,
    ).stdout.decode()
    b64 = out.strip().split(":")[-1].strip()     # "PLAINTEXT: <base64>"
    return base64.b64decode(b64)                 # the raw private key

def handle(req: dict) -> dict:
    if req["op"] == "create":
        return create_wallet(req["credential"])          # from sign-up
    if req["op"] == "sign":
        private_key = kms_decrypt(req["encrypted_key"], req["credential"])
        try:
            signed_tx = sign_transaction(req["transaction"], private_key)  # your chain's signer
            return {"signed_tx": signed_tx}
        finally:
            del private_key                              # don't let plaintext outlive the request
    return {"error": "unknown op"}

def serve():
    s = socket.socket(socket.AF_VSOCK, socket.SOCK_STREAM)
    s.bind((socket.VMADDR_CID_ANY, VSOCK_PORT)); s.listen()
    while True:
        conn, _ = s.accept()
        req = json.loads(conn.recv(8192).decode())
        conn.send(json.dumps(handle(req)).encode())
        conn.close()

if __name__ == "__main__":
    serve()

That's the entire trust boundary, and it's small enough to read in one sitting. The same sealed box both mints keys and signs with them, and in either case the plaintext key only exists inside the enclave — created in create_wallet or briefly revived in kms_decrypt, used once, and dropped before any reply crosses back over vsock. (generate_keypair and sign_transaction are the only two chain-specific pieces; everything else is identical no matter which blockchain you're on.)

Building and running it

The enclave app is a Docker image that you convert into an enclave image file:

FROM amazonlinux:2
RUN yum install -y python3 gcc python3-devel && pip3 install boto3 <your-chain-sdk>
COPY kmstool_enclave_cli /app/kmstool_enclave_cli
COPY libnsm.so /app/libnsm.so
COPY server.py /app/server.py
CMD ["python3", "/app/server.py"]

nitro-cli build-enclave --docker-uri signing-server:latest --output-file signing_server.eif
# ^ prints PCR0 → paste it into the KMS key policy
nitro-cli run-enclave --cpu-count 2 --memory 3806 \
                      --eif-path signing_server.eif --enclave-cid 16

One gotcha: enclaves aren't managed by Docker or systemd, so nothing restarts them for you if they die. A tiny watchdog under systemd that polls nitro-cli describe-enclaves and relaunches the enclave when it's gone covers this.

Wrapping up

Back at the start, the choice looked like "buy a Wallet-as-a-Service and hand off custody" or "run your own HSMs and hate your life." This is the third door. You get HSM-grade key protection out of infrastructure you already run, you own the entire trust boundary end to end, and the only two pieces that are chain-specific are generate_keypair and sign_transaction — everything else is the same whether you're on Ethereum, Solana, Bitcoin, or something that doesn't exist yet.

It's not a small amount of moving parts, and the attestation flow takes a beat to click. But once it does, the mental model is clean: social login decides who can act, the JWT and step-up MFA decide what they can do, PCR0 decides which code is allowed to touch a key, and the enclave plus KMS make sure the plaintext only ever exists somewhere nobody — including you — can reach into. That's a wallet you can put in front of ordinary users and still describe honestly: we made your key, we help you spend it, and we can't read it.

If you take one thing away, let it be that "non-custodial-ish, self-hosted, no vendor holding the keys" is not a moonshot anymore. It's a weekend spike on top of a reference implementation. So go build it.

More info — the full working reference implementation (VPC, KMS policy, enclave build, CDK) is open source: aws-samples/aws-nitro-enclave-blockchain-wallet. Clone it, deploy it, and read the parts this post glossed over.

Next steps — two directions worth exploring once the single-enclave version is working:

Remove the single point of trust with MPC. Right now one enclave can reconstruct a whole key. Split it so no single enclave (or single AWS account) ever holds the complete key, and a signature needs several parties to cooperate: Build secure multi-party computation (MPC) wallets using AWS Nitro Enclaves.
Make it production-grade. Add key backup and recovery (what happens if a user loses access?), multi-AZ high availability for the enclave and monitoring/alerting on failed attestations.