proposal/discussion: OAuth - disallow web application to be OAuth public client (and to have direct communication with OAuth token endpoint)

[elarlang]

spin-off from #1916 "Discussion/Proposal 1"

The summary for browser based communication says:

To summarize, the architecture of a browser-based OAuth 2.0 client application is straightforward, but results in a significant increase in the attack surface of the application. The attacker is not only able to hijack the client, but also to extract a full-featured set of tokens from the browser-based application.

This architecture is not recommended for business applications, sensitive applications, and applications that handle personal data.

Write requirement (preferred) or at least "really strong recommendation" to avoid architecture where the browser communicates directly with authorization server token request and handling access token and refresh token.

Or in OAuth terminology, that OAuth confidential (and not public) client is used.

May be limited to first-party solutions.

It requires quite a strong change to widespread attitude, as with using SPA architecture, often the browser uses directly OAuth service, including token endpoint.

--
Feedback from @tghosth in #1916 (comment)

that sounds like a sensible extra requirement for L2 and L3
Overall it seems like things in Section 7 are to be banned altogether and the Browser-based OAuth 2.0 client.

--
Overlap by recommendation from @TobiasAhnoff in #1925

8 Verify that access and refresh tokens are not accessible by Javascript

--

So the question is - are there valid reasons to not disallow it?