[MPSimmons]

I'm not making any judgement calls here in terms of how things are _actually_ done, or what the _actual_ risk exposure is, but...

The design philosophy seems to be, use short-lived security credential A (the jwt) for all of your requests, which (again, _theoretically_) risks its exposure, and have a Security Credential B that you keep very secure, and use that to create new instances of Security Credential A.

If SC-A were a cookie and SC-B were kept in a hardware store, then I think this might be logical, but where they're both basically cookies, it seems kind of crazy to me, too. Maybe there are some details in how the actual storage of the cookies varies, but I think it's Hopium all the way down.

[nprateem]

The point is JWTs can be validated independently on the server, no DB lookup is required. In distributed systems, that's the main benefit - they don't all need to talk to the auth server, just have a certificate that can be used to validate JWTs. This means they can't be practically invalidated per user though.

By contrast, refresh tokens go to the auth server that can do whatever checks are necessary to make sure the user is still allowed to use the service. This would typically incur DB lookups and require more complex auth logic than simply validating "yeah, this JWT is legit and still in-date".