Secure Web Token (SWT) is a Node.js library offering a security-focused alternative to traditional JSON Web Tokens (JWTs). Unlike JWTs, which are merely Base64 encoded, SWT employs AES-256-GCM encryption for payloads and implements server-side session binding, making tokens device-bound and preventing reuse on other devices. This approach significantly enhances security by making stolen tokens useless for attackers. The current stable version is 1.2.8. It provides a simple API with `sign()` and `verify()` functions, supporting expiry and HttpOnly session cookies. Key differentiators include full payload encryption, true device binding, and server-side session management, making it suitable for high-security applications like admin panels, SaaS dashboards, and internal tools where preventing token leakage and session hijacking is critical.
npm install secure-web-tokenVerified import paths — ran on the pinned version, not inferred.
Demonstrates a basic Express.js server using `secure-web-token` to handle user login and protect a route. It shows how to `sign` a token with device binding, set an HttpOnly session cookie, and then `verify` the token and session context for authorized access.
Implement and configure a persistent session store (e.g., Redis, database) by providing a custom `store` object to the `sign` and `verify` functions, or by extending `getStore`.
Generate a strong, long, random secret. Store it securely (e.g., environment variable, KMS) and ensure all instances of your application use the exact same secret.
Ensure `sessionId` is consistently passed from the client (e.g., HttpOnly cookie) and use it to retrieve the `fingerprint` from your server-side session store, then pass both to `verify` options.
Configure your frontend HTTP client (e.g., Axios, Fetch API) to send credentials (`credentials: 'include'`) and allow the browser to manage the HttpOnly cookie automatically. Do not attempt to access the `swt_session` cookie from JavaScript.
Check if the token is present, unexpired, and correctly signed. Verify that the `sessionId` and associated `fingerprint` provided to `verify` match the server-side session, and that the `SECRET` is identical to the one used during `sign`.
Ensure the `sessionId` is valid and the session exists in the configured store. This often indicates a missing or expired session, or a misconfigured session store (e.g., in-memory store reset).
Confirm the `SECRET` key used in `verify` is identical to the one used in `sign`. If the secret is correct, the token may have been tampered with or is corrupted. Ensure the token is passed correctly without modification.
No dependency data recorded yet.