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

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.

Yes, BusKill works with any USB drive.

• https://github.com/buskill/buskill-app

In fact, the BusKill cable is just a USB Drive. The only thing “fancy” that it has is a magnetic coupler in the middle of the 1-meter cable so that it will breakaway at any angle. But, if you’d like, you can build your own. The instructions are here:

• https://docs.buskill.in/buskill-app/en/stable/hardware_dev/bom.html

It has a magnetic (de)coupler, which allows it to break away at any angle if your laptop is physically snatched away from you.

Some of our users actually use the BusKill cable with a Yubikey:

• https://humandecoded.io/qubes-os-yubikey-buskill/

If that’s not clear, I highly recommend watching this 2-minute explainer video

• https://www.buskill.in/#demo

It should only be posted once to this community. It’s also been cross-posted to other relevant communities.

Good bot