| ▲ | 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 | |||||||||||||||||
| |||||||||||||||||
| ▲ | 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. | |||||||||||||||||
| |||||||||||||||||