Did that too. I even installed a hot swap for my drives. Worked like a charm.

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.

Yeah, that would be something great for sure!

Sorry, I meant PDF arranger https://github.com/pdfarranger/pdfarranger

I like to add xournal++ for editing PDF without a functional form field. And as other said already: PDF Ranger and Firefox itself

Testing your projects in Internet Explorer, other than that: none I can think of. Happy coding

Love the form factor. That’s right my alley

Never recording videos… That is outrageous ;) Interesting train of thought, though. Video is the main data hog on my drives. It’s easy to mess up the compression. At the same time is combines audio, image and time in one easy to consume file. Personally, i would miss it.

Wow, that was a rabbit hole of information, links and ideas. Thanks a lot. I reached a point of what I would call “satisfaction” https://cdn.nationalarchives.gov.uk/documents/selecting-storage-media.pdf was back linked by Nestor and it seems to give me an idea of what I’ll do next. Thanks again 👍

“The strength is in the diversity of the mediums” I like that. Should be part of the book of Zen for Backups. Thank you for your insights.

M-disk, never heard of that. I got a quick research done and it seems to be exactly what I was looking for. Thank you!

Interesting take on the test process. Never really thought of that. I just trusted in rsyncs error messages. Maybe I write a script to automate those checks. Thanks

Good advice. My off-site is my brother’s place.

Checked it out, thanks. I have to figure out, how it compares to my rsync Script

So you would suggest to get bigger and bigger storages?

I really like and can embrace the philosophical part. I do delete rigorously data. At the same time, i once had a data lost, because I was young and stupid and tried to install Suse without an backup. I still am sad to not to be able to look at the images of me and my family from this time. I do look at those pictures/videos/recordings from time to time. It gives me a nice feeling of nostalgia. Also grounds me and shows me how much have changed.

That is an always ON approach? For example with an NAS? While that is a very save approach, it does not fit the idea of having something “on the shelf”. Thank you for the advice though :)

Ugh, sounds icky. Thanks for the advice:)

https://www.ganttproject.biz This one is nice