Comment by losvedir
21 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?
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
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
I don't have data on whether it is common, but I know a few OAuth vendors support it.
In case anyone is wondering, here is the proposal from Cloudflare: https://blog.cloudflare.com/saas-to-saas-security/
TL;DR: visibility and control for all connections (marketplace apps, 4th parties) to your 3rd party SaaS platforms. See which connections are active as well as when and how much they transmit. Transparent token splitting to force connections through the proxy as well as instant token revocation and ACLs.
We are currently building this and would appreciate your feedback!
I mean the admin account had visibility of clients env vars, thats maybe not really great in the first place.
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.
This is incorrect.
You preface with PUBLIC_ to expose them in client side code.