Expired JWTs keep Feathers websocket connections alive past authentication expiry

Short answer

There is no built-in Feathers configuration that automatically disconnects a websocket or removes it from channels when its JWT expires. The documented pattern is application-level: re-validate the token on each service call (or on a timer), and if it is expired, remove the connection from the relevant channels using the channels API. Closing the socket is a separate action; removing it from channels does not close the transport.

Per-call token verification is not a default transport feature for Socket.io or Primus. It is approximated by adding authentication/authorization hooks that re-check the JWT from params.authentication on every call. Exact hook names, channel APIs, and parameter shapes differ between Feathers major versions and between transports, so verify against the installed packages.

Confirmed facts and likely explanation

Based on the supplied research brief, Feathers authenticates a websocket connection at handshake time. The authentication plugin populates params.user and params.authenticated for that connection and caches them. By default, subsequent service calls and channel events over the same socket do not re-validate the JWT. This is the likely reason an expired or revoked token does not disconnect the client: the socket remains connected and stays in channels until the transport closes it.

Uncertainty: the exact behavior is version-sensitive. Feathers 4 (feathers-authentication) and Feathers 5 (@feathersjs/authentication) differ in hook context and channel API. Socket.io and Primus also differ in how connections are exposed. Treat any exact API name as needing verification against your installed versions.

Pattern for expired tokens on active connections

1. Identify versions and transport. Check package.json or run a scoped dependency query:

   npm ls @feathersjs/feathers @feathersjs/authentication @feathersjs/socketio @feathersjs/primus feathers-authentication

   This determines whether you are on Feathers 4 or 5 and which transport is in use.
2. Confirm current behavior. Add a temporary before hook on a service that logs the token payload's exp claim, params.user, and the current time. Call the service over the websocket after the token expires. If the call succeeds with a past exp, no per-call check exists.
3. Add per-call verification. In a before hook, verify the JWT from params.authentication (or re-verify via the authentication service). If expired or revoked, throw an authentication error. This rejects service calls but does not remove the connection from channels.
4. Remove from channels. Use the channels API to remove the connection from the channels it joined. In Feathers, this is typically app.channel(...).leave(connection) or the equivalent for your version. You need a reference to the connection. For service calls, params.connection may be available; for a periodic job, maintain a registry of connections with their token expiry. Removing from channels stops channel broadcasts but leaves the socket open.
5. Optionally close the socket. If you need to force disconnect, call the transport-specific close method on the connection. The question asks for removal without manually closing, so channel removal is the documented pattern.

There is no single documented Feathers pattern that does all of this automatically. The common approach is a custom hook plus a connection registry or periodic sweep.

Distinguishing socket exhaustion from database pool exhaustion

Feathers core exposes no unified connection-pool metrics. You must instrument two separate layers and correlate them under load:

Layer	Metrics to collect	What it indicates
Transport	Open websocket count, channel member counts, event-loop lag, file descriptors	Transport-level socket exhaustion if socket count is high and DB pool is normal
Database adapter	Pool acquired/idle/waiting counts (e.g., Knex, Mongoose, Sequelize)	Database pool exhaustion if waiting count is high and sockets are normal

If both are high, the expired-socket issue may be contributing to DB pressure indirectly, but you still need separate metrics to confirm. Do not rely on Feathers core for pool visibility.

One missing detail that changes the recommendation

Which Feathers major version and transport are you using? Feathers 4 with Socket.io, Feathers 5 with Socket.io, and Primus each expose different hook and channel APIs. If you provide that, the hook and channel-removal code can be made exact. Otherwise, treat the steps above as a version-agnostic outline and verify each API against your installed packages.

This draft is conservative and requires current verification against your Feathers version and transport implementation.