Forem: David Essien

How to Authenticate Users with Solana Wallets in NestJS

David Essien — Mon, 19 Jan 2026 07:00:00 +0000

Let's talk about wallet based auth in NestJS. What this is, is basically an auth system where the user is authenticated and authorized based on their web3 wallet. We'll be doing this with a Solana wallet. The process is quite straightforward:

User requests a nonce (a single-use random number that prevents replay attacks)
Backend sends the nonce
User signs the nonce with their wallet address and returns the signed nonce back to the backend
Backend verifies that the nonce was signed by the right address

From this point on it's your regular auth flow and you can hook this up to any existing JWT or session auth system you've implemented.

One thing to note is that a frontend is required for this or at least some way for the client to sign nonces with their web3 wallet. We'll be using @solana/kit SDK for this as it's the modern implementation of the @solana/web3.js SDK and recommended for production use by Anza.

Backend

The backend's job is to generate unique challenges (nonces), verify that signatures were created by the claimed wallet address, and issue JWT tokens on successful authentication.

We'll need to install @solana/kit as well as redis since we will be using that to store our nonces. Redis is ideal here because it provides fast in-memory storage with built-in TTL (time-to-live) expiration, automatically cleaning up old nonces without manual intervention.

npm install @solana/kit redis

Redis Service

Let's set up our redis client and service.

In NestJS, when you're working with non-class instances like Redis clients, you can't use the standard class-based dependency injection. Instead, you use string tokens as injection identifiers. The Redis client is created by a factory function (not instantiated via new RedisService()), so TypeScript can't use the class itself as a token. String constants provide a unique identifier that NestJS can use to register and retrieve the instance.

This is why we define REDIS_CLIENT as a constant string token that we'll use to register and inject our Redis client throughout the application.

//redis.constants.ts
export const REDIS_CLIENT = 'REDIS_CLIENT';

We need two specific methods here. The setNonce method stores the nonce with a 5-minute expiration using Redis's EX option, which automatically cleans up old nonces and prevents replay attacks.

The getAndDeleteNonce method atomically retrieves and deletes the nonce in one operation, ensuring each nonce can only be used once for verification. This pattern prevents an attacker from reusing a previously signed nonce.

//redis.service.ts
import { Inject, Injectable } from '@nestjs/common';
import { REDIS_CLIENT } from './redis.constants';
import type { RedisClientType } from 'redis';

@Injectable()
export class RedisService {
  constructor(@Inject(REDIS_CLIENT) private readonly redis: RedisClientType) {}

  // Store nonce with 5-minute expiration
  async setNonce(address: string, nonce: string): Promise<void> {
    await this.redis.set(`nonce:${address}`, nonce, { EX: 300 });
  }

  // Retrieve and immediately delete nonce to prevent replay attacks
  async getAndDeleteNonce(address: string): Promise<string | null> {
    const nonce = await this.redis.get(`nonce:${address}`);

    if (nonce) {
      await this.redis.del(`nonce:${address}`);
    }

    return nonce;
  }
}

We're using NestJS's ConfigService to manage environment variables in a type-safe way. This is better than directly accessing process.env because it centralizes configuration, provides validation, and makes testing easier. You can validate required variables at startup (fail fast), type-check them, and mock them in tests without polluting the global process object.

The @Global() decorator makes this module available throughout your application without needing to import it into every module. Make sure to set up ConfigModule in your AppModule like this:

// app.module.ts
import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
// ... other imports

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true, // Makes ConfigModule available globally
    }),
    // ... other modules
  ],
  // ... controllers and providers
})
export class AppModule {}

Now we can set up our Redis module:

//redis.module.ts
import { Global, Module } from '@nestjs/common';
import { RedisService } from './redis.service';
import { REDIS_CLIENT } from './redis.constants';
import { ConfigService } from '@nestjs/config';
import { createClient } from 'redis';

@Global()
@Module({
  providers: [
    {
      provide: REDIS_CLIENT,
      inject: [ConfigService],
      useFactory: async (configService: ConfigService) => {
        const client = createClient({
          url: configService.get<string>('REDIS_URL'),
        });

        client.on('error', (err) => console.error('Redis client error', err));

        await client.connect();

        return client;
      },
    },
    RedisService,
  ],
  exports: [REDIS_CLIENT, RedisService],
})
export class RedisModule {}

Auth Service

With Redis configured to handle nonce storage, we can build the authentication logic. The auth service will generate nonces, create SIWS-compliant messages, verify signatures, and issue JWT tokens. Let's implement our service logic.

We need to provide a way for the frontend to request a nonce. We also need to use our redis methods to store the nonce we provide to be used during verification later.

We use randomBytes from Node's crypto module to generate cryptographically secure random values. The 16 bytes of random data are then converted to base64url encoding, which is URL-safe and produces a string without padding characters. This encoding ensures the nonce can be safely included in URLs and JSON without escaping issues, while 16 bytes provides sufficient entropy (2^128 possible values) to prevent collision attacks. This gives us a unique, unpredictable nonce for each authentication attempt.

import { randomBytes } from 'crypto';

generateNonce(): string {
  return randomBytes(16).toString('base64url');
}

The message format follows the Sign-In with Solana (SIWS) standard, which is analogous to Sign-In with Ethereum (SIWE). This standardized format includes the domain requesting authentication, the user's wallet address, a human-readable message, the unique nonce, and a timestamp. This structure ensures the user knows exactly what they're signing and prevents phishing attacks where a malicious site might try to get users to sign messages intended for other domains.

async getChallenge(address: string) {
  const nonce = this.generateNonce();

  await this.redisService.setNonce(address, nonce);

  // Standard SIWS message format for wallet authentication
  const message = `titan-app.com wants you to sign in with your Solana account:\n${address}\n\nSign this message to authenticate.\n\nNonce: ${nonce}\nTimestamp: ${Date.now()}`;

  return { message, nonce };
}

The signature verification method is the heart of the authentication system. It retrieves the stored nonce, reconstructs the exact message that was signed, and uses Solana's cryptographic primitives to verify that the signature was created by the private key corresponding to the claimed wallet address. If any part of this fails, authentication is rejected.

