Is a JWT basically a session in a stateless app?

It depends on how you’re using the word. A JWT is a token format, not a session by definition. An application can use one as a session mechanism by having the client present it on each request and relying on its claims to represent ongoing authenticated context.

That does not make every JWT a session, though. Tokens can serve other purposes, and a JWT by itself does not provide the full set of behaviors people may expect from server-managed sessions.

For practical web development, I’d call it a signed authentication token rather than a session. The server does not keep a session record just because it issued a JWT. It checks the token presented with each request.

That can make request handling stateless with respect to server-side session storage, but the client still carries state in the token. Also, revoking a token before it expires can be awkward unless you add a server-side mechanism, which brings some state back into the picture.

There’s a useful distinction between session state and authentication claims. A JWT can hold claims such as an identity or permissions, but it is a poor place for values that change often. If those values change, an already-issued token may keep presenting the old claims until it expires or the system otherwise rejects it.

So use it for the limited information needed to verify a request, not as a general-purpose container for a user’s changing application state.

People use “session” in more than one way. In the broad sense, it can mean a continuing interaction whose requests are associated with the same user or context. In the narrower web-development sense, it often means data held in a server-side session store and referenced by a cookie.

Under the broad meaning, a JWT can participate in a session-like setup. Under the narrower meaning, the JWT itself is not the server-side session. Neither usage is automatically wrong, so it helps to say which one you mean.