JS clients are called public client
https://tools.ietf.org/html/rfc6749#section-2.1
The sentence below means Ajax-only restriction can be such a method, but it shouldn't be higly trusted.
The authorization server MAY establish a client authentication method with public clients. However, the authorization server MUST NOT rely on public client authentication for the purpose of identifying the client.
NOTE: For native clients, faking ajax client is relatively easy. This is one of the accepted risks when using Ajax-only restriction as client authentication.
https://gist.github.com/nov/929da99bbae065cb67a951f3eee5c21c
https://tools.ietf.org/html/rfc6749#section-2.3
This section is allowing public clients not to authenticate to the token endpoint, but there is no alternative recommendation. It means developers who decided not to use client authentication needs to design alternative way by their own, or needs to accept risks caused by not using client authentication.
https://tools.ietf.org/html/rfc6749#section-3.2.1
OAuth PKCE extension is the only alternative of client authentication which is RFC-ized in IETF. (but it's for native apps which can store code_verifier securely)
https://tools.ietf.org/html/rfc7636
OAuth Token Binding extension is also beeing specified as client authentication alternative, but it's still in early stage and much complex than PKCE. (it also requires clients to store private key securely)
https://tools.ietf.org/html/draft-ietf-oauth-token-binding-01
For JS clients, I've drafted this spec which allows keep access tokens and API access code in iframes so that they are not accessible by JS code in main window. But this spec is also in early draft stage yet.
https://tools.ietf.org/html/draft-sakimura-oauth-wmrm-00
Google is also drafting "IdP iFrame, in which IdP (= API server) provides an iframe which does whole token lifetime management task in it. But it's not published to IETF, instead it's published to OpenID Foundation. And still very early stage.
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20151116/005865.html
This section also allows public clients not to authenticate to the token endpoint as below.
If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.
https://tools.ietf.org/html/rfc6749#section-4.1.3
OAuth PKCE extension is a possible alternative here too.
Refresh token is issued in code flow.
https://tools.ietf.org/html/rfc6749#section-4.1.4
This flow doesn't utilize token endpoint. It means there are no client authentication.
So that this flow is for public clients.
https://tools.ietf.org/html/rfc6749#section-4.2
Refresh token isn't intended to be issued to public clients as below.
The authorization server MUST NOT issue a refresh token.
https://tools.ietf.org/html/rfc6749#section-4.2.2
This flow requires highly trusted client. As section 2.3 described, public clients authenticated via Ajax restriction shouldn't be higly trusted.
The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application.
https://tools.ietf.org/html/rfc6749#section-4.3
Since this flow doesn't utilizes authorization endpoint, there is no chance for users to see what scopes the client is requesting. It means this flow allows client to specify any scopes which is allowed to the client except for user consent. If a client has wide scope access and no client authentication is performed, other apps can acts as the client and use this flow to get wider scope access than it's actually allowed.
This flow is originally designed for migration from Basic Authentication which was still widely used when OAuth2 spec is discussed. In that situation, letting existing clients exchange the stored password with accesss & refresh tokens and throw away the stored passwords was the motivation to support this flow. But if the API has never support Basic Authentication, there are no such motivation.
This flow is also designed for apps running UI-restricted devices, but this extension is going to be used for such situations.
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03
So this flow shouldn't be the first choise anymore. And hopefully, no new API servers support it.
This section also allows public clients not to authenticate to the token endpoint as below.
If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.
https://tools.ietf.org/html/rfc6749#section-6
OAuth PKCE extension is a possible alternative here too.