import { getAddressFromPublicKey, getBase58Decoder, getBase58Encoder } from '@solana/kit';

async verifySolanaSignature(data: {
  address: string;
  signatureBase58: Uint8Array;
  message: Uint8Array;
  nonce: string;
}): Promise<boolean> {
  const { address, signatureBase58, message, nonce } = data;

  // Retrieve and delete the nonce to prevent replay attacks
  const storedNonce = await this.redisService.getAndDeleteNonce(address);

  if (!storedNonce || storedNonce !== nonce) {
    return false;
  }

  try {
    // Decode the signature and message from base58
    const signature = getBase58Decoder().decode(signatureBase58);
    const messageBytes = getBase58Decoder().decode(message);

    // Verify the signature matches the address
    const publicKey = getAddressFromPublicKey(
      getBase58Decoder().decode(address)
    );

    // Use Solana's signature verification
    const isValid = await verifySignature(publicKey, messageBytes, signature);

    return isValid;
  } catch (error) {
    console.error('Signature verification error:', error);
    return false;
  }
}

The validateUserWithWallet method either finds an existing user by wallet address or creates a new one. This is where you'd integrate with your user management system. In this example, we're using Prisma to handle database operations, but you could adapt this to any ORM or database layer.

async validateUserWithWallet(address: string): Promise<UserEntity | null> {
  // Find existing user by wallet address
  let user = await this.prisma.user.findUnique({
    where: { walletAddress: address },
  });

  // If no user exists, create one
  if (!user) {
    user = await this.prisma.user.create({
      data: {
        walletAddress: address,
      },
    });
  }

  return user;
}

The login function creates JWT tokens after successful authentication. We build a payload containing the user's ID and device information, then conditionally add email and wallet address if they exist. The function returns both an access token for immediate use and a refresh token for obtaining new access tokens when the current one expires. The refresh token is handled by a separate service that manages longer-lived tokens with different expiration rules.

async login(
  user: UserEntity,
  deviceInfo: string,
  walletAddress?: string,
): Promise<{
  access_token: string;
  refresh_token: string;
}> {
  const payload = {
    sub: user.id,
    deviceInfo,
  };

  if (user.email) {
    payload['email'] = user.email;
  }

  if (walletAddress) {
    payload['walletAddress'] = walletAddress;
  }

  const refresh_token = await this.jwtRefreshService.create(payload);

  return {
    access_token: this.jwtService.sign(payload),
    refresh_token,
  };
}

Wallet Auth Guard

Now we need a way to protect our login endpoint. NestJS guards intercept incoming requests before they reach the controller, making them perfect for authentication logic.

The guard is responsible for intercepting requests to protected endpoints and verifying that the wallet signature is valid before allowing the request to proceed. It extracts the signed data from the request body, verifies the signature using our auth service, finds or creates the user, and attaches both the user entity and wallet address to the request object for use in the controller.

// guards/wallet-auth.guard.ts
import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';
import { AuthService } from '../auth.service';
import { UnauthorizedException } from '@nestjs/common';

@Injectable()
export class LocalWalletAuthGuard implements CanActivate {
  constructor(private readonly authService: AuthService) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const request = context.switchToHttp().getRequest();
    const { address, signatureBase58, message, nonce } = request.body;

    // Verify signature first
    const isValid = await this.authService.verifySolanaSignature({
      address,
      signatureBase58,
      message,
      nonce,
    });

    if (!isValid) {
      throw new UnauthorizedException('Invalid signature');
    }

    // Find or create user
    const user = await this.authService.validateUserWithWallet(address);

    if (!user) {
      throw new UnauthorizedException('Could not validate user');
    }

    // Attach user and address to request for use in controller
    request.user = user;
    request.address = address;

    return true;
  }
}

Auth Controller

With our guard handling verification, the controller becomes simple. It just needs to provide nonces to unauthenticated users and issue tokens after the guard confirms valid signatures.

In the controller, we have two endpoints. The loginWithWallet endpoint uses our LocalWalletAuthGuard which verifies the signature and attaches both the user entity and wallet address to the request object. By the time we reach this controller method, we know the authentication is valid. We extract device information from the user-agent header, call the login service, set the refresh token as an httpOnly cookie for security, and return the access token. The getChallenge endpoint is marked with @Public() decorator since users need to request a nonce before they can authenticate. It simply returns the SIWS message and nonce for the given wallet address.

@Post('login-with-wallet')
@UseGuards(LocalWalletAuthGuard)
async loginWithWallet(
  @Request() req: RequestType & { user: UserEntity; address: string },
  @Response({ passthrough: true }) res: ResponseType,
) {
  const deviceInfo = req.headers['user-agent'] || 'Unknown Device';

  const { access_token, refresh_token } = await this.authService.login(
    req.user,
    deviceInfo,
    req.address,
  );

  // Set refresh token as httpOnly cookie for security
  res.cookie('titan_refresh_token', refresh_token, {
    httpOnly: true,
    secure: true,
    sameSite: 'strict',
  });

  return { access_token };
}

@Public()
@Get('nonce/:address')
@ApiOperation({ summary: 'Request nonce for wallet-based authentication' })
@ApiResponse({
  description: 'Nonce and SIWS message sent successfully.',
  status: 200,
  example: {
    message:
      'titan-app.com wants you to sign in with your Solana account:\n${address}\n\nSign this message to authenticate.\n\nNonce: ${nonce}\nTimestamp: ${Date.now()}',
    nonce: '1234xlrhex',
  },
})
async getChallenge(@Param('address') address: string) {
  return await this.authService.getChallenge(address);
}

Backend Summary

That covers the backend implementation. We've set up a Redis-backed nonce system that generates unique challenges for each authentication attempt, an auth service that creates SIWS-compliant messages and manages JWT token generation, a guard that verifies signatures using Solana's cryptographic primitives, and controller endpoints that handle the nonce request and login flow. The signature verification ensures that only the holder of the wallet's private key can authenticate, while the nonce system prevents replay attacks.

Frontend

The backend is now ready to issue nonces and verify signatures. The frontend's job is to request these nonces, get the user to sign them with their wallet's private key (which never leaves their browser), and send the signed message back for verification. Now let's implement the frontend of our auth system.

