I think you misunderstood what I said. The API key I don't want to expose is the one that is required to register the user with the newsletter service, not the client key for the OAuth service.
The title of the article says OAuth, and hence assumed that you wanted an authenticated client to be able to make the call to the backend for subscribing.
This is what is happening, except instead of a backend endpoint hosted on my own VPS, I'm using a Cloudflare worker.
"The title of the article says OAuth, and hence assumed that you wanted an authenticated client to be able to make the call to the backend for subscribing."
An authenticated client is necessary in order to retrieve the email of the client.
The conflating part here is that using the callback as a mechanism to imply subscription.
This works for your situation.
However, if you need to start making multiple backend calls, then, you will likely need to separate the authentication part from the subscription part.
Generally, OAuth implies that the requirement is to get authenticated by a provider and making multiple subsequent calls to some backend. Additionally, the backend will verify the authenticity of the short-lived token before allowing the operation to proceed.
OAuth uses a client key and/or a client secret, for the application that is requesting access on behalf of the client.
While non-human client-credentials can be used in-conjunction with a human-user's credentials it's largely unnecessary as an unauthorized client wouldn't be able to authenticate with a human-user because the redirect_uri sent from the client would be rejected automatically (and if that worked, there's always 'aud' audience filtering too), so the human-user wouldn't even be prompted to authenticate, they'd get an error message.