What do you mean by that? An API key usually is the secret. And everything needed to access the API must by definition be contained in the client app, so it's only a question of reverse engineering enough of it to extract these parameters.

This is why I get paid big bucks to investigate and remediate security problems in applications and systems.

It is technically impossible to embed a "secret" into something you allow everyone to download, and expect it to stay secret forever. This is called security through obscurity and it isn't real security.

This I know. What keeps me employed is knowing how to construct a client that doesn't embed a secret yet manages to perform an authorization flow.

This is in-fact the precise use case of secure enclave remote attestation. Maybe the GCHQ will be able to run their own Reddit clients, but the average person or even experienced hacker will not.

I have no idea what cratermoon is intending to talk about, but the usual way to solve this problem is attestation. At a high level, the client device has the secret, but it is embedded in a secure enclave that makes it difficult to extract. You then build a chain of trust from that secret that attests that the binary being run is the official one.

Android (at least with the standard Google services) seems to provide an implentation of this through the play integrety API [0]. I'm not familiar with the internals of that system, but I have worked on this type of system for a much more constrained use-case.

If I were designing this, my first pass at a napkin design would be:

* Devices running the app must have a TPM. This TPM is loaded with a private key that is intended to remain highly secret. Corresponding public key is well known.

* During boot, "everything" is measured into the TPM's Platform Configuration Registers (PCRs). To measure something into a PCR, you update the PCR value as: PCR[n] = hash(PCR[n] || measured_value).

* The TPM does not (in this use-case) have a notion of what the "correct" values of the PCRs are. However, it can use the secret key to sign the PCRs values. Forging this signature would require either breaking the underlying crypto, hacking the TPM, or learning the secret key contained within the TPM. To prevent replay attacks, the TPM includes a nonce sent by the server.

* The device sends the server a list of what firmware/kernel/OS it is running (everything that was measured into the TPM). The server determines what the PCR values for the claimed configuration should be, and validates the signature that the TPM generated

* You now know that the OS is "trusted", and can now trust the OS to verify that the app is signed by a given public certificate and is running in a sufficiently secure environment.

[0] https://developer.android.com/google/play/integrity

Why authenticate the device and not the user?

How does authenticating the user help? The whole point of the exercise is to block 3rd party apps. It is assumed that the user is authorized to access Reddit through the first party app, so authenticating the user doesn't solve the issue.

That's how oauth2 works. If the app isn't registered with reddit, it doesn't get to act on behalf of the user. No app secrets are necessary, just the user's login credentials, which the app never sees. The resource owner (reddit in this case) can allow or disallow based on the client_id (which is not a secret) and the redirect_uri registered for the app. Reddit, twitter, google, github, apple, and dozens of others handle apps this way.

Client_id is spoofable.

Redirect_uri helps with webapps that run on a standard web browser. However, if the client is not a web app (or, is running under a properly modified web browser), it can simply ignore the redirect.

Oauth2 does contemplate a client_secret field for client authentication. However, such a field is useless on public clients.

The oath2 spec is very explicit that client_id can not be used as a means of authenticating clients.