mikeschinkel 03:55 on October 3, 2013

Securing the WordPress JSON API

Hi all,

Thanks to Ryan for adding me to the team. I’m excited to see WordPress finally embrace a RESTful API and look forward to help in ways that can make best use of my potential contributions.

Speaking of, I wanted to continue the discussion about authentication and make a high level proposal. I was going to post it here but it got too long as to be overwhelming so I decided to dust off my old blog that hasn’t seen any new posts for years; ironically now there are two posts there this week.

Anyway, here it is and I’m going to redirect the comments back here:

Proposal – Securing the WordPress JSON API

mordauk 15:03 on October 3, 2013

I’d love to see the use of API keys over userlogin / password. In my mind, the advantages greatly outweigh the extra code weight we’d need to add.
Max Cutler 15:28 on October 3, 2013

While API keys prevent the user from publicly exposing their password, they are still pretty insecure when not used over SSL. Even if you have an API nonce, it’s trivial for someone in a coffee shop to intercept the API key + nonce and use it before the user’s mobile app uses it.

If you are truly interested in having a secure non-HTTPS API, then you’re going to have to do something like the Amazon API or oAuth 1. Otherwise you are just debating shades of insecurity.

I wasn’t around in the early days of WordPress’ XML-RPC API, but they clearly chose convenience over security. I’d recommend that the JSON API team focus on a quality identity/auth/auth experience over SSL, and focus on community-level options for non-SSL. That might mean a JetPack module to proxy API calls, or working with the popular shared hosts to offer SSL-secured WordPress instances, or just having a public awareness campaign in the community on the merits of purchasing an SSL cert and security your site.
- mikeschinkel 17:23 on October 3, 2013
  
  Hi Max,
  
  Agreed that API keys are not fully secure.
  
  However one of the main points I tried to make in my proposal is that not all API access NEEDS to be fully secure. If we implement API Capabilities we can allow the things that don’t need to be completely secure to use API keys. My guess is that there are a lot of things that do not need to be truly secure. Then we can require SSL (or allow the site builder/owner to override with a constant.) for things that must be secure.
- Ryan McCue 00:26 on October 4, 2013
  
  I wasn’t around in the early days of WordPress’ XML-RPC API, but they clearly chose convenience over security. I’d recommend that the JSON API team focus on a quality identity/auth/auth experience over SSL, and focus on community-level options for non-SSL. That might mean a JetPack module to proxy API calls, or working with the popular shared hosts to offer SSL-secured WordPress instances, or just having a public awareness campaign in the community on the merits of purchasing an SSL cert and security your site.
  
  I think SSL certainly has to be considered, but we definitely need something that works without it. It’s unrealistic to expect that every site is going to upgrade to SSL. Proxying via a centralised service is also not really a solution, although I’d expect that Jetpack would do something like that on top of anything we come up with, for extra security.
Ryan McCue 00:24 on October 4, 2013

My concern with introducing compulsory API keys is that it makes using applications a more complicated process. I’m sure everyone knows the pains of linking your site to Facebook/Twitter and needing to create new applications on the aforementioned sites first. This works OK for most users since there’s a centralised database where things like mobile apps can be registered. On the other hand, for us we don’t have a way of centralising this, and requiring regular users to set up mobile app keys would make the API dead-in-the-water.

One possibility we could look at instead is rate limiting clients (by IP) until they have an access token, making it somewhat of an opt-in system. This way, the barrier to usage is much reduced for most users, but

By the way, I don’t think this is really authorization vs authentication, it’s more like client authentication vs user authentication. Authorization is separate, although still involved. Both client authentication and user authentication need to be discussed though.

I actually think the best solution here is Amazon-like authentication, which is actually really similar to OAuth 1. I think what we should do is use this type of system with GitHub-style upgrading: send a first request with Basic authentication, then swap that out for a token you get back.
- mikeschinkel 01:10 on October 4, 2013
  
  To be clear I wasn’t suggesting API keys for all use cases but instead as the primary means and then to utilize an escalation of security requirements for API services that require more security as proposed in this table.
  
  As I mentioned one approach is to offer an API service to retrieve an API key and require a separate authentication means to retrieve that key, such as the Amazon-style approach or SSL. That way the WordPress mobile team could easily implement an app that requests the API service with the harder-to-implement Amazon-style authentication or SSL+username+password to retrieve an API key (and the WordPress team should have no problem getting that to work compared to the motivated yet n00b site owner) after which the WordPress.org mobile app could use the API key for most other API services.
  
  Doing the above would retain the trivially-easy method of using API keys for writing API service calls where the would-be developer can use a browser as an exploratory device/debugging tool and an API key grabbed from the admin but there would be a higher security bar + ease of use for end-users for those who want to simplify getting the API key for their end-users.
  
  Offering API keys like this favors those who might be able to inch their way into learning how to work with API keys rather than force the Amazon-style auth on them from day one. I’m sensitive to the latter’s difficulty because it was overwhelming for me when I first had to deal with it.
  
  And this approach is pretty much what you suggested above regarding GitHib-style upgrading where you get a token back. So what’s the real difference between a token and an API key anyway, other than the name chosen to identify the concept?
  - Bryan Petty 22:12 on October 9, 2013
    
    Keep in mind that differentiating between required authentication methods depending on the request type/endpoint being used is really discriminating towards the types of clients and uses of the API as opposed to simply requiring *some form* of auth (regardless of the type) for certain types of requests providing access to sensitive data. I don’t think we should discriminate on that at all, and while you might think that’s giving up security in some cases, it’s really not our responsibility to enforce it. That really is up to the client and the admin of the blog being used (they could potentially install additional plugins providing higher security much like there’s plugins to handle login attempt limits for example).
    
    The reason I bring this up is because you need to consider cases where it’s not just server-to-server API use, but also themes like O2 that shouldn’t be required to use an API key to avoid request limits based on the number of unauthenticated visitors to the site simply loading a post or comments through the API. O2 would never have API keys for anonymous visitors.
    
    JSON REST APIs are frequently used for a much wider array of legitimate use cases than even XML-RPC, so we will very likely be required to ease up on required forms of authentication more than the XML-RPC API ever did (which as you said, wasn’t much).