OAuth with refresh tokens.

IAM roles/workload identity.

Even time-limited or signed JWT, though has a separate issues.

Maybe you'll say 'those are both just text values passed like an apikey' though api keys don't frequently rotate/time limited, which is an important security feature.

▲

JoeBOFH 7 hours ago | parent | next [-]

So how would this help in this case? The oauth info would’ve just been in the csv or in someone’s env file.

	▲	sofixa 6 hours ago \| parent [-]
		With OIDC, the "info" would be just a URL with the public signing keys that the server accepts as legitimate signers. 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.

▲

jallmann 6 hours ago | parent | prev | next [-]

> OAuth with refresh tokens.

Then the LLM slurps up your refresh token. What's next?

▲

kittoes 6 hours ago | parent | next [-]

Is that really a concern though in the same way API keys are? Since when do OAuth clients store refresh tokens in areas that LLMs regularly scan? API keys are truly passwords, while refresh tokens are exchanged for a password.

Sure, a leak would be bad but I'd argue that it's orders of magnitude less likely compared to the accepted norm.

	▲	jallmann 5 hours ago \| parent \| next [-]
		The accepted norm is, increasingly, full disk access, regardless of how bad of an idea it is. At a minimum, agents typically will have a way of obtaining new access tokens. 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.
	▲	Sohcahtoa82 4 hours ago \| parent \| prev [-]
		> Since when do OAuth clients store refresh tokens in areas that LLMs regularly scan? 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.

▲

jpalawaga 4 hours ago | parent | prev | next [-]

depends on the grant type and what scenario we're talking about. things change if we're talking about 3-legged oauth or client-device oauth. for example, in an authorization code flow, the refresh token is useless without the client id/secret.

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.

▲

6 hours ago | parent | prev [-]

[deleted]

▲

XorNot 7 hours ago | parent | prev [-]

At that point you've just reinvented Kerberos tickets really...

	▲	dcrazy 7 hours ago \| parent [-]
		It’s almost like Kerberos was designed and implemented for a reason!