"Effective defense requires architectural change: treating OAuth apps as third‑party vendors, eliminating long‑lived platform secrets, and designing for the assumption of provider‑side compromise."

Designing for provider-side compromise is very hard because that's the whole point of trust...

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. (I work for one such.)

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.

Corroborates that zero-trust until now has been largely marketing gibberish. Security by design means incorporating concepts such as these to not assume that your upstream providers will not be utterly owned in a supply chain attack.

It's important to occasionally execute or imprison a general to motivate the remaining generals. Rarely though.

Come back after 500 karma.

Organizations should do it not catastrophically wrongly, especially once a core design / concept is mostly solidified. Putting a little time into reliability and guardrails prevents a huge amount of downside.

I've been at organizations that don't think engineers should write tests because it takes too much time and slows them down...

If the battery lasts 10 years basically then that's fair, but ease of repair is very useful.

Being at the right place at the right time is more important than your equipment 80% of the time. Predict the composition and lighting and you don't need to do anywhere near as much editing.

Ha ha good luck doing that reliably with wide-angle underwater photography. You're always moving around, conditions are constantly changing, and wildlife is inherently unpredictable.

That is probably a good part of the excitement in wildlife photography. Some people camp for years waiting for a shot of a snow leopard, well the pros on contract at least.

and Kiyosaki has declared bankruptcy at least once!

There really should be a special category for business books written by people who’ve gone bankrupt. I know at least two well known examples, but there’s got to be a whole lot more.

Dave Ramsey went bankrupt but to be fair he incorporates it into his teaching.

“Hear are the things that led me to bankruptcy, and here are the things I did to climb out of it and become financially stable again.”

Good to see their purchase of Replicate paying off!

Except it's so janky and unreliable that the audience hasn't fully realized that it's not the winning move.

But if you have state, and that state needs to persist between program executions, then for the love of resiliency and all that is robust, consider using a SQL database!