JWT does not say anything about this. It specifies the format of the token, what it contains, and how it is encrypted or signed.
An application that I build uses these steps:
The user navigates to a login page.
He enters username and password, submits the login form.
The server validates username and password.
If they are correct, the server creates a JWT for the user.
The server sets a cookie on the response.
The browser of the user stores the cookie and sends it on any future request to the server.
The server extracts the JWT from the cookie send by the browser.
The server validates the JWT (signature OK, did not expire) to know if the user successfully authenticated.
If necessary, the server checks additional claims made in the JWT to decide if the user is allowed to access the requested resource.
I also use JWTs for server to server communication. The receiving server acts like described above. But the requesting server can not login. So I generate a long lived JWT and store it in the configuration of the requesting server.
There are two alternatives:
The HTTP header Authorization: Bearer <token>
A HTTP cookie (which is also send in a HTTP header)
It is up to the server to retrieve the JWT from these HTTP headers.
None that I know of. JWT is a fine technology. They are easy to understand, extensible, supported by many programming languages, easy to use in web applications.