The answer to your question can be at the code level, protocol level or architecture level. I will attempt to summarize here most of the protocol level issues since that is usually critical in pros and cons analysis. Keep in mind that OAuth2 is much more than Resource Owner Password Credentials which, according to the specification, exists for "legacy or migration reasons", is considered "higher risk than other grant types" and the specification explicitly states that the clients and authorization servers "SHOULD minimize use of this grant type and utilize other grant types whenever possible".
There are still many advantages of using ROPC over basic authentication but before we get into that, let's understand the basic protocol difference between OAuth2 and basic authentication. Please bear with me as I explain these and will come to ROPC later.
User authentication flows
There are four roles defined in OAuth2 specification. With examples, they are:
- Resource owner: The user who has access to some resource, e.g. in your case, different users may have different access level to the REST API;
- The client: usually the application the user is using, and needs access to the resource to provide services to the user;
- Resource server: the REST API in your case; and
- Authorization server: the server to which user's credentials are presented and which will authenticate the user.
When a client application runs, it is granted access to the resources based on the user. If a user has administrator privileges, the resources and operations available to the user in REST API may be far more than a user without administrator privileges.
OAuth2 also allows the possibility of using a single authorization server with multiple clients and for multiple resources. As an example, a resource server can accept user's authentication with Facebook (which can act as authorization server in such a case). So when the user runs an application (i.e. the client), it sends the user to Facebook. User types their credentials in Facebook, and the client gets back a "token" which it can present to the resource server. Resource server looks at the token and accepts it after verifying that Facebook in fact issued it and allow the user access to the resource. In this case, the client never sees user's credentials (i.e. their Facebook credentials).
But let's say you are managing your user's identities (and have an authorization server) instead of Facebook, which grants tokens to your client already. Now, let's say you also have a partner and you want to allow their application (i.e. client) to access your REST API. With basic authentication (or even ROPC), the user will provide credentials to that client which will send it to the authorization server. Authorization server will then provide a token that can be used by the client to access the resources. Unfortunately, this means that user's credentials are now visible to that client too. However, you would not want a partner's application (who could be external to your organization) to even know a user's password. That's a security issue now. In order to achieve that goal, you would want to use another flow (such as the authorization code grant) in which the user directly provides credentials to the authorization server.
Thus, with OAuth2, one would ideally not use ROPC in such cases rather use a different one, such as authorization code flow. This protects any application from knowing the user's credentials which are presented only to the authorization server. Thus, a user's credentials are not leaked. The same issues apply with basic authentication, but in the next section, I will explain how ROPC is still better because the user's credentials still do not need to be stored by the client in ROPC for persistent access by the clients.
Note that when the user goes to the authorization server, the authorization server can also ask user to confirm that they want to allow the client to access the resources on their behalf or not. That is why it is called the authorization server because the process of authorizing a client to access resources is entailed in the process. If the user does not authorize the client, it will not get access to the resources. Likewise, if the user themselves do not have access to the resources, the authorization server can still deny access and not issue a token.
In basic authentication, even the authorization server and resource server are combined into a single entity. Thus, the resource server wants to authorize the user, so asks the credentials from client. The client furnishes those credentials which are used by the resource server to authenticate the user. This means that multiple resource servers will essentially be requiring credentials from the user.
Token issuance
The clients get tokens from authorization server, keep them around and use those to access the resources (more details on tokens themselves below). The clients never know the user's password (in flows other than ROPC) and do not need to store it. In ROPC, even though the clients do know the user's password, they still do not need to store it because they use these tokens to access resources. By contrast, in basic authentication, if a client does not want to have user to provide credentials in every session, then the client has to store the user's password so they can furnish it the next time around. This is a major drawback to using basic authentication unless the client is only a web application in which case, cookies can address some of these concerns. With native applications, that's usually not an option.
There is another aspect of OAuth2 which is entailed in how tokens are issued and they work. When a user furnishes credentials to the authorization server (even in ROPC), the authorization server can give one or more of the two types of tokens: 1) access token, and 2) refresh token.
Access tokens are sent to the resource server which will grant access to the resources after validating it, and usually they have a short lifetime, e.g. 1hr. Refresh tokens are sent to the authorization server by the client to get another access token when it expires, and usually have a large lifetime (e.g. a few days to months or even years).
When the client provides the access token to the resource server, it looks at the token and after validating, looks inside the token to determine whether to allow access or not. As long as access token is valid, the client can keep using it. Let's say the user closes the application and starts it the next day, and the access token is expired. Now the client will make a call to the authorization server and present the refresh token assuming it's not expired. Authorization server, since it already issued the token, verifies it and can determine that the user does not need to provide the credentials again and thus gives another access token to the client. The client now has access to the resource server again. This is how typically the client applications for Facebook and Twitter ask for credentials one time and then do not require the user to provide credentials again. These applications never need to know the users credentials and yet can access resources every time user starts the application.
Now the user can go into the authorization server (e.g. in their Facebook user profile), change password without impacting any client applications. They will all continue to function properly. If the user loses a device on which they already had an application with refresh tokens, they can tell authorization server (e.g. Facebook) to "log them out" of those applications which the authorization server (i.e. Facebook) will accomplish by not honoring any existing refresh tokens and forcing the user to provide credentials again when they try to access resources through those applications.
JWT is simply the token format that is usually used with OAuth2 and OpenID Connect. The methods of signing the token and validating it is also standardized with libraries available for those instead of every resource server implementing yet another solution. Thus, the advantage lies in reusability of code that has been vetted and continues to be supported.
Security implications
Basic authentication will be weaker when any of the above scenarios are in the picture. There is also an extensive threat model for OAuth2 available for developers who can use the suggestions in it to avoid common vulnerabilities in their implementations. If you go through the threat model, you will see that many implementation related vulnerabilities (such as open redirector and CSRF) are also covered in it. I did not go through comparison of those against basic authentication in this response.
The last major advantage of OAuth2 is that the protocol is standardized and multiple authorization servers, clients and resource servers honor it. Numerous libraries are available to developers, which are maintained so as security issues are found in implementations, the libraries are updated while allowing interoperability.
Conclusion
If you are writing a new application, IMO, the ideal case would be to avoid both the basic authentication and ROPC because of the issues inherent in them. However, each application has different needs, timelines, developer proficiency etc. so the decision is case-by-case. But even if you did not have any more need than basic authentication, by choosing it, you could lock yourself into an architecture that may not be easy to extend (e.g. if you have multiple servers in the future, you would not necessarily want to have the user provide credentials to each one of them rather just provide to authorization server once, which can hand out tokens, etc.)
Note that I did not address your comment about how the credentials are sent over the wire because those can be secured using TLS or a similar protocol, or proof of possession etc. As someone already suggested, base 64 encoding is 0 security, please do not be deluded by that. The differences mentioned above are usually at the architectural level and thus that is where I focused because architecture is the hardest to change once implemented.
Azure Active Directory B2C Basic, a service which I work on and was recently released for public preview, allows third party application to use AAD as the authorization server with interoperability with social IDPs (such as Facebook, Google, etc.). It also allows users to create their own accounts instead of using social IDPs and those can later be used for authentication purposes. There are a few other services also like that (e.g. another one I know of is auth0) which can be used by developers to completely outsource authentication and user management for their applications and resources. The same protocols characteristics that I mentioned above is used by developers to decouple authorization server (AAD), a resource (e.g. their REST APIs), the client (e.g. their mobile applications), and users. I hope this explanation helps somewhat.
Best Answer
Let's get this started with a very basic answer.
JWT (as used in the context of OAuth and OpenID) does not require shared secrets between client and API. There are 3 components and pairs of 2 share a secret each: client <-> identification server, identification server <-> API.
This moves most complexity from the API to the identification server, the API just has to check that the token was issued by the identification server and was not tempered with. To verify that the API checks that the JWT-signature is valid with the known single shared secret between identification server and API. That's it!
How the identification server validates the user identity can vary widely (in many cases it's the old username+password pair over a TLS-connection), but is of no effect on your API.
Privacy and security of the message and the token itself when using JWT are handled by TLS, JWT is ignorant of such issues.