On Thursday of last week, we had an Authentication chat in #core-passwords — truth be told, the discussion spilled over into Friday and a bit on Saturday as well. I delayed posting this summary a bit to make sure there wasn’t anything else about to be said that I’d miss.
Spoiler alert: we didn’t decide anything conclusively, it was more brainstorming and voicing possibilities.
Also worth noting is that we place equal weight on the user experience of the authentication system as we do on the security when evaluating it for core. That isn’t to say that we value the security any less, but rather that we also view the UX as critical to nail down as well, and is likely easier to suss out problems earlier on in casual conversation than evaluating the eccentricities of crypto. So if some of the discussion tended more towards UX considerations than Security considerations, be aware that both are critical, we were just tending to evaluate the UX first, as it’s an easy litmus test for whether a particular method is worth pursuing, and more easily understood by more people than the intricacies of replay attacks and the sort.
There were two major areas of discourse that were addressed: Authentication Scheme, and Authentication Scope.
The scheme would be one of several possibilities, such as OAuth 1.0a, OAuth 2, Application Passwords sent as Basic Authentication, or some other either ad-hoc or previously unconsidered system.
There are assorted concerns with various systems:
- HTTPS — WordPress cannot guarantee that the site will be hosted on a HTTPS infastructure, and as such, any API tokens passed along with the request could potentially be sniffed in transit. However, if the site doesn’t have HTTPS available, the same thing happens on every page you view already with your authentication cookies. The major difference being that cookies become invalidated on logout or expiration, so cookie thieves have a smaller window to exploit the stolen authentication than tokens that are valid until revoked.
- OAuth Application Registration — The user experience flow for OAuth can be particularly tricky. Imagine it: You’ve just installed an app on your phone, and you want to link it to your user account on your WordPress site. Your steps are as follows: Log in to your WordPress site, Create an AppID for the phone app, give the phone app it’s Secret tokens. Now from the Phone app, you click a button to go back to your site and approve the link to your user in the application and exchange user access tokens. That is a /lot/ of back and forth-ing. It could be simplified somewhat if there was some sort of central repository for all WordPress sites that apps could register at, and then .org sites could dynamically pull down public keys for applications that they can use to verify the secrets in the apps, but that then becomes a significant amount of overhead for the construction and maintenance of the application ‘clearing house’ and it’s been clarified that it is not something that WordPress.org (the website) is up to build or host. Long story short: this UX flow is so confusing that it really feels much more like plugin territory at its current iteration.
Probably some other points I’m missing, but those felt like the major two.
The second issue at hand is one of Authentication Scope. That is, when an application authenticates, what functionality is it permitted to do?
This is significantly different from user capabilities. We had discussed an extra field when auth’ing applications where you could ‘downgrade’ your user role for that application’s API requests (that is, if you’re an Administrator, you could only give an application Author capabilties), but that doesn’t really solve the issue — as every user role has the ability to — for example — update their password or email address. And if an application can do that, then that’s the ballgame, and they can log in to wp-admin as you and do whatever they like.
We also talked about perhaps just disallowing certain functionality from ever being used as a part of the REST API. However, with the rise of third-party site management applications, such as Calypso, or if other programs like ManageWP or InfiniteWP or whatever the other half dozen ones are wants to truly manage your site, they’ll need access to that functionality. After all, what’s the point of aiming at eventually achieving REST API parity with the wp-admin experience if it can’t be used anywhere outside of wp-admin?
The solution we seemed to be leaning towards is a ‘two-tiered’ scope system. That is, provide a default ‘content’ tier — akin to the functionality of the legacy XML-RPC API — that can support writing and updating posts, taxonomies, comments and the like (and any custom endpoints that are explicitly opted in to the limited tier), and a second ‘full control’ tier that allows access to everything — plugins, themes, users, what have you. The second tier would be suited for full control applications like Calypso or remote management tools, whereas the first more limited tier would be more than adequate for the functionality in the legacy WordPress mobile apps, or blogging applications like Desk or Microsoft Word integration. It’s simple enough for users to understand, and technologically could be passed in via the `$args` array to `register_rest_route()` whether an endpoint should be available or not.
Still with us? Thanks for slogging through a somewhat lengthy summary, we’d love to hear your thoughts below on anything you think we missed or didn’t consider sufficiently in depth.
If anyone would like to read the full discussion, it starts here in the Slack logs: https://wordpress.slack.com/archives/core-passwords/p1455832859000040