Snarky peer comment, but if you can do this, then yeah, it sidesteps all of the complexity of a distributed authorization system. The trade off is the single point of failure: when your token verifier goes down, so does the entire system.
What do we call a token that's stored in a cookie, sent via the HTTP 'Authorization' header to the API with each request, and Redis-cached on the server for say 5 minutes after looking it up in the users/token service? I still call it a token, just not a JWT. Maybe I should change my terminology?
I think that's reasonable terminology. "Token" is an overloaded term.
I'd be careful about "stored in a cookie" (really "sent in a cookie") because that would not be how an auth token would be sent or received. Not in a literal cookie, but another HTTP header.
I think it's fair to say that all cookies are tokens. The distinction between a typical cookie and a token in this context (i.e. a token that is difficult to revoke) is:
If a token needs to be looked up to know its authorization scope, it is easy to revoke (just update it or clear it in the lookup database). This is equivalent to a session cookie.
The challenge is when the token contains the auth scope. This might be used when the two systems do not share a lookup mechanism. These can be difficult to revoke before their built-in expiration time. This (token revocation) is the "hard part" about JWTs.