I will, but I'm 85% sure they already know -- but they made a business decision to make one OAuth flow for all "platforms" for a consistent & simpler UX (at the expense of extra security risk, which they've accepted).

Edit: wait, did you mean email stripe or email the pentest company that authored the article of common oauth vulns?

https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html

I haven't seen it. Thanks for sharing!

afaik, it doesn't cover this use-case (where the Resource Server [Stripe] just uses the wrong flow -- forcing us to expose our access keys to a third party).

But, curious, it lists 0 attacks for the OAuth Flow that Stripe should be using here = Client Credentials Flow.

Edit: ahhhhh, this paragraph is elucidating

The Authorization Code Flow is one of the most widely used OAuth flows in web applications. Unlike the Implicit Flow, which requests the Access Token directly to the Authorization Server, the Authorization Code Flow introduces an intermediary step. In this process, the User Agent first retrieves an Authorization Code, which the application then exchanges, along with the Client Credentials, for an Access Token. This additional step ensures that only the Client Application has access to the Access Token, preventing the User Agent from ever seeing it.

I confirmed that Stripe is using the Authorization Code Flow

 undefined

    
curl https://connect.stripe.com/oauth/token \
-u sk_test_MgvkTWK1jRG3olSRx9B7Mmxo: \
-d “code”=”ac_123456789” \
-d “grant_type”=”authorization_code”

  

• source: https://docs.stripe.com/connect/oauth-reference#post-token-request

...but it does appear to be using the wrong OAuth Flow type. They give the token to us in the end. There's no need to expose it to a third party.

So I guess "choosing the wrong flow type" would be a valid addition to the "attacks" section under Authorization Code Flow

No, I'm not forced to use Stripe.

I'm looking at mollie now, but I don't really know of any better alternatives to Stripe. Got a recommendation?

Anything that requires a PayPal account is not an option.

Edit: Mollie won't let us create an account unless we push >50.000 EUR/mo. Yeah, we're a small business. We're wayyy under that limit. So no Mollie :(

Thanks. It's a good guess, but that's not the case.

The developers confirmed that the only place the OAuth access tokens are stored is on my server. Of course, the dev's server (which sees the [non-expiring!] access keys for >800,000 Stripe Accounts!) would be a ripe target for someone malicious. But it's not designed to store the keys there. All subsequent connections to the Stripe API are done directly between my server and Stripe's server (with no intermediary "platform"). The token is only exposed to the dev server when OAuth flow is first established. Then the dev server (effectively a MITM, by design) sends it down to my server for storing and future use.

PCI compliance on my server isn't an issue because all sensitive payment information is tokenized.

The reason this is done is because Stripe doesn't allow the redirect during the OAuth flow to be dynamic. It must be a predefined value that's hard-coded into the app.

For security purposes, Stripe redirects a user only to a predefined URI.

• https://docs.stripe.com/connect/oauth-reference#redirect-uri

That's why Stripe forces you to expose your access tokens to the developer's servers.

I'd still appreciate if someone with more experience with OAuth than me knows if this is common. Seems like a very bad design decision to require users to transmit their bearer tokens through the developer's servers.

Update: It looks like you're describing their "Platform" option. In 2025, there's 3 "authentication types" for Stripe Apps, as documented here

1. Platform
2. OAuth 2.0
3. Restricted API Keys

In this case, I'm talking about OAuth 2.0 (Stripe Connect), not "Platform"

I have been, but Stripe support hasn't been helpful.

Update: one of the plugin authors finally explained it well:

It's because Stripe doesn't allow the redirect during the OAuth flow to be dynamic. It must be a predefined value that's hard-coded into the app.

For security purposes, Stripe redirects a user only to a predefined URI.

• https://docs.stripe.com/connect/oauth-reference#redirect-uri

That's why Stripe forces you to expose your access tokens to the developer's servers.

I'd still appreciate if someone with more experience with OAuth than me knows if this is common. Seems like a very bad design decision to require users to transmit their bearer tokens through the developer's servers.

Can you elaborate? Any idea why Stripe would choose this design?

I think Stripe generally has good security practices. But I just can't understand this design choice. There has to be a reason..

Please read the question. I am not the developer; I can't change to keycloak.