Now let's implement the frontend of our auth system. The user needs to sign our message with their private key. It is important this private key stays secure and never leaves the frontend. A tool that facilitates this is a wallet. Since we're using Solana we'll be using the Phantom wallet.

The setup steps are straightforward. First, install Phantom as a browser extension. Once installed, create a new wallet or import an existing one. Then navigate to Settings, go to Developer Settings, and enable Testnet mode. In Testnet mode, select Solana Devnet. You could use Localnet if you have a test validator running locally or Testnet for a shared testing environment, but Devnet provides a good balance of accessibility and realistic network conditions.

Once all this is done we can start hacking. We'll spin up a small React frontend. This is just for speed and general accessibility. You can implement this in any frontend stack as long as you understand the core steps. I used Vite to set up my React project with TypeScript and Tailwind. We should also install the @solana/kit package, which automatically includes @solana/react and other necessary dependencies, along with @wallet-standard/react-core.

npm install @solana/kit @wallet-standard/react-core

After we're done with project setup, the first thing we want to do is define our Solana client instance. This will be used to communicate with the Solana chain via its RPC endpoints.

// lib/solana-client.ts
import type {
  Rpc,
  RpcSubscriptions,
  SolanaRpcApi,
  SolanaRpcSubscriptionsApi,
} from "@solana/kit";

export type Client = {
  rpc: Rpc<SolanaRpcApi>;
  rpcSubscriptions: RpcSubscriptions<SolanaRpcSubscriptionsApi>;
};

// lib/helpers.ts
import { createSolanaRpc, createSolanaRpcSubscriptions } from "@solana/kit";
import type { Client } from "./solana-client";

let client: Client | undefined;

export function createClient(): Client {
  if (!client) {
    client = {
      rpc: createSolanaRpc(`${import.meta.env.SOLANA_RPC_URL}`),
      rpcSubscriptions: createSolanaRpcSubscriptions(
        `${import.meta.env.SOLANA_RPC_SUBSCRIPTIONS_URL}`
      ),
    };
  }

  return client;
}

Make sure your .env file contains the Devnet URLs:

SOLANA_RPC_URL=https://api.devnet.solana.com
SOLANA_RPC_SUBSCRIPTIONS_URL=wss://api.devnet.solana.com

With the Solana client configured, we need functions to communicate with our backend. In our features/auth/api folder, we'll create two API calls: one to request a nonce and another to submit the signed message. Let's define them both.

// features/auth/types
export type RequestNonceOutput = {
  message: string;
  nonce: string;
};

export type VerifyNonceInput = {
  address: string;
  signatureBase58: Uint8Array<ArrayBufferLike>;
  message: Uint8Array<ArrayBufferLike>;
  nonce: string;
};

export type LoginResponse = {
  access_token: string;
};

// features/auth/api/requestNonce.ts
import type { RequestNonceOutput } from "../types";

export async function requestNonce(
  address: string
): Promise<RequestNonceOutput> {
  const response = await fetch(
    `${import.meta.env.VITE_API_URL}/auth/nonce/${address}`
  );

  if (!response.ok) {
    throw new Error(`Failed to request nonce: ${response.statusText}`);
  }

  const data = await response.json();

  // Validate response structure
  if (!data.message || !data.nonce) {
    throw new Error('Invalid response format from nonce endpoint');
  }

  return data as RequestNonceOutput;
}

// features/auth/api/loginWithWallet.ts
import type { VerifyNonceInput, LoginResponse } from "../types";

export async function loginWithWallet(
  signedData: VerifyNonceInput
): Promise<LoginResponse> {
  const response = await fetch(
    `${import.meta.env.VITE_API_URL}/auth/login-with-wallet`,
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify(signedData),
    }
  );

  if (!response.ok) {
    const errorData = await response.json().catch(() => ({}));
    throw new Error(
      errorData.message || `Login failed: ${response.statusText}`
    );
  }

  const data = await response.json();

  // Validate response contains access token
  if (!data.access_token) {
    throw new Error('Invalid response format from login endpoint');
  }

  return data as LoginResponse;
}

These are going to serve as our connection to the backend we made previously.

Before we build the UI components, we need to manage wallet connection state across the app. React Context provides a clean way to share the selected wallet without prop drilling.

As this is only an auth demonstration it's not going to be anything fancy, just enough to implement the authentication flow and some state to show we're logged in.

First off, our wallet account context. You can use some other way to manage context in your application. Here we'll be using the React Context API.

// src/context/SelectedWalletAccountContext.tsx
import { createContext } from "react";
import type { UiWallet, UiWalletAccount } from "@wallet-standard/react-core";

export type SelectedWalletAccountState = UiWalletAccount | undefined;

export const SelectedWalletAccountContext = createContext<
  readonly [
    selectedWalletAccount: SelectedWalletAccountState,
    setSelectedWalletAccount: React.Dispatch<
      React.SetStateAction<SelectedWalletAccountState>
    >,
    selectedWallet: UiWallet | undefined
  ]
>([
  undefined,
  function setSelectedWalletAccount() {
    /* empty */
  },
  undefined,
]);

The wallet account context provider handles persistence and synchronization of the selected wallet across sessions. When a user selects a wallet, we save a storage key composed of the wallet name and account address to localStorage. On subsequent visits, the provider attempts to restore the previously selected wallet if it's still available. The provider also handles cleanup when wallets disconnect and ensures the selected account stays synchronized with the actual connected wallets from the Wallet Standard registry.

// src/context/SelectedWalletAccountContextProvider.tsx
import { useEffect, useMemo, useState } from "react";
import {
  SelectedWalletAccountContext,
  type SelectedWalletAccountState,
} from "./SelectedWalletAccountContext";
import {
  getUiWalletAccountStorageKey,
  uiWalletAccountBelongsToUiWallet,
  uiWalletAccountsAreSame,
  useWallets,
  type UiWallet,
  type UiWalletAccount,
} from "@wallet-standard/react-core";

const STORAGE_KEY = "solana-wallet-standard-react:selected-wallet-and-address";

let wasSetterInvoked = false;

