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):
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):
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).
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.
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.
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>
...
maltfield @ maltfield @lemmy.ml Posts 4Comments 10Joined 2 yr. ago 
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):
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):
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).