Why does Stripe require OAuth tokens to pass through a third party server?

Can someone who understands OAuth better than me explain to me why Stripe REQUIRES that their OAuth Access Keys get shared with a third party?

I've tried RTFM, but my biggest hangup is that the OAuth docs appear describe a very different situation than mine. They usually describe a user agent (web browser) as the client. And they talk about "your users" as if I have a bunch of users that I'm going to be fetching access keys for.

Nah, this is server <--> server. I have a server. Stripe has a server. I am one user. All I need is ONE API key for ONE account. But I'm forced to use OAuth. It doesn't seem appropriate, and it's especially concerning that the "flow" requires the (non-expiring!) Access Token to be shared with a third party server. Why?!?

I recently learned that Stripe has been pushing OAuth (branded as "Stripe Connect") to its integration apps as the "more secure" solution, compared to Restricted API Keys. In fact, we've found that most integrations we've encountered that use Stripe Connect are less secure than using Restricted API Keys because the (private!) tokens are shared with a third party!

I've been using Stripe to handle credit card payments on my e-commerce website for years. Recently, we updated our wordpress e-commerce website and all its plugins. And then we discovered that all credit card payments were broken because our Stripe Payment Gateway plugin stopped allowing use of Restricted API Keys. Instead they only support "Stripe Connect" (which, afaict, is a marketing term for OAuth). This change forced us to do a security audit to make sure that the new authentication method met our org's security requirements. What we found was shocking.

So far we've started auditing two woocommerce plugins for Stripe, and both have admitted that the OAuth tokens are shared with their (the developer's) servers!

One of them is a "Stripe Verified Partner", and they told us that they're contractually obligated by Stripe to use only "Stripe Connect" (OAuth) -- they are not allowed to use good-'ol API Keys.

They also told us that Stripe REQUIRED them to include them in the OAuth flow, such that their servers are given our (very secret!) OAuth Access Keys!

The benefit of normal API Keys, of course, is that they're more secure than this OAuth setup for (at least) two reasons:

1. I generate the API keys myself, and I can restrict the scope of the keys permissions

2. I store the key myself on my own server. It's never transmitted-to nor stored-on any third party servers. Only my server and Stripe's servers ever see it.

Can someone shine a light onto this darkpattern? I understand that standardization is good. OAuth Refresh Keys add security (this service doesn't use them). But why-oh-why would you FORCE OAuth flows that share the (non-expiring) Access Tokens with a third party? And why would you claim that's more secure than good-ol-API-keys?

Does OAuth somehow not support server<-->server flows? Or is it a library issue?

What am I missing?

Why does Stripe require OAuth tokens to pass through a third party server?

Can someone who understands OAuth better than me explain to me why Stripe REQUIRES that their OAuth Access Keys get shared with a third party?

I've tried RTFM, but my biggest hangup is that the OAuth docs appear describe a very different situation than mine. They usually describe a user agent (web browser) as the client. And they talk about "your users" as if I have a bunch of users that I'm going to be fetching access keys for.

Nah, this is server <--> server. I have a server. Stripe has a server. I am one user. All I need is ONE API key for ONE account. But I'm forced to use OAuth. It doesn't seem appropriate, and it's especially concerning that the "flow" requires the (non-expiring!) Access Token to be shared with a third party server. Why?!?

I recently learned that Stripe has been pushing OAuth (branded as "Stripe Connect") to its integration apps as the "more secure" solution, compared to Restricted API Keys. In fact, we've found that most integrations we've encountered that use Stripe Connect are less secure than using Restricted API Keys because the (private!) tokens are shared with a third party!

I've been using Stripe to handle credit card payments on my e-commerce website for years. Recently, we updated our wordpress e-commerce website and all its plugins. And then we discovered that all credit card payments were broken because our Stripe Payment Gateway plugin stopped allowing use of Restricted API Keys. Instead they only support "Stripe Connect" (which, afaict, is a marketing term for OAuth). This change forced us to do a security audit to make sure that the new authentication method met our org's security requirements. What we found was shocking.

So far we've started auditing two woocommerce plugins for Stripe, and both have admitted that the OAuth tokens are shared with their (the developer's) servers!

