Remix.run Logo
losvedir 9 hours ago

As someone trying to think about OAuth apps at our SaaS, it certainly is very hard.

Do any marketplaces have a good approach here? I know Cloudflare, after their similar Salesloft issue, has proposed proxying all 3rd party OAuth and API traffic through them. But that feels a little bit like trading one threat vector for another.

Other than standard good practices like narrow scopes, shorter expirations, maybe OAuth Client secret rotation, etc, I'm not sure what else can be done. Maybe allowlisting IP addresses that the requests associated with a given client can come from?

mooreds 9 hours ago | parent | next [-]

This was probably partly a Google refresh token theft (given the length of the access). No inside info, just looking at how the attack occurred.

OAuth 2.1[0] (an RFC that has been around longer than I've been at my employer) recommends some protections around refresh tokens, either making them sender constrained (tied to the client application by public/private key cryptography) or one-time use with revocation if it is used multiple times.

This is recommended for public clients, but I think makes sense for all clients.

The first option is more difficult to implement, but is similar to the IP address solution you suggest. More robust though.

The second option would have made this attack more difficult because the refresh token held by the legit client, context.ai, would have stopped working, presumably triggering someone to look into why and wonder if the tokens had been stolen.

0: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1

hvb2 7 hours ago | parent [-]

One time use of refresh tokens is really common? Where each refresh will get you a new access token AND a new refresh token?

That's standard in oidc I believe

mooreds 6 hours ago | parent [-]

I don't have data on whether it is common, but I know a few OAuth vendors support it.

wouldbecouldbe 9 hours ago | parent | prev [-]

I mean the admin account had visibility of clients env vars, thats maybe not really great in the first place.

iririririr 8 hours ago | parent [-]

you'd think. but this is a js dev world.

nextjs app bake all env vars on the client side code!! it's all public, unless you prefix the name with private_ or something.

rozenmd 7 hours ago | parent [-]

This is incorrect.

You preface with PUBLIC_ to expose them in client side code.