danielpunkass
commented
4 years ago This ticket was inspired by conversation in a Slack thread: https://wordpress.slack.com/archives/C02RQC26G/p1580745738095300
Open danielpunkass opened 4 years ago
danielpunkass
commented
4 years ago This ticket was inspired by conversation in a Slack thread: https://wordpress.slack.com/archives/C02RQC26G/p1580745738095300
Summary: supporting a method for obtaining a REST API authentication token over XMLRPC would allow existing XMLRPC clients to start migrating to the REST API in absence of a full-blown oauth2 solution in core.
For years, clients of the XMLRPC API method, who need to authenticate outside the scope of a web browser, have been unable to take advantage of the REST API without special plugins to accommodate authenticating for the API. This limits adoptions of the API because XMLRPC clients are often developing products that are intended to be used by a broad spectrum of WordPress end-users, who may not have the inclination or ability to configure sites with custom plugins, etc.
These clients include 3rd party app developers such as myself (https://red-sweater.com/marsedit) and probably most notably the WordPress native mobile apps.
Longer term, there is talk of an oauth2 solution for authentication that could open up access to the API to these clients. In the absence of such a solution, it might be pragmatic to offer these clients a path through XMLRPC that grants access to the REST API.
Because the changes would be limited in scope to the XMLRPC API, which already supports inherently less secure authentication methods, it wouldn't be a substantive change in the security of a typical WordPress installation. Sites that, for example, disable XMLRPC would implicitly disable this enhancement as well.
In fact, any client who adopted this method for obtaining an authentication token would be immediately increasing the security of a user's site by abstaining from further use of the username/password for every request, which is what XMLRPC requires today.
One consideration is whether the authentication token granting access to REST offers greater access to the installation than a current XMLRPC authentication. If this is true (and very well might be), then you might consider limiting the scope of access for these XMLRPC-based tokens such that they only offer the same degree of access comparable to what the XMLRPC API allows.