One of the major motivations for the creation of the WordPress REST API is that it allows developers to easily — or more easily — build WordPress client applications. With the API, developers can build applications that can control most aspects of a WordPress site. However, great though the API is, authentication has been a perennial problem for developers. Until recently, the REST APIs authentication systems were “difficult and incomplete,” making it hard for developers to create applications that offered a compelling user experience. Applications would have to be individually registered with each site before they could be authenticated, putting a significant burden on the app’s users.
If a developer made an iOS app for WordPress that allowed for the easy uploading of photos — a sort of personal Instagram — that application would have to be registered on each site to which it would be authenticated to upload images. Ideally, a user should be able to install the app and then authenticate with their site and account, regardless of whether the app had previously been registered on the site.
For services like Facebook, this is not so much of a problem — an application that needs to authenticate with Facebook to access a user’s account need only register in one place — with Facebook.
There are millions of WordPress sites that an application may want to authenticate with, and registering on each of those sites is next to impossible — not to mention the terrible user experience it creates. That developers would have had to make such demands on their users was probably holding back the development of applications that made full use of the REST API.
The Authentication Broker — recently announced by WordPress — was created to make the process more straightforward. It is a central system with which individual WordPress sites register using a broker client.
Under this system, when a user wants to connect an application to their site or a site on which they have an account, the application communicates with the broker, which then asks the site to register the application and issue credentials, which are passed back to the application via the broker. Once that’s done, the application is able to authenticate with the WordPress site using the usual authentication process (OAuth 1 in this case).
Both the authentication server and client are open source, and it’s possible for an organization to use the broker application to set up an internal authentication broker, allowing companies to register their own sites and only allow specific applications to authenticate.
Authentication is a difficult problem, especially distributed authentication. The WordPress Authentication Broker is an excellent step towards the creation of a truly secure and distributed WordPress ecosystem.