// Attempts to restore previously selected wallet from localStorage
function getSavedWalletAccountAndWallet(
  wallets: readonly UiWallet[]
):
  | { account: UiWalletAccount | undefined; wallet: UiWallet | undefined }
  | undefined {
  // Stop auto-selecting after user makes explicit choice
  if (wasSetterInvoked) {
    return;
  }

  const savedWalletNameAndAddress = localStorage.getItem(STORAGE_KEY);
  if (
    !savedWalletNameAndAddress ||
    typeof savedWalletNameAndAddress !== "string"
  ) {
    return;
  }

  const [savedWalletName, savedAccountAddress] =
    savedWalletNameAndAddress.split(":");

  if (!savedWalletName || !savedAccountAddress) {
    return;
  }

  // Find matching wallet and account in current connected wallets
  for (const wallet of wallets) {
    if (wallet.name === savedWalletName) {
      for (const account of wallet.accounts) {
        if (account.address === savedAccountAddress) {
          return { account, wallet };
        }
      }
    }
  }
}

export function SelectedWalletAccountContextProvider({
  children,
}: {
  children: React.ReactNode;
}) {
  const wallets = useWallets();

  const [selectedWalletAccount, setSelectedWalletAccountInternal] =
    useState<SelectedWalletAccountState>(
      () => getSavedWalletAccountAndWallet(wallets)?.account
    );

  const [selectedWallet, setSelectedWalletInternal] = useState<
    UiWallet | undefined
  >(() => getSavedWalletAccountAndWallet(wallets)?.wallet);

  // Wrapper that saves selection to localStorage
  const setSelectedWalletAccount: React.Dispatch<
    React.SetStateAction<SelectedWalletAccountState>
  > = (setStateAction) => {
    setSelectedWalletAccountInternal((prevSelectedWalletAccount) => {
      wasSetterInvoked = true;
      const nextWalletAccount =
        typeof setStateAction === "function"
          ? setStateAction(prevSelectedWalletAccount)
          : setStateAction;

      const accountKey = nextWalletAccount
        ? getUiWalletAccountStorageKey(nextWalletAccount)
        : undefined;

      if (accountKey) {
        localStorage.setItem(STORAGE_KEY, accountKey);
      } else {
        localStorage.removeItem(STORAGE_KEY);
      }

      return nextWalletAccount;
    });
  };

  // Restore saved wallet on mount
  useEffect(() => {
    const savedWalletAccount = getSavedWalletAccountAndWallet(wallets)?.account;
    const savedWallet = getSavedWalletAccountAndWallet(wallets)?.wallet;

    if (savedWalletAccount && savedWallet) {
      setSelectedWalletAccountInternal(savedWalletAccount);
      setSelectedWalletInternal(savedWallet);
    }
  }, [wallets]);

  // Keep selected account synchronized with connected wallets
  const walletAccount = useMemo(() => {
    if (selectedWalletAccount) {
      for (const uiWallet of wallets) {
        for (const uiWalletAccount of uiWallet.accounts) {
          if (uiWalletAccountsAreSame(selectedWalletAccount, uiWalletAccount)) {
            return uiWalletAccount;
          }
        }

        // If selected account's wallet is connected, use its first account
        if (
          uiWalletAccountBelongsToUiWallet(selectedWalletAccount, uiWallet) &&
          uiWallet.accounts[0]
        ) {
          return uiWallet.accounts[0];
        }
      }
    }
  }, [selectedWalletAccount, wallets]);

  const wallet = useMemo(() => {
    if (selectedWallet) {
      for (const uiWallet of wallets) {
        if (uiWallet.name === selectedWallet.name) {
          return uiWallet;
        }
      }
    }
  }, [selectedWallet, wallets]);

  // Clear selection if wallet disconnects
  useEffect(() => {
    if (selectedWalletAccount && !walletAccount) {
      setSelectedWalletAccountInternal(undefined);
    }
  }, [selectedWalletAccount, walletAccount]);

  return (
    <SelectedWalletAccountContext.Provider
      value={useMemo(
        () => [walletAccount, setSelectedWalletAccount, wallet],
        [walletAccount, wallet]
      )}
    >
      {children}
    </SelectedWalletAccountContext.Provider>
  );
}

Once our context is set up we can import and use it like so:

// src/main.tsx
import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import "./index.css";
import App from "./App.tsx";
import { SelectedWalletAccountContextProvider } from "./context/SelectedWalletAccountContextProvider.tsx";

createRoot(document.getElementById("root")!).render(
  <StrictMode>
    <SelectedWalletAccountContextProvider>
      <App />
    </SelectedWalletAccountContextProvider>
  </StrictMode>
);

Wallet List

With context set up to track wallet state, we can build the UI. Users need a way to see available wallets and connect them to our app. The Wallet Standard exposes all compatible browser wallets, so we'll create a dialog that lists them. We'll start with the wallet list item.

// features/auth/components/wallet_list_item.tsx
import { Button } from "@/components/ui/button"
import { SelectedWalletAccountContext } from "@/context/SelectedWalletAccountContext";
import { useConnect, type UiWallet } from "@wallet-standard/react-core";
import { useContext } from "react";

type Props = {
  wallet: UiWallet;
  setOpen: () => void;
};

export const WalletListItem = ({ wallet, setOpen }: Props) => {
  const [isConnecting, connect] = useConnect(wallet);
  const [_, setSelectedWalletAccount] = useContext(
    SelectedWalletAccountContext
  );

  const handleConnect = () => {
    try {
      // Connect returns array of accounts, we select the first one
      connect().then((res) => {
        setSelectedWalletAccount(res[0]);
      });
    } catch (error) {
      console.error("Failed to connect:", error);
    } finally {
      setOpen();
    }
  };

  if (!wallet) return;

  return (
    <li>
      <Button
        variant="outline"
        disabled={isConnecting}
        onClick={handleConnect}
        className="flex flex-row p-4 items-center justify-start gap-3 w-full"
      >
        <img alt="wallet logo" src={wallet.icon} className="w-6 h-6" />
        <p className="text-lg font-semibold">{wallet.name}</p>
      </Button>
    </li>
  );
};

