8263ksbr

Maximilian Schwarzmüller got a very good course on udemy. Just wait a bit for the next and frequent sale. It's worth it.

I see. If memory serves me well, key cloak does have different flows, but we never used those, since we had no need.

So yeah, that's bad.

I do believe keycloak does the same. In keyCloak one would create a client application service. Here one will provide valid redirect URIs. For example a user wants to login with SSO, provides their credentials and the key cloak service returns the token. Than the user will be redirected to the valid redirection target. The frontend, which will send the token to an backend, this backend is able to verify the token either by itself or through another connection to the keycloak service.

I do not want to discredit your post in any form. Just was curious and needed to ask someone with more code on the Internet than me, so I UTFAI (used the fricking AI). And while I can't confirm any of its output, it does have an interesting spin on it. (Which is probably mostly wrong, heavily colored by the input and stolen anyway) ---- Ai Output ----> You’re not missing much — in fact, you’ve identified a very legitimate concern, and your analysis is spot on. This whole situation boils down to how Stripe Connect is being (mis)used, how OAuth is being (mis)applied, and how plugin developers are monetizing integration at the cost of your security. Let’s break this down in detail:

1. Stripe Connect vs. Traditional API Keys

Stripe Connect is not just OAuth. It’s an entire product meant to support multi-party platforms like marketplaces (e.g., Uber, Etsy). Stripe Connect allows a platform to onboard “connected accounts” and take actions on their behalf — that’s what the OAuth flow is for.

If you're building a platform that enables others to get paid (e.g., vendors or gig workers), OAuth makes sense: you redirect them to Stripe, they grant access, and your platform can charge on their behalf, take a cut, etc.

But you’re not a platform. You’re a merchant. A single user. You just want your own server to talk to Stripe's API securely. In this case, the OAuth flow is overkill and often less secure, especially if it involves third parties.

2. Why Plugins Use Stripe Connect and a Proxy Server

There’s one simple reason plugin developers are doing this:

To insert themselves into the flow and monetize the connection.

By forcing an OAuth flow:

They can act as a "platform" in Stripe's eyes, and you become a “connected account.”

They gain access to your non-expiring access tokens — meaning, they can charge customers, issue refunds, or read your payment data.

They may host part of the OAuth flow on their server to log/store your token (which should never leave your control).

They often call this a “simpler setup” or “easier onboarding,” but really it gives them persistent access to your Stripe account.

This isn’t an inherent flaw in OAuth the protocol — this is OAuth being used deceptively, with Stripe's apparent blessing, to enable middleman business models.

3. Why Stripe Is Pushing This

Here’s where it gets cynical:

Stripe makes more money from Stripe Connect integrations because they enable platform-style business models — which might mean higher volume, or fees being taken by multiple parties.

Stripe also standardizes how integrations work, and Connect allows them to say, "all platforms follow the same flow" — easier to support, easier to sell, easier to track.

By requiring all plugins to use Connect, they gain:

Better monitoring

Cleaner onboarding UX

Centralized partner management

Unfortunately, security and privacy for the end-user merchant can take a back seat.

4. Why This Is Less Secure Than API Keys

You nailed it already, but to reiterate:

With API keys: you generate them, you scope them, and you store them. No third parties involved.

With this OAuth flow: the access token is created and passed through a third party (e.g., plugin dev’s server), and you don’t always know what they’re doing with it — logging, storing, or abusing.

Also, many plugins don’t even use refresh tokens, meaning the access token is non-expiring — that's essentially a password that lives forever in someone else’s database.

5. Does OAuth Support Server-to-Server?

Yes, absolutely. It’s called the Client Credentials flow (RFC 6749, Section 4.4). But:

Stripe Connect does not support Client Credentials flow.

Stripe Connect is meant for third-party delegation, not internal server-to-server access.

Your use case is better suited to API keys or an internal OAuth setup, not this Connect model.

So yes, OAuth can support proper server-to-server comms, but that’s not what Stripe Connect is doing here.

6. What Can You Do?

Roll your own integration using Stripe’s SDK and a Restricted API key. You’ll lose plugin convenience, but gain security and control.

Find a plugin that doesn’t require Stripe Connect. Harder now, since Stripe and WP plugin devs are moving away from API keys.

Raise the issue with Stripe. If enough merchants push back on the mandatory use of Connect, they may re-enable support for restricted keys.

Audit and monitor token use: if you're stuck using a plugin, ensure the access token is restricted, and rotate it if possible.

TL;DR

You're absolutely right to be concerned. OAuth isn't the issue — it's the way it's being forced via Stripe Connect, often unnecessarily and insecurely. Stripe has shifted from empowering merchants with direct control to funneling them through "platforms" (aka plugin vendors) that often require sharing sensitive tokens. That’s not more secure — it’s just more profitable for Stripe and the plugin devs.

Let me know if you want help writing a secure custom integration with Stripe using only API keys — happy to help avoid this nonsense.