There is a public query form in my web app, and architecture team asking to authenticate the web app with OAuth2 like this, but I don't believe it will be of any help.
I believe best way to protect is by reCAPTCHA.
Can we prevent DDoS or spam form submission by using client authentication?
tl/dr: Client authentication in the browser is useless because browser-based bots will automatically authenticate themselves, and browser-less bots will get stopped by much simpler methods anyway. This isn't really a surprise, because "client authentication" isn't really effective for browsers (and is only slightly effective for other "kinds" of clients). Captcha, unfortunately, is the only real solution, although it cannot protect you from targeted attacks.
I want to clarify a detail from the comments. My understanding is that the goal here isn't to require someone to login to use your form. Rather, you want the client (in this case, the JavaScript app you build which runs in the user's browser) to authenticate with your server, so only people browsing your website can submit your form. This authentication will happen by JavaScript adding an authorization token to the request, and the server rejects any form submissions that don't contain the correct authorization token.
Before I go into details I want to emphasize one important point: it is not possible to restrict someone to only using your "app". Your JavaScript runs on their computer, in their browser. As a result an attacker can easily reverse-engineer your app (which is extremely easy when it is javascript in a browser), determine how it authenticates itself with the server, and then reproduce that in anyway necessary. To try to limit users to only using your app effectively means that you are trying to implement DRM, and it is simply not possible (especially in cases like this). You can make things harder for attackers, but you can't stop them outright. Still, let's discuss your question in more specifics.
In order to protect against spam bots, you first have to understand how they work. There are of course a ridiculous number of varieties, but I'll focus on two general "types" (keep in mind that I've chosen these categories somewhat arbitrarily):
action property on the form. Pretty simple. They will also fake details in the request headers (Origin, User-Agent, etc...) to look more like a regular user.The simple class of bots reads the HTML returned by the server to figure out what kind of request the server is looking for, builds a matching request, and sends it to the server. If your client-authentication process involves using JavaScript to attach additional credentials to the request, then that authentication process will actually stop such bots from executing successfully.
However, it isn't technically the presence of the authentication that keeps the bots out - it is simply the use of JavaScript that stops them, because the bot doesn't know anything about steps that JavaScript takes. For this class of bots, you could just as easily have JavaScript intercept the form submission, add some predetermined data to the request (imagine it adds something like not_a_bot=true to the request data), and submit it with Ajax. The server then rejects any requests that don't include that not_a_bot=true flag. This sort of incredibly simple check will stop bots that don't execute your JavaScript. In fact, I've actually used this in production systems and it dramatically cuts down on bot submissions. The only downside is that it also locks out users that don't have JavaScript enabled (which your proposed client authentication method also does).
So, will your authentication step help? Yes! However, only by accident, and there are much simpler ways to accomplish the same thing.
However some bots work by using an actual browser, which means it runs any JavaScript passed down by the server. As a result any sort of automatic authentication step that is executed by your JavaScript will automatically happen for these kinds of bots as well. In fact, it is nearly impossible to differentiate between these bots and regular users.
This means that whether you secure your form by adding the not_a_bot=true flag in JavaScript, or whether you secure it by having JavaScript add in an authorization token to the request, these bots will take the same exact steps and the server will accept the spam submission. The attacker won't even have to reverse engineer your app - your own JavaScript will allow the spam bot to circumvent your protections.
How do you stop these bots from filling out your forms? There's only one cost-effective solution: a captcha system (although even that isn't a guarantee).
DDoS is not even worth a mention. A DDoS attack works by simply flooding the server with so much traffic that it cannot keep up. While there are some kinds of DDoS attacks that might be prevented by trying to ignore submissions from bots, the most common kind won't be. Many DDoS attacks work by simply sending so much network traffic to your infrastructure that there is not enough bandwidth to keep up. When that happens there is nothing that can be done at the server level to stop the DDoS attack. Completely different strategies (mainly at the network-level) are required there. Whoever suggested that this might help against a DDoS simply doesn't understand how such attacks work.
So after breaking things down we can see that client authentication provides absolutely no benefit. It would stop simple spam bots, but only because it requires JavaScript which simple bots don't execute. Instead there are much simpler steps which would stop these kinds of spam bots anyway. Moreover, the client authentication will provide no protection against bots that use actual browsers to do their job. Nothing will stop those, although a good captcha may at least discourage drive-by-bots that aren't specifically targeting you.