The Wordpress Activity Pub plugin is on my TODO list. I opened some bug reports with them recently.

what happens if I die? what happens if my site goes down? what happens if a site is "protected" by cloudflare (and therefore makes the content inaccessible to at-risk folks)? what happens if a site has an authwall (and therefore is inaccessible to less-privileged folks)?

I think it's important for us to federate content, not just links.

it's a lot of work, but basically I copy the html from wordpress into pandoc, convert it to markdown, and then do a lot of cleanup

• https://pandoc.org/try/

I didn't copy the whole post here because it's so much work, but I usually do when there's less images and my articles aren't likely to exceed the max char limit :)

Hi, Michael Altfield here. I was the sysadmin for OSE from 2017-2020.

Everything OSE does is transparent, so you can just check the OSE websites to see what everyone is currently working-on. OSE contributors log their hours in a worklog called "OSE Dev". There you can quickly see who is working on what.

• https://osedev.org/graphs

The above graphs show 4 contributors in the past ~10 weeks (one is me; we had some issues with the apache config recently). There's no direct link, but you can then check the wiki to see people's work logs (just search for the person's name and Log):

• https://wiki.opensourceecology.org/wiki/Marcin_Log
• https://wiki.opensourceecology.org/wiki/Catarina_Log
• https://wiki.opensourceecology.org/wiki/Alexa_Log
• https://wiki.opensourceecology.org/wiki/Maltfield_Log

I also like to look at the MediaWiki "Recent Changes" page to peak at what people are up-to as well:

• https://wiki.opensourceecology.org/index.php?title=Special:RecentChanges&limit=500&days=30

I told Marcin about Lemmy back in June 2023. Another OSE contributor even created an OSE community on the slrpnk.net instance, but it appears to have been abandoned. I'll email him about this thread to see if he'll bite and publish updates in this community since there's clearly interest :)

Also, shameless plug: I started an org that's very similar in spirit to OSE called Eco-Libre, with a focus on projects to sustainably enfranchise human rights in smaller communities. We're currently accepting volunteers ;)

• https://eco-libre.org/join

Can you mention this in your article?

Personally I wouldn't run a lemmy instance because of this (and also many other concerns)

I recommend [a] letting the lemmy devs know (eg on GitHub) that this issue is preventing you from running a lemmy instance and [b] donating to alternative projects that actually care about data privacy rights.

The fines usually are a percent of revenue or millions of Euros, whichever is higher.

So if your revenue is 0 EUR then they can fine you the millions of Euros instead. The point of the “percent of revenue” alternative was for larger corporations that can get fined tens or hundreds of millions of Euros (or, as it happened to Meta, in some cases -- billions of Euros for a single GDPR violation).

The fines usually are a percent of revenue or millions of Euros, whichever is higher.

So if your revenue is 0 EUR then they can fine you the millions of Euros instead. The point of the “percent of revenue” alternative was for larger corporations that can get fined tens or hundreds of millions of Euros (or, as it happened to Meta, in some cases -- billions of Euros for a single GDPR violation).

That would be true if their instance wasn't federating. If the instance is federating, then it's downloading content from other users, even if the user isn't registered on the instance. And that content is publicly available.

So if someone discovers their content on their instance and sends them a GDPR request (eg Erasure), then they are legally required to process it.

It's definitely not impossible to contact all instances; it's a finite list. But we should have a tool to make this easier. Something that can take a given username or post, do a search, find out all the instances that it federated-to, get the contact for all of those instances, and then send-out a formal "GDPR Erasure Request" to all of the relevant admins.

Did you read the article and the feedback that you've received from your other users?

Any FOSS platform has capacity issues. I run my own FOSS projects with zero grant funds and where I'm the only developer. I understand this issue.

What we're talking about here is prioritization. My point is that you should not prioritize "new features" when existing features are a legal, moral, and grave financial risk to your community. And this isn't just "my priority" -- it's clearly been shown that this is the desired priority of your community.

Please prioritize your GDPR issues.

Very nice. Unfortunately it doesn't look like Boost is available on F-Droid.

Fortunately, in my case, my image was "orphaned" and never actually attached to a post or comment, so it wouldn't have federated.

If the image has already federated then that's a whole next level problem :(