The server still does authorisation on top. And unless you control the private keys, you cannot mint JWTs that are accepted as legitimate.
So the "info" leaking is really not a problem.
Then the LLM slurps up your refresh token. What's next?
Sure, a leak would be bad but I'd argue that it's orders of magnitude less likely compared to the accepted norm.
Refresh tokens don't solve anything in this case; they just shuffle the problem around, and introduce other complications of their own.
What you want are capability scoped credentials that are enforced on the backend. That is agnostic to credential issuance mechanism, although passkeys are the best.
Using these credentials effectively still presupposes hygiene that might not exist in a typical developer environment, eg no root credentials (or access to such) sitting anywhere. There's probably a good product and market for whoever can solve this in a low-friction way.
If you can store your refresh token outside of where LLMs regularly scan, then why not just store your API token in that place?
The point is that refresh tokens do nothing to increase security. If a refresh token can be used to get a token, then the refresh token might as well be the actual token.
It's akin to performing client-side password hashing. It doesn't make your password more secure, it just means your hash is now your password. If someone is able to sniff your traffic, hashing the password first doesn't change anything.
I grow so tired of half-baked security theater.
more providers are making refresh-tokens single shot. this means that if someone refreshes your token for you, your own auth will break as you will not be eligible to refresh the token, at which point you could reconnect the app and void the old (stolen) session.
time-limiting and single-purposing the tokens are not cure-alls, but they do certainly offer enhanced security by limiting the amount and scope of damage.