One thing to note is that while we can fetch all wallets connected to the browser, you often only want the ones that support the chain your application is based on. To do this we can create a hook to fetch and filter these wallets for us. You can extend this to work for multiple chains if need be. Extracting this logic into a custom hook is production-grade because it encapsulates the filtering logic in a reusable, testable unit. It makes your components cleaner by separating concerns, and if you need to add more complex filtering logic later or support multiple chains, you only need to modify this one hook rather than hunting through multiple components.

// features/auth/hooks/useFilteredWallets.tsx
import { useWallets } from "@wallet-standard/react-core";

export function useFilteredWallets() {
  const wallets = useWallets();

  // Filter wallets that support Solana chains
  const solanaWallets = wallets.filter((uiWallet) =>
    uiWallet.chains.some((chain) => chain.startsWith("solana:"))
  );

  return solanaWallets;
}

Now we can implement the actual wallet list to render all connected wallets that match our base chain.

// features/auth/components/wallet_list.tsx
import { Button } from "@/components/ui/button";
import {
  DialogHeader,
  Dialog,
  DialogTrigger,
  DialogContent,
  DialogTitle,
  DialogDescription,
} from "@/components/ui/dialog";
import { WalletListItem } from "./wallet_list_item";
import { useFilteredWallets } from "../hooks/useFilteredWallets";
import { useState } from "react";

export const WalletList = () => {
  const [open, setOpen] = useState(false);
  const solanaWallets = useFilteredWallets();

  return (
    <Dialog open={open} onOpenChange={setOpen}>
      <form>
        <DialogTrigger asChild>
          <Button variant="outline">View Wallets</Button>
        </DialogTrigger>

        <DialogContent className="sm:max-w-106.25">
          <DialogHeader>
            <DialogTitle>Select Wallet</DialogTitle>
            <DialogDescription>
              Select the wallet you want to connect to Titan.
            </DialogDescription>
          </DialogHeader>

          <ul className="flex flex-col gap-2">
            {solanaWallets.map((wallet, idx) => (
              <WalletListItem
                key={idx}
                wallet={wallet}
                setOpen={() => setOpen(false)}
              />
            ))}
          </ul>
        </DialogContent>
      </form>
    </Dialog>
  );
};

Sign-In Button

Once a wallet is connected, we need to authenticate the user. This is where the full flow comes together: request nonce, sign it, send to backend. This is just going to be a simple button that triggers the auth flow.

The first thing that will happen on click is that we request a nonce from our backend. Immediately after we get the nonce we use the useSignIn hook to sign our message. We then extract the results we need and send them in our login request.

// features/auth/components/auth_buttons.tsx
import { useSignIn } from "@solana/react";
import { Button } from "@/components/ui/button";
import { requestNonce } from "../api/requestNonce";
import { loginWithWallet } from "../api/loginWithWallet";
import type { UiWallet } from "@wallet-standard/react-core";

type SignInProps = {
  address: string;
  wallet: UiWallet;
};

export const SignInButton = ({ wallet, address }: SignInProps) => {
  const signIn = useSignIn(wallet);

  if (!wallet) return;

  const handleSignIn = async () => {
    try {
      // Request nonce from backend
      const res = await requestNonce(address);

      // Sign the message with wallet's private key
      const { account, signedMessage, signature } = await signIn({
        nonce: res.nonce,
        domain: import.meta.env.VITE_APP_DOMAIN || "localhost:5173",
      });

      // Send signed data to backend for verification
      const loginResponse = await loginWithWallet({
        address: account.address,
        signatureBase58: signature,
        message: signedMessage,
        nonce: res.nonce,
      });

      // Store access token (you might want to use a state management solution)
      localStorage.setItem('access_token', loginResponse.access_token);

      console.log('Successfully authenticated!');
    } catch (error) {
      console.error("Failed to sign in:", error);
      // You might want to show this error to the user via a toast or alert
    }
  };

  return <Button onClick={handleSignIn}>Sign In</Button>;
};

Our finished App.tsx looks like this.

// App.tsx
import { useContext } from "react";
import { WalletList } from "./features/auth/components/wallet_list";
import { SelectedWalletAccountContext } from "./context/SelectedWalletAccountContext";
import { SignInButton } from "./features/auth/components/auth_buttons";

function App() {
  const [selectedWalletAccount, _, selectedWallet] = useContext(
    SelectedWalletAccountContext
  );

  return (
    <div className="flex gap-3 min-h-svh flex-col items-center justify-center">
      <div>
        <p className="text-lg font-semibold">
          Active account: {selectedWalletAccount?.address || 'None'}
        </p>
      </div>

      <WalletList />

      {selectedWalletAccount && selectedWallet && (
        <SignInButton
          address={selectedWalletAccount.address}
          wallet={selectedWallet}
        />
      )}
    </div>
  );
}

export default App;

Frontend Summary

That wraps up the frontend implementation. We've built a wallet connection system that integrates with the Wallet Standard to support any compatible Solana wallet, not just Phantom. The context provider manages wallet selection persistence across sessions, while the sign-in flow requests a nonce from the backend, prompts the user to sign it with their wallet, and sends the signed message back for verification. The private key never leaves the user's wallet, ensuring security throughout the process.

Conclusion

We've implemented a complete wallet-based authentication system for Solana. The backend generates unique nonces with Redis-backed storage, creates SIWS-compliant challenge messages, verifies signatures using Solana's cryptographic primitives, and manages JWT token generation after successful verification. The frontend leverages the Wallet Standard to support multiple wallet providers and handles the signing flow securely within the user's wallet extension.

This auth pattern is fundamentally different from traditional username/password authentication because the user proves ownership of their wallet through cryptographic signatures rather than shared secrets. The nonce prevents replay attacks, the standardized message format prevents phishing, and the time-limited Redis storage ensures old challenges can't be reused. You can extend this system by adding additional user data to the JWT payload, implementing token refresh logic, or supporting multiple blockchain networks with minimal modifications to the core flow.

Building Secure JWT Auth in NestJS: Argon2, Redis Blacklisting, and Token Rotation

David Essien — Mon, 12 Jan 2026 08:55:38 +0000

