socketfiAccessToken in an Authorization: Bearer header, and every protected route should call verifyAuth() before trusting any user-supplied data. This example gives you a production-ready Express server with centralized middleware, full TypeScript types, and several protected route patterns to copy from.
Architecture
Installation
Project structure
Step-by-step files
Starting the server
src/server.ts
Calling protected endpoints from the frontend
Attach the access token from the authenticated session to every request:Verification result shape
verifyAuth() returns:
result.wallet — not any wallet address sent in the request body — as the authoritative identity for all business logic.
Ownership validation pattern
A common pattern: ensure the caller is acting on their own resources, not someone else’s.Applying middleware per-route instead of globally
If your app has a mix of public and private endpoints, applyauthMiddleware at the route level:
Using with Fastify, NestJS, or Hono
verifyAuth() is framework-agnostic — the same function works wherever you can extract a Bearer token from a request header.
Clearing the key cache during testing
@socketfi/server caches public keys internally to reduce network round-trips on every verifyAuth() call. In automated tests and CI environments, you can call clearKeyCache() to flush the cache and force fresh key retrieval — useful when rotating keys between test runs.
clearKeyCache() is intended for testing environments. You do not need to call it in production code — the cache refreshes automatically.Security checklist
Always call verifyAuth()
Every protected endpoint must verify the token server-side. Never trust wallet addresses or user IDs sent from the client.
Use HTTPS
Bearer tokens in transit must be protected by TLS. HTTPS is required in production.
Validate ownership
After verifying identity, confirm the user owns the resource they’re accessing before executing any write operation.
Never log tokens
Access tokens are credentials. Log error messages, not token values.