Absolutely. Though, when people say cookies vs JWT, what they mean is:
Cookies: a simple session ID, a random number, stored in a cookie.
JWT: a JSON object stored in local storage that specifies authorization of some user that is authenticated by public key cryptography. JWTs can be configured in many ways, but this is what people usually mean because they want their sessions to be "stateless."
Way way more often than not, the "cookie" solution is better because it's far simpler. JWTs come with a tremendous amount of complexity with few benefits.
My big issue with JWTs: securing images. With cookies, a browser attaches the cookie on the image request. With JWT, a browser does not send it with the request. Cookies are far easier in this case.
If the token is only good for one use or for a short period of time (minutes not hours) it's probably fine. I've used them in URL's for invite links. One time use that expire after a short amount of time. Probably not perfect for high security applications like banks or health care but for most applications it's fine.
This was what I was about to post -- JWT-in-cookie is just about perfect from a security/convenience ratio standpoint is it not? Assuming the HTTP cookie is secured properly (like all cookies normally are), it's the perfect way to serve both browser and non-browser traffic (apps may choose to do a little more work to pull the cookie out of the authentication request and use just the auth header if they want).
Any thoughts? I can't think of anything glaringly wrong with the scheme.
Also, I generally think that if someone has the resources to obtain your JWT it probably doesn't matter if it's encrypted (assuming it's stuff like the user's ID or roles, and not something you shouldn't be putting in there anyway), because the attacker has the time until you revoke the token to do whatever they want as the user.
Sorry for the curt reply, I'm about to fall asleep.
In OP's case, I think they're unlikely to see any benefits to using JWT.
Dealing with authN/authZ can grow fairly complicated depending on the business' requirements. On the surface what you're suggesting seems like it would work perfectly fine for many use-cases, so you're not wrong.
JWT is often immaterial to authentication. One must consider how the service is consumed and through which mediums. Depending on the data's importance, you'll need to carefully consider the security model.
Acquiring someone's cookie or token doesn't always mean full access, nor does it mean you get to repeatedly request new tokens. You could require an additional password check before allowing the user to take certain actions. Two examples of this are GitHub and Google.
Absolutely -- In the end to even invalidate a JWT properly you have to either depend on time (so short-lived tokens + refresh token), or store some sort of blacklist (and then you're back to where you started anyway). The world is probably ready for a microservice that does this that everyone can use -- I saw one on HN a while ago but haven't seen it since.
The big benefit I saw from JWTs was the stateless nature, with the drawback of servers using the same key.
OP is not familiarized with the topic, and was probably confused and overwhelmed. Not surprising, as getting authentication right can be very challenging.
I told them to avoid JWT and instead use old-school stateful session cookies because there's tons of libs that do most of the work for you, and they're unlikely to see any material benefits at this time from using JWT.
Cookies: a simple session ID, a random number, stored in a cookie.
JWT: a JSON object stored in local storage that specifies authorization of some user that is authenticated by public key cryptography. JWTs can be configured in many ways, but this is what people usually mean because they want their sessions to be "stateless."
Way way more often than not, the "cookie" solution is better because it's far simpler. JWTs come with a tremendous amount of complexity with few benefits.