That's bad.

OAuth supports several types of flows. If I'm not mistaken (I've learned a bit more about OAuth since yesterday) you're describing the Authorization Code Flow -- as documented in RFC 6749 (The OAuth 2.0 Authorization Framework), Section 4.1 (Authorization Code Grant):

• https://www.rfc-editor.org/rfc/rfc6749.html#section-4.1

That RFC defines many other types of flows that do not require sharing the access keys with a third party, such as the Client Credentials Flow, as documented in RFC 6749 Section 4.4 (Client Credentials Grant):

• https://www.rfc-editor.org/rfc/rfc6749.html#section-4.4

The only reason you'd want to use the Authorization Code Flow is if the third party needs your access token for some reason, or if you want to hide the access key from the user agent.

The problem here is that Stripe is using the wrong flow (the third party doesn't need the access token, as they claim they never save it anyway). And if keyCloak only supports that one flow, that's would be a problem too (in this case).

Upon further reading of RFC 6749, it appears that OAuth does require this -- sometimes.

It depends on the OAuth Flow. In this case, Stripe uses the “Authorization Code” Grant.

This is documented in Stripe’s OAuth reference documentation here:

 undefined

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

  

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

Authorization Code Grants are defined in RFC 6749 (The OAuth 2.0 Authorization Framework), Section 4.1 (Authorization Code Grant):

• https://www.rfc-editor.org/rfc/rfc6749.html#section-4.1

To better understand why the OAuth Authorization Code Grant requires sharing the access token with a thrid party server, I found this article (Common OAuth Vulnerabilities) by Doyensec very elucidating:

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

It says that the Authorization Code Flow is supposed to be used when you don’t want to share the tokens with the user agent.

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.

But this doesn't make sense for this use-case. It appears Stripe is needlessly putting us at risk by choosing the Authorization Code Grant.

Stripe Connect does not support Client Credentials flow.

Can you please tell me what is the name of the "flow" that Stripe Connect is using here?

I figured out the root technical cause. 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.

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

Finally someone directs me to the actual RFC. Except that section is titled "Client Credentials Grant"

• https://www.rfc-editor.org/rfc/rfc6749.html#section-4.4

Why do I see this sometimes called a "Grant" and sometimes called a "Flow"?

What's the definition and difference of each?

Thanks, but I don't think this is the case here. The Authentication provider is Stripe (or, at least, it's a stripe.com domain name). The 3rd party is the app developer's server.

Stripe's infra is already PCI compliant.

I'm not sure how a hardware security token would be relevant here. The end result must be something-you-know access token. Initial setup is done with 2FA, sure. But I don't think the server can store (or emulate) a passkey. The issue here isn't how I authenticate with Stripe. It's after that -- when Stripe gives the tokens to the third party (the dev's server) and then the third party gives the token to my server. I don't understand why Stripe doesn't just let the devs implement it so Stripe gives the tokens directly to my server.

It doesn't say porn, it says adult. The legend describes how it's determined

Adult "Yes" means there's no profanity filters or blocking of NSFW content. "No" means that there are profanity filters or NSFW content is not allowed.

how do you do that? Is there a guide anywhere for how to setup mastodon seeing lemmy or lemmy seeing mastodon?

I think at the top, just above the "Recommended"

<h2>

 undefined

    
For a more detailed comparison of Lemmy instances, see:

<ul>
<li><a href="https://github.com/maltfield/awesome-lemmy-instances">Awesome-Lemmy-Instances on GitHub</a></li>
<li><a href="https://the-federation.info/platform/73">the-federation.info Lemmy Instances Page</a></li>
<li><a href="https://lemmymap.feddit.de/">Feddit's Lemmymap</a></li>
</ul>

After you create an account, you can find communites across all instances using <a href="https://browse.feddit.de/">Feddit's Lemmy Community Browser</a>

<h2>Recommended</h2>
...

  

oh shit I wish I knew that existed before XD

I'm literally just asking the instance's API how many users it has:

• https://links.dartboard.social/api/v3/site

Check the users_active_month field. How your instance calculates that is a question for the lemmy devs ;D

I see TypeScript and get scared. Personally, I do think that the join-lemmy.org/instances page should link to:

1. My table comparison https://github.com/maltfield/awesome-lemmy-instances
2. The Lemmy Community Browser (to find communities across all instances) https://browse.feddit.de/
3. The Lemmy Map https://lemmymap.feddit.de/
4. The federation's lemmy page (with another table comparing instances) https://the-federation.info/platform/73

Can anyone with TypeScript experience make this PR for us? Here's the relevant file:

• https://github.com/LemmyNet/joinlemmy-site/blob/main/src/shared/components/instances.tsx

Because I had a bug. Fixing now :)

Hmm, I see community_creation_admin_only is set to false on the API. I'll look into this, thanks for letting me know :)

• https://lemmy.blahaj.zone/api/v3/site

Edit: should be fixed now. Please let me know if you find any other issues :)

Hi Lemmy!

I make BusKill laptop kill cords that make your computer lock, shutdown, or self-destruct if the device is physically separated from you.

This protects your (encrypted) data from theft, which can be useful for digital nomads and cryptotraders working in cafes/coworking spaces. But our target audience is journalists, activists, and human rights workers in oppressive regimes.

• https://buskill.in/

Both the hardware and the software are open-source (CC-BY-SA, GPLv3). We manufacture the hardware with injection molding, but if you have a 3D-printer, then you can take a stab at our 3D-printable prototype.

• https://www.buskill.in/3d-print-2023-04/

...And apparently I'm doing (minor) contributions to lemmy these days too