Imagine you've just watched your first tutorial on authentication. You spin up a login flow, add some JWTs, and call it done. Then you push to production and realize those tutorials skipped the hard parts—token revocation, session management, replay attacks.

It's not enough to have a login endpoint. Production auth means thinking like an attacker and handling edge cases that basic tutorials ignore. Let's talk about what actually secure authentication looks like in NestJS and how to implement it without the security holes.

When a developer says they are "implementing auth," they are usually talking about two distinct but inseparable concepts: Authentication and Authorization. When building robust systems, these go hand in hand.

Authentication (AuthN) vs. Authorization (AuthZ)

Authentication is about identity. It answers "Who are you?" using credentials like email/password, passkeys, or biometrics.
Authorization is about permissions. It answers "What can you do?" Once we know who you are, we use strategies like Role-Based Access Control (RBAC) to ensure you only touch the resources you're allowed to.

The NestJS Toolkit: Passport and Guards

In the NestJS ecosystem, we don't reinvent the wheel. We use Passport.js, the industry standard for Node.js authentication. NestJS wraps this in @nestjs/passport and provides AuthGuards.

Guards are the "bouncers" of your application. When a request hits a protected route, the Guard intercepts it, extracts the token, and validates it before the request ever reaches your controller logic.

@Injectable()
export class JwtAuthGuard extends AuthGuard('jwt') {
  constructor(
    private readonly reflector: Reflector,
    private readonly redis: RedisService,
  ) {
    super();
  }

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const isPublic = this.reflector.getAllAndOverride<boolean>(IS_PUBLIC_KEY, [
      context.getHandler(),
      context.getClass(),
    ]);

    if (isPublic) return true;

    const request = context.switchToHttp().getRequest();
    if (!request.headers['authorization']) return false;

    const token = request.headers['authorization'].split(' ')[1] as string;

    // Check if the token was manually revoked (logout)
    const isBlacklisted = await this.redis.isTokenBlacklisted(token);
    if (isBlacklisted) return false;

    const result = super.canActivate(context);
    return result instanceof Promise ? result : (result as boolean);
  }
}

Secure Onboarding: Why Argon2?

For sign-up, you need to store passwords. I chose Argon2 over the more common Bcrypt. Argon2 was the winner of the Password Hashing Competition for a reason: it's memory-intensive.

Unlike older algorithms, Argon2 allows you to configure memory usage, making it significantly harder to crack using specialized hardware like GPUs or ASICs. It essentially punishes brute-force attempts with slow, high-resource computation.

Registration (Hashing)

When a user signs up, the plain-text password is transformed into a hash before being stored in the database.

// UsersService
import { hash } from '@node-rs/argon2';

async create(data: CreateUserDto): Promise<User> {
  let userData = { ...data };
  if (data.password) {
    const passwordHash = await hash(data.password); //
    userData = { ...userData, password: passwordHash };
  }
  return await this.prisma.user.create({ data: userData });
}

Login (Verification)

Crucially, we never "decrypt" a password. When a user logs in:

We retrieve the stored hash from the DB.
We take the plain-text password provided in the login form.
We run the provided password through the same hashing process (including the "salt" stored within the hash).
If the resulting hash matches the stored one, the user is verified.

import { verify } from '@node-rs/argon2';

// AuthService
async validateUser(email: string, password: string): Promise<UserEntity | undefined> {
  const user = await this.usersService.findOneByEmail(email);
  if (user && user.password) {
    /* The verify function automatically creates a hash of the plain
password and compares it against our stored password hash */
    const isPasswordValid = await verify(user.password, password);
    if (isPasswordValid) return new UserEntity(user);
    throw new UnauthorizedException('Password is not valid');
  }
}

The Dual-Token Strategy

Once verified, we generate two tokens.

1. The Access Token (Short-lived & Stateless)

Signed with a secret key, this contains the user’s ID and metadata. We set this to 15 minutes. This is the industry standard because it limits the "blast radius"—if a token is stolen, it’s only useful for a tiny window.

2. The Refresh Token (Long-lived & Stateful)

Signed with a completely different secret (this is vital for security), we set this to 7 days. Unlike the access token, we store this in our database (Prisma) because it needs to be stateful. We also attach a unique JTI (JWT ID) when signing the token to allow for efficient database lookups after decoding the JWT.

By storing it, we gain a "Kill Switch." If we detect suspicious activity, we can manually revoke that specific token in the DB, preventing it from ever being used to generate a new access token. Here's how we create and store the refresh token in our database:

import { randomUUID } from 'node:crypto';

// JwtRefreshService
async create(payload: CreateRefreshTokenDto): Promise<string> {
  const tokenId = randomUUID(); // Unique ID for this token
  const refresh_token = this.jwtService.sign(
    { ...payload, jti: tokenId },
    {
      secret: this.configService.get('JWT_REFRESH_SECRET'),
      expiresIn: '7d',
    },
  );

  const hashed_refresh_token = await hash(refresh_token);

  await this.prisma.refreshToken.create({
    data: {
      id: tokenId,
      token: hashed_refresh_token,
      userId: payload.sub,
      absolute_limit_at: new Date(Date.now() + 90 * 24 * 60 * 60 * 1000), // Hard session limit
      isRevoked: false,
    },
  });

  return refresh_token;
}

Solving the "Stateless Revocation" Problem with Redis

The biggest flaw in JWTs is that they are stateless. If a user logs out, their Access Token is still technically valid until those 15 minutes are up.

To fix this without destroying performance, we use Redis.

Redis is an in-memory key-value store. Because it lives in RAM, it provides the sub-millisecond read/writes we need to check every single incoming request without slowing down the API. On logout, we "blacklist" the access token in Redis for the remainder of its lifespan. Our JwtAuthGuard then checks Redis on every request: if the token is in the blacklist, access is denied. When the user logs out, we calculate how long until the access token would naturally expire and blacklist it for exactly that duration:

// RedisService implementation
async blacklistToken(token: string, ttl: number): Promise<void> {
  await this.redis.set(`blacklist:${token}`, '1', { EX: ttl }); //
}

async isTokenBlacklisted(token: string): Promise<boolean> {
    const result = await this.redis.exists(`blacklist:${token}`);
    return result === 1;
 }

