[com2kid]

JWTs are nice because the same authentication scheme can be used for applications and websites.

Basically a bunch of endpoints can be put up, and if they use JWTs, it is easy to hit those endpoints from any type of app.

Cookies can of course be used, but that requires pulling cookie jars into native code. Perfectly do-able, but also super awkward and potentially error prone. e.g. I remember using apps on Windows that required me to clear my Internet Explorer cookies if the native app's auth got into a broken state!

(Things aren't that bad anymore)

JWTs are also nice because I can easily write services that authenticate to each other. I can have a service running on my backend that authenticates its limited access service account, gets a JWT, and goes and talks to another service. Could I pass around cookies? Sure, but it'd be more work and more complicated than "attach this JSON blob".

Cookies are nice if everything is browser based, but I'd argue that isn't the best way to build services.

(And finally, the amount of time I've spent debugging JWT issues < the amount of time I've spent debugging cookie issues!)

[ascotan]

There is no need to write to a cookie in server-to-server auth, just pass an auth token back in a custom header. No JWT required. Cookies are for offline users.

[com2kid]

> just pass an auth token back in a custom header.

At that point why not just use JWT?

If my auth service provider already uses JWT (which it does), and all the platforms I am writing on have a provided library that consumes JWT (which they do), then why would I go with a custom header?

Also having uniformity of code patterns is nice.

My web service uses the same authentication scheme as my native apps. Heck my backend DB knows how to look JWT tokens and apply permissions correctly.