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.
In that case you could create a backend endpoint that accepts a request and makes the call with the API key on behalf of the client/front-end.
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.
"In that case you could create a backend endpoint that accepts a request and makes the call with the API key on behalf of the client/front-end"
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 + OIDC only uses client-secrets when using the client_credentials flow, which is only for us with non-human software, or when a client needs to authenticate and authorize itself independently of any human user. When humans are involved you won't be using client_credentials, you'll be using 'implicit' or 'code' (preferably with PKCE) - but ONLY when the client can actually safely store secrets - so static-website SPAs simply can't.
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.
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.