// JwtAuthGuard
@Injectable()
export class JwtAuthGuard extends AuthGuard('jwt') {
    // existing authorization logic

    // Check if the token was manually revoked (logout)
    const isBlacklisted = await this.redis.isTokenBlacklisted(token);
    if (isBlacklisted) return false;

    // return result
  }
}

// Logout logic
async logout(data: { userId: string; access_token: string; refresh_token: string }) {
  const access_token_payload = await this.jwtService.verifyAsync(data.access_token);
  const ttl = access_token_payload.exp - Math.floor(Date.now() / 1000);

  if (ttl > 0) {
    await this.redisService.blacklistToken(data.access_token, ttl); //
  }
  // ... proceed to revoke refresh token
}

Refresh Token Rotation & Absolute Limits

What if a refresh token is stolen? An attacker could theoretically stay logged in for 7 days. We solve this with Refresh Token Rotation.

Every time a user uses a Refresh Token to get a new Access Token, we:

Invalidate the old Refresh Token.
Issue a brand-new Refresh Token.

The Absolute Time Limit

To prevent a session from being kept alive forever by rotation, we implement an Absolute Time Limit (e.g., 90 days). This is set at the initial login. Every time a token rotates, that original 90-day timestamp is carried forward. Once we hit that date, no more rotations are allowed—the user must log in with their password again.

// rotateRefreshToken logic
async rotateRefreshToken(payload: RotateRefreshTokenDto) {
  const { old_refresh_token_id, time_limit, sub, email, deviceInfo } = payload;

  await this.revokeRefreshToken(old_refresh_token_id); // Invalidate old

  const new_refresh_token = this.jwtService.sign(
        {
          email,
          sub,
          deviceInfo,
        },
        {
          secret: this.configService.get<string>('JWT_REFRESH_SECRET'),
          expiresIn: '7d',
        },
      );

  // Create new token record with the original time_limit
  await this.prisma.refreshToken.create({
    data: {
      token: await hash(new_refresh_token),
      userId: sub,
      absolute_limit_at: time_limit, // Carry forward absolute limit
      isRevoked: false,
    },
  });
}

  async revokeRefreshToken(token_id: string) {
    try {
      await this.prisma.refreshToken.update({
        where: {
          id: token_id,
        },
        data: {
          isRevoked: true,
        },
      });
    } catch (error) {
      if (error instanceof Prisma.PrismaClientKnownRequestError) {
        if (error.code === 'P2025') {
          throw new NotFoundException('Token not found');
        }
      }
      throw error;
    }
  }

  @Public()
  @UseGuards(JwtRefreshAuthGuard)
  @Post('refresh')
  async refresh(
    @Request()
    req: RequestType & {
      user: { email: string; id: string; refreshToken: string };
    },
    @Response({ passthrough: true }) res: ResponseType,
  ) {
    if (req.user) {
      const tokens = await this.authService.refreshTokens({
        userId: req.user.id ?? '',
        email: req.user.email ?? '',
        token: req.user.refreshToken ?? '',
      });

      res.cookie('titan_refresh_token', tokens?.refresh_token, {
        httpOnly: true,
        secure: true,
        sameSite: 'strict',
      });

      return { access_token: tokens?.access_token };
    }
  }

Reuse Detection (The "Nuclear" Option)

If a token that was already revoked is used, it signals a potential theft. The system responds by revoking all tokens for that user.

// validateToken snippet
if (storedToken?.isRevoked) {
  // Nuke 'em
  await this.prisma.refreshToken.updateMany({
    where: { userId: payload.userId },
    data: { isRevoked: true }, // Revoke all active sessions for this user
  });
  throw new UnauthorizedException('Token reuse detected. Please login again');
}

One thing to note is that while we return the access token to the user in the response body, we have to set the refresh token as a http-only cookie.

  @Post('login')
@UseGuards(LocalAuthGuard)
async login(
  @Request() req: RequestType & { user: UserEntity },
  @Response({ passthrough: true }) res: ResponseType,
) {
  const deviceInfo = req.headers['user-agent'] || 'Unknown Device';

  const { access_token, refresh_token } = await this.authService.login(
    req.user,
    deviceInfo,
  );

  // Securely set the Refresh Token as a cookie
  res.cookie('titan_refresh_token', refresh_token, {
    httpOnly: true, // Prevents JS from reading the cookie
    secure: true,   // Only sent over HTTPS
    sameSite: 'strict', // Protects against CSRF
    path: '/auth/refresh', // Optional: Only send cookie to the refresh endpoint
  });

  // Send the Access Token in the body for the frontend to store in memory
  return { access_token };
}

