I don't understand what's wrong with just using cookies for authentication?
The scheme you describe is potentially vulnerable to cross site request forgery (CSRF).
An malicious request could be made on behalf of the user. This request would send the cookie which would pass the authentication checks, and perform any activity the user could themselves.
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
If you look at the link above to the OWASP article on CSRF it specifically lists secret cookies as an invalid mitigation technique.
Assuming you are using your cookies as a stateless authentication identifier then your scheme is basically similar to JWT except created with cookies. The main differences are:
- JWTs are generally only signed instead of encrypted (though you can encrypt them as well). What this means is that you can ask third party services to create tokens for you. This allows you to plug your application into other authentication services or provide an authentication service yourself for other apps.
- Mobile native apps and cookies might create problems. Generally can be overcome but the implementation can be a lot trickier than using tokens which only need to be attached as text to a request header or body and are easily stored.
- JWTs are easier to work with especially in javascript environments as you can pretty much attach any metadata you want to the claims and can read them as you would normal JSON. It also helps that with their popularity you can find ready-built solutions for more of the modern frameworks.
- Cookies are vulnerable to cross-site request forgery (CSRF) while tokens will depend on how you store them (cross-site scripting (XSS) if in web storage, CSRF if you decide on storage cookie).
In summary what you are suggesting is solid, but it's basically the same as JWT missing a few of the benefits. If your system has no need for third party integration then by all means go with cookies, but make sure to secure them against CSRF as mentioned by @Daisetsu.