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.
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.