One of them is a "Stripe Verified Partner", and they told us that they're contractually obligated by Stripe to use only "Stripe Connect" (OAuth) -- they are not allowed to use good-'ol API Keys.

They also told us that Stripe REQUIRED them to include them in the OAuth flow, such that their servers are given our (very secret!) OAuth Access Keys!

The benefit of normal API Keys, of course, is that they're more secure than this OAuth setup for (at least) two reasons:

1. I generate the API keys myself, and I can restrict the scope of the keys permissions

2. I store the key myself on my own server. It's never transmitted-to nor stored-on any third party servers. Only my server and Stripe's servers ever see it.

Can someone shine a light onto this darkpattern? I understand that standardization is good. OAuth Refresh Keys add security (this service doesn't use them). But why-oh-why would you FORCE OAuth flows that share the (non-expiring) Access Tokens with a third party? And why would you claim that's more secure than good-ol-API-keys?

Does OAuth somehow not support server<-->server flows? Or is it a library issue?

What am I missing?

Why does Stripe require OAuth tokens to pass through a third party server?

Can someone who understands OAuth better than me explain to me why Stripe REQUIRES that their OAuth Access Keys get shared with a third party?

I've tried RTFM, but my biggest hangup is that the OAuth docs appear describe a very different situation than mine. They usually describe a user agent (web browser) as the client. And they talk about "your users" as if I have a bunch of users that I'm going to be fetching access keys for.

Nah, this is server <--> server. I have a server. Stripe has a server. I am one user. All I need is ONE API key for ONE account. But I'm forced to use OAuth. It doesn't seem appropriate, and it's especially concerning that the "flow" requires the (non-expiring!) Access Token to be shared with a third party server. Why?!?

I recently learned that Stripe has been pushing OAuth (branded as "Stripe Connect") to its integration apps as the "more secure" solution, compared to Restricted API Keys. In fact, we've found that most integrations we've encountered that use Stripe Connect are less secure than using Restricted API Keys because the (private!) tokens are shared with a third party!

I've been using Stripe to handle credit card payments on my e-commerce website for years. Recently, we updated our wordpress e-commerce website and all its plugins. And then we discovered that all credit card payments were broken because our Stripe Payment Gateway plugin stopped allowing use of Restricted API Keys. Instead they only support "Stripe Connect" (which, afaict, is a marketing term for OAuth). This change forced us to do a security audit to make sure that the new authentication method met our org's security requirements. What we found was shocking.

So far we've started auditing two woocommerce plugins for Stripe, and both have admitted that the OAuth tokens are shared with their (the developer's) servers!

One of them is a "Stripe Verified Partner", and they told us that they're contractually obligated by Stripe to use only "Stripe Connect" (OAuth) -- they are not allowed to use good-'ol API Keys.

They also told us that Stripe REQUIRED them to include them in the OAuth flow, such that their servers are given our (very secret!) OAuth Access Keys!

The benefit of normal API Keys, of course, is that they're more secure than this OAuth setup for (at least) two reasons:

1. I generate the API keys myself, and I can restrict the scope of the keys permissions

2. I store the key myself on my own server. It's never transmitted-to nor stored-on any third party servers. Only my server and Stripe's servers ever see it.