The reason for this is to make the refresh token invisible to the client-side javascript. Even if an attacker successfully runs a script on your page, they cannot "read" the refresh token. We also set secure: true (ensuring it's only sent over HTTPS) and sameSite: strict to protect against CSRF attacks.

As for the access token, the frontend receives it in the JSON response and typically stores it in memory (a variable). While it's still technically vulnerable to XSS, because it isn't persisted in storage, it's much harder to exfiltrate, and its short 15-minute lifespan limits the damage if it is compromised

Conclusion

At the end of the day, writing code alone doesn't build a secure authentication system. We need to constantly balance security, speed, and user experience. By thinking like an attacker, we can turn standard JWTs into a fortified system using tools like Redis and techniques like Refresh Rotation. It takes a bit more effort to set up, but the peace of mind knowing you’ve accounted for edge cases like token theft or stale sessions is well worth the complexity, especially in sensitive applications.

Summary of our Security Workflow

Memory-Hard Hashing: Used Argon2 to ensure passwords are resistant to GPU-based cracking.
Dual-Token Architecture: Balanced security with short-lived (15 min) access tokens and long-lived (7 day) refresh tokens.
Real-time Revocation: Leveraged Redis for sub-millisecond access token blacklisting upon logout.
Session Lifecycle Management: Implemented 90-day absolute time limits to ensure no session lasts forever.
Automatic Breach Detection: Enabled Refresh Token Rotation with a "nuclear" reuse detection trigger that invalidates all user sessions if a stolen token is detected.

Technical Stack Overview

Tool	Purpose	Key Feature
NestJS	Backend Framework	Modular architecture and robust dependency injection.
Passport.js	Auth Logic	Industry-standard middleware for handling JWT strategies.
Argon2	Password and Token Hashing	Memory-intensive hashing
Prisma	Database ORM	Type-safe interaction with our stateful Refresh Token storage.
Redis	In-Memory Store	Rapid read/write operations for stateless token revocation (blacklisting).
JWT	Tokenization	Secure, encoded payload delivery for AuthN and AuthZ.

Handling Cold Starts in Serverless AI: Why Your First Request Fails (And How to Fix It)

David Essien — Tue, 02 Dec 2025 10:00:00 +0000

First request to your AI model: timeout. Second request: instant success. If you've integrated AI APIs into serverless applications, you've probably hit this wall.

Here's what's happening, why it matters for user experience, and how I solved it without forcing users to manually retry.

The Problem: Cold Starts Kill First Impressions

I was testing LogicVisor (a code review platform using Gemini AI) when I noticed a pattern: after a few hours of inactivity, the first API call would consistently fail with "Model is temporarily unavailable. Please try again later". Trying again just a few seconds later always worked.

For a new user trying the platform for the first time, their experience would be:

Submit code for review
See an error message
Get told to "try again"

As you can expect, this isn't a great first experience. Even if the issue would be resolved on their second try, many would just leave.

Why This Happens: Resource Management in Serverless

On free/low-cost tiers of cloud AI services, providers deallocate resources during inactivity. When your request comes in after idle time, the model needs to "wake up":

Allocate compute resources
Load the model into memory
Initialize the runtime environment

This cold start adds latency—sometimes 2-10 seconds depending on model size. Your request times out before the model is ready.

This doesn't happen on premium tiers because you're paying for dedicated resources. But for no-cost/low-cost MVPs and proof-of-concept apps like mine, you'll deal with cold starts.

The Standard Solution: Exponential Backoff

The industry-standard approach is exponential backoff retry logic:

First retry: wait 2 seconds
Second retry: wait 4 seconds
Third retry: wait 8 seconds
Fourth retry: wait 16 seconds

This works well for distributed systems handling network congestion or database deadlocks where you don't know how long the issue will persist.

Why I Chose Linear Backoff Instead

For my specific use case, I knew:

The error was transient (always resolved on second attempt)
This was a user-facing application (waiting 16 seconds is unacceptable)
Maximum 3 retries was reasonable

Linear backoff fit better: 2s → 4s → 6s progression instead of exponential growth.

Here's the implementation:

// Helper function to call AI with linear backoff retry logic
async function callAIWithRetry(maxRetries = 3) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      // Call Gemini or Groq AI service (simplified for clarity)
      const response = await ai.models.generateContentStream({...});
      return response;
    } catch (error) {
      const errorMessage = error instanceof Error ? error.message : String(error);
      const is503Error = 
        errorMessage.includes("503") || 
        errorMessage.includes("overloaded") ||
        errorMessage.includes("temporarily unavailable");

      if (is503Error && attempt < maxRetries - 1) {
        // Linear Backoff: 2s → 4s → 6s (not exponential 2s → 4s → 8s → 16s)
        const waitTime = 2000 * (attempt + 1); 

        // Notify user via Server-Sent Events (the UX fix)
        if (!coldStartNotified) {
          controller.enqueue(
            encoder.encode(`data: ${JSON.stringify({
              type: "cold_start",
              message: "Waking up sleepy reviewer... ☕"
            })}\n\n`)
          );
          coldStartNotified = true;
        }

        console.log(`Retrying in ${waitTime}ms (Attempt ${attempt + 1}/${maxRetries})`);
        await new Promise((resolve) => setTimeout(resolve, waitTime));
        continue;
      }

      throw error; // Not a 503 or max retries exceeded
    }
  }
  throw new Error("Max retries exceeded");
}

The key differences from exponential backoff:

Fixed increment (2 seconds) instead of exponential growth
User-facing messaging during retries via Server-Sent Events
Early exit after 3 attempts to avoid hanging

Making Delays Transparent: Frontend Handling

Backend retry logic solves the technical problem, but users still experience a delay. I added cold start detection on the frontend:

const response = await submitCode(
  code,
  language,
  problemName || "Code Review",
  selectedModel,
  (content: string, eventType?: string) => {
    // Handle cold start event
    if (eventType === "cold_start") {
      setIsColdStart(true);
      setSubmitting(false);
      return;
    }

    // Handle streaming content
    setStreaming(true);
    setStreamedContent((prev) => prev + content);
  }
);

When a cold start is detected, the UI shows:

{isColdStart && (
  <div className="mb-4 p-3 bg-amber-50 dark:bg-amber-900/20 
                  border border-amber-200 dark:border-amber-800 rounded-lg">
    <p className="text-sm text-amber-800 dark:text-amber-200">
      ☕ Waking up sleepy reviewer... This may take a few extra seconds.
    </p>
  </div>
)}

This turns a confusing timeout into an understandable loading state. Users know something is happening, not that the app is broken.

Alternative Strategies (And Why I Didn't Use Them)

1. Keep-Alive Mechanisms

Set up a cron job to ping your endpoint every 5 minutes, preventing cold starts entirely.

Why I skipped it: Adds infrastructure complexity and still incurs API costs even when no real users are active.

2. Upgrade to Premium Tier

Pay for dedicated resources, eliminate cold starts.

Why I skipped it: Not viable for an MVP with zero revenue. This is the eventual solution once the platform proves itself.

Results

With linear backoff + transparent messaging:

First-time users no longer see raw error messages
Retries happen automatically and transparently
Average additional latency: ~2-4 seconds on cold starts only
Warm requests: no change in performance

Takeaway

Cold starts are an infrastructure constraint you can't eliminate on free tiers, but you can handle them gracefully:

Implement retry logic appropriate to your error pattern (linear for transient errors, exponential for unknown duration)
Make delays visible and understandable to users through status messaging
Design for the 80% case (warm starts) while handling the 20% (cold starts)

User experience isn't just about speed—it's about managing expectations during unavoidable delays.

Have you dealt with cold starts in your serverless applications? What strategy worked for you?