OAuth with client secrets is fundamentally unsuitable for desktop and mobile applications, but that hasn't stopped virtually every major implementor from using it that way. The people who wrote the spec were too busy congratulating each other and downplaying concerns to seriously engage with this issue until it was much too late to do anything about it.
It remains a deeply broken standard, and the people who were responsible for it at an early stage are entirely to blame. Several of them have removed their names from the spec, but I'll not forget the role they played in shouting down critics who raised concerns about this very issue.
The spec has been clear from the start that there are clients that can protect their secrets, and ones that can't [1]. Here's a choice quote: "A native application is a public client installed and executed on the device used by the resource owner. Protocol data and credentials are accessible to the resource owner. It is assumed that any client authentication credentials included in the application can be extracted." Unfortunately, much of the rest of the spec is a bit like a playing puzzle, where reading it in one sitting doesn't actually build your understanding, and you have to constantly cross-reference various sections to construct a complete picture of the process the spec is trying to set.
It look a long time for people's familiarity with the spec to grow, and for providers and clients to improve in quality and adherence to the ideas and text of the spec.
Of course that is if the OAuth provider allows it.
That's the catch. Last time I checked, at least Google didn't. So how can you write a (F)OSS email application for accessing GMail via OAuth2, without putting the secrets into the code (which Google also forbids)?
[0]: https://developers.google.com/identity/protocols/oauth2
[1] https://developers.google.com/identity/protocols/oauth2/nati... [2] https://web.archive.org/web/20150520223809/https://developer...
"Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects."
That's why the best option is to set up a secure middleware layer to hold your secrets. Here's an example using react: https://fusionauth.io/blog/2020/03/10/securely-implement-oau...
(Full disclosure, this is a post on the blog of the companyfor which I work.)
It's really the implicit grant (where access tokens are available to the client) that should be avoided.
From https://tools.ietf.org/html/rfc7636
"OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy")."
At the end of the day, no matter what the grant, if you store the access tokens (or refresh tokens) in the browser running an SPA, it is vulnerable to an XSS attack, right?
My understanding is that that is suboptimal because the browser has such a large surface area to secure.
Edit: This seems pretty new, any timeline for a release?
If the user doesn't want to use your service, they configure their own key.