Can someone shine a light onto this darkpattern? I understand that standardization is good. OAuth Refresh Keys add security (this service doesn't use them). But why-oh-why would you FORCE OAuth flows that share the (non-expiring) Access Tokens with a third party? And why would you claim that's more secure than good-ol-API-keys?

Does OAuth somehow not support server<-->server flows? Or is it a library issue?

What am I missing?

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

• https://nantes.indymedia.org/posts/87395/une-lettre-divan-enferme-a-la-prison-de-villepinte-perquisitions-et-disques-durs-dechiffres/

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

• https://tails.boum.org/security/argon2id/index.en.html

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

• https://mjg59.dreamwidth.org/66429.html

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

• https://nantes.indymedia.org/posts/87395/une-lettre-divan-enferme-a-la-prison-de-villepinte-perquisitions-et-disques-durs-dechiffres/

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

• https://tails.boum.org/security/argon2id/index.en.html

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

• https://mjg59.dreamwidth.org/66429.html

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

• https://nantes.indymedia.org/posts/87395/une-lettre-divan-enferme-a-la-prison-de-villepinte-perquisitions-et-disques-durs-dechiffres/

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

• https://tails.boum.org/security/argon2id/index.en.html

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

• https://mjg59.dreamwidth.org/66429.html

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

• https://nantes.indymedia.org/posts/87395/une-lettre-divan-enferme-a-la-prison-de-villepinte-perquisitions-et-disques-durs-dechiffres/

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

• https://tails.boum.org/security/argon2id/index.en.html

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

• https://mjg59.dreamwidth.org/66429.html

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

• https://nantes.indymedia.org/posts/87395/une-lettre-divan-enferme-a-la-prison-de-villepinte-perquisitions-et-disques-durs-dechiffres/

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

• https://tails.boum.org/security/argon2id/index.en.html

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

• https://mjg59.dreamwidth.org/66429.html

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

• https://nantes.indymedia.org/posts/87395/une-lettre-divan-enferme-a-la-prison-de-villepinte-perquisitions-et-disques-durs-dechiffres/

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

• https://tails.boum.org/security/argon2id/index.en.html

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

• https://mjg59.dreamwidth.org/66429.html

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

• https://nantes.indymedia.org/posts/87395/une-lettre-divan-enferme-a-la-prison-de-villepinte-perquisitions-et-disques-durs-dechiffres/

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

• https://tails.boum.org/security/argon2id/index.en.html

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

• https://mjg59.dreamwidth.org/66429.html

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

• https://nantes.indymedia.org/posts/87395/une-lettre-divan-enferme-a-la-prison-de-villepinte-perquisitions-et-disques-durs-dechiffres/

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

• https://tails.boum.org/security/argon2id/index.en.html

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

• https://mjg59.dreamwidth.org/66429.html

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

• https://nantes.indymedia.org/posts/87395/une-lettre-divan-enferme-a-la-prison-de-villepinte-perquisitions-et-disques-durs-dechiffres/

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

• https://tails.boum.org/security/argon2id/index.en.html

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

• https://mjg59.dreamwidth.org/66429.html

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

• https://nantes.indymedia.org/posts/87395/une-lettre-divan-enferme-a-la-prison-de-villepinte-perquisitions-et-disques-durs-dechiffres/

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

• https://tails.boum.org/security/argon2id/index.en.html

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

• https://mjg59.dreamwidth.org/66429.html

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

• https://nantes.indymedia.org/posts/87395/une-lettre-divan-enferme-a-la-prison-de-villepinte-perquisitions-et-disques-durs-dechiffres/

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

• https://tails.boum.org/security/argon2id/index.en.html

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

• https://mjg59.dreamwidth.org/66429.html

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

• https://nantes.indymedia.org/posts/87395/une-lettre-divan-enferme-a-la-prison-de-villepinte-perquisitions-et-disques-durs-dechiffres/

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

• https://tails.boum.org/security/argon2id/index.en.html

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

• https://mjg59.dreamwidth.org/66429.html

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

• https://nantes.indymedia.org/posts/87395/une-lettre-divan-enferme-a-la-prison-de-villepinte-perquisitions-et-disques-durs-dechiffres/

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

• https://tails.boum.org/security/argon2id/index.en.html

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

• https://mjg59.dreamwidth.org/66429.html