George Stephanis 8:23 pm on February 23, 2016
Tags: application-passwords ( 4 ), authentication ( 4 ), rest-api ( 107 ), two-factor ( 12 )

REST API Authentication

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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. That isn’t to say that we value the security any less, but rather that we also view the UXUX User experience 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.

Authentication Scheme

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:

HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information. — WordPress cannot guarantee that the site will be hosted on a HTTPS infastructure, and as such, any APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. 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.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party territory at its current iteration.

Probably some other points I’m missing, but those felt like the major two.

Authentication Scope

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-adminadmin (and super 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 APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/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

#application-passwords, #authentication, #rest-api, #two-factor

austinpray 8:45 pm on February 23, 2016

WordPress should support HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information. as the default rather than an enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature..
- George Stephanis 8:55 pm on February 23, 2016
  
  Unfortunately that isn’t something that WordPress has any control over — it’s up to hosts and users, as it’s server configuration.
  - Jeremy Clarke 4:13 pm on February 25, 2016
    
    I’d say WP should imply that all users use HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information., and most hosts (at least Dreamhost) will be making it a default now that Let’s Encrypt makes it free (if not easy) for them to do so.
    
    IMHO having a “if you’re not even running HTTPS how do you expect your app interactions to be secure?” policy would be very fair.
    
    Having an in-coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. solution that is disabled when HTTPS isn’t available also seems fair, and would be a great way to turn up the hustle for hosting providers.
jteague 9:20 pm on February 23, 2016

I realize this throws a wrench into the potential works, but I would not be in favor of either an oauth or app password schema that tries getting around HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information.. I don’t know application cases where HTTPS would not be a requirement up front in the app build process. Certainly none we’ve ever built.

With Let’s Encryptin at near pre-release, and the otherwise very low financial burden on SSLSSL Secure Sockets Layer. Provides a secure means of sending data over the internet. Used for authenticated and private actions. these days, I think it better to take the lead than to encourage poor security or worse the impression of security that doesn’t exist. Thanks.
- thetechnuttyuk 10:25 pm on February 23, 2016
  
  I agree, with Google making moves towards a HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information. only internet anyway, it’s clear that some things have to be purposed specifically for HTTPS for them to grow, putting features like this in HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. is frankly waiting for trouble to happen, it’s also decreasing the reasons that someone should switch.
  
  Not only that, I can’t think of one other application take doesn’t force HTTPS security on things like this, not forcing HTTP is building huge security flaws in WordPress, flaws that hackers will figure out and will use to their advantage.
  
  People should know that the only way to be secure is HTTPS, too many people don’t realise the full dangers of HTTP yet.
Eric Andrew Lewis 10:28 pm on February 23, 2016

I think we should consider cookie-based auth for third party apps, in some form. It is already the de facto auth scheme. The architecture for it exists, we’re familiar with it, and we’ve decided the scheme itself is secure enough to manage your entire WP admin.

We could create app-specific cookies that have limited permission scope (e.g. “this app wants to edit your posts” or “this app wants to edit your posts and your users”).

We could ensure that apps don’t store your credentials by offering a login screen that apps send you to auth the app, similar to OAuth flows (e.g. wp-login.php?requested_permissions=edit_user&edit_posts&sendback_url=https://coolapp.com). After auth WordPress could redirect you back to the site with the app cookie (https://coolapp.com?wp_authed_your_app=true&app_cookie=w33ruhibd32f8yh3rf823yfh3ifn3=).
- George Stephanis 3:50 pm on February 24, 2016
  
  Apart from being relatively fragile, I feel that this is an incredibly dangerous idea.
  
  As soon as an app has your main password, we lose the ability to regulate what the app does. We can’t ‘force’ them to take a weakened privileges cookie, they could just spoof a browser and get a full cookie, at which point they can do anything from deleting all your posts to uploading and activating custom plugins (even ones that are not vetted and in the repository), to changing your user password and email address to entirely hijack your site.
  
  Plus, if they have your plaintext password, there is no guarantee that the app would keep it secure. For example, Pressgram — which operated via XML-RPC — uploaded user passwords in plaintext to a remote server. I don’t like the idea of encouraging users to give their plaintext wp-adminadmin (and super admin) password to any app, from a security and trust perspective. (I’d far prefer an Application Password that can’t be used to access things that aren’t in the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. — it feels much more security conscious).
  - Eric Andrew Lewis 4:39 pm on February 24, 2016
    
    > As soon as an app has your main password
    
    Please note the part where I said “we could ensure apps don’t store your credentials by offering a login screen on [your WordPress site])
    - George Stephanis 4:48 pm on February 24, 2016
      
      Ah, sorry, my mind jumped to our previous conversation.
      
      At the point where they’re not entering their main password — but they are instead just clicking to approve the application and getting the auth token redirected back, that feels very much like a minor UIUI User interface addition to what we’ve built out with Application Passwords.
    - George Stephanis 5:01 pm on February 24, 2016
      
      I just wrote this up as a rough idea for Application Passwords — is it roughly what you had in mind? https://github.com/georgestephanis/application-passwords/issues/36
      - Eric Andrew Lewis 7:54 pm on February 24, 2016
        
        Yes, that looks good.
        
        It seems our visions are merging, and either using app passwords or cookies would be an implementation detail.
      - Jeremy Clarke 4:20 pm on February 25, 2016
        
        +1 This makes sense. The more it feels like authenticating a Twitter/Facebook app the better and so far this sounds similar.
Mike Nelson 1:11 am on February 24, 2016

Wait wait wait… I’d like to take a step back. Why are we so tied up trying to secure the WP APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. authentication for HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. users, meanwhile they’re providing their password to the wp-login page unecrypted EVERY time they log in? If I were a hacker, I wouldn’t care what kind of complex security got implemented for the WP API, I can already just setup on a public wifi and sniffsniff A module for PHP Code Sniffer that analyzes code for a specific problem. Multiple stiffs are combined to create a PHPCS standard. The term is named because it detects code smells, similar to how a dog would "sniff" out food. all requests to wp-login.php for passwords. It’s too easy. I already have a way in.

So let’s assume for a moment we force everyone who wants to use the WP API to use oAuth1a and jump through all those hoops. Great, all those HTTP users’ passwords are safe…. wait, no they’re not. They never were. They’ve provided their password unencrypted over the internet every time they’ve logged in.

If someone doesn’t have HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information. enabled, their password isn’t secure. No matter how secure we make it with the WP API, it was never secure to begin with. They need HTTPS if they want security. Using the WP API securely should start with the assumption that they’re using HTTPS. With that assumption I think we can give users a good experience.

Am I totally off base with these thoughts?
- George Stephanis 3:54 pm on February 24, 2016
  
  I wouldn’t be terribly opposed to the idea of just stating that if a site doesn’t support HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information., that ‘on your own head be it’ basically. If you choose not to support good security protocols, you’re knowingly accepting the risks.
  
  But a lot of users are ignorant of the risks that they’re exposing themselves to, and we need to do what we can to keep them safe. As developers, that’s our job.
  
  So it’s tricky. There is no truly great solution that we’ve found yet. OAuth 1.0a uses a secret to ‘sign’ requests to the site so that they can’t be used in replay attacks, and the secret is never sent over the wire. So that works, but it’s dependent on the arguably bad UXUX User experience of having an application registered before user authentication.
  - Mike Nelson 5:36 pm on February 24, 2016
    
    I hear ya but it already is “on your own head be it”.
    
    So for HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. sites, their password has already been exposed over the net. So from that starting point, none of the authentication methods considered will help, or really can. It’s incorrect to say “oAuth1a is secure for HTTP” because the process used to setup and configure oAuth1a was insecure to begin with.
    
    For example with application passwords being used over HTTP, I had originally thought it was safer than just Basic Auth because the user securely sets up and sees their application passwords in the wp adminadmin (and super admin). But the wp admin is being served over HTTP, and so are those application passwords. Meaning those application passwords have already been exposed, and so has their original password for that matter. So even though I agree we need to do what we can to keep users safe, I don’t see how we’re helping. It seems like an impossible task. We’re starting with an insecure system where the user’s password is already exposed: we don’t know if the user clicking the button in the wp admin is the real user, and we don’t know if we’ve given the application passwords to the real user, and we don’t know if it’s the real user who’s authorized the applications in the oAuth pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party’s admin. We began the whole process not knowing if this was the real user. How are we going to improve that?
    The only thing you can say is that intercepting a user’s password is EASIER with the Basic Auth authentication for the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. because their password is sent on every request, whereas in the wp admin it’s only sent once.
    - George Stephanis 5:43 pm on February 24, 2016
      
      If you’re originally generating the password or secrets over a VPN or on a secure home networknetwork (versus site, blog), there’s very little likelihood that the initial generation would be intercepted. Then you can use the signing over less secure networks — like your local Starbucks — with more comfort.
      
      Obviously I’m not accounting for government-scale surveillance, merely pointing out that if the initial exchange is free from prying eyes, you’re probably fine with OAuth 1.0a signing.
      - Mike Nelson 5:56 pm on February 24, 2016
        
        yeah ok that’s a good point
      - voldemortensen 6:11 pm on February 24, 2016
        
        To play the advocate, how many regular users do things over a VPN, and in reality, home networks aren’t that secure. Tools like reaver and aircrack-ng make it trivial to do MITM attacks, or even compromise the whole networknetwork (versus site, blog). Granted, someone would have to be specifically targeting you, but those tools are readily available.
      - George Stephanis 6:20 pm on February 24, 2016
        
        Sure, it’s totally feasible you could get hit on your home networknetwork (versus site, blog). My point is just that it’s significantly more likely on a public one, and measures can be taken client-side to mitigate.
John P. Bloch 2:07 am on February 24, 2016

I wonder if it might also make sense to further break down the content and “full” scopes into read and write. That way, applications that don’t need to modify user data but would like to read it could better put their users at ease (and same with reading content without being able to write it, perhaps for analytical or aggregation purposes).
- George Stephanis 3:56 pm on February 24, 2016
  
  Maybe? But that feels more like pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party territory. I’m not sure if an ‘options grid’ of limited vs full and C/R/U/D (or just simply read vs write) would be in any way intelligible to your typical user.
  
  Whether to grant access, and limited vs full feels to me — as a quick gut check — about as far as it would be wise to go.
- Jeremy Clarke 4:27 pm on February 25, 2016
  
  FWIW it wasn’t easy but I think FB/Twitter/iOSiOS The operating system used on iPhones and iPads./Android have trained people to think in terms of granting permissions for specific tasks and denying others. At least they got some people on board with the concept.
  
  The matrix/list would have to be simple, but something like “this app wants to: READ your content, WRITE new content but doesn’t need to CHANGE settings” would probably make sense to most people.
  
  Ideally apps would be able to indicate what they need, and users could then choose whether to grant access to all of it or some of it.
Eric 4:47 pm on February 24, 2016

> 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,

Please do not assume that current or future mobile apps are “legacy” or that they do not aspire to be a “full control” application. On the contrary, the goal is for a very rich experience beyond what is supported by the legacy XML-RPC APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways..
- George Stephanis 4:49 pm on February 24, 2016
  
  Sorry Eric! I was trying to refer to apps that communicate exclusively through the legacy XML-RPC APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. (what will eventually become legacy versions of the WordPress mobile apps). Worded badly on my part.
  - Eric 4:54 pm on February 24, 2016
    
    Thanks for clarifying George 🙂
javilopezg 11:25 pm on February 24, 2016
Hi everybody, here a new one with a blogblog (versus network, site) using WordPress.

I was testing the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. and it is clear to me that a change in the authentication is needed. It does not have any sense to create different applications for different websites. A solution could be a central repository as George suggest, but if you do not want to do that I think that you do not have to do that.

I will use OAuth 2 to explain my self because in my opinion is really more simple and better and clear and… in comparison to OAuth 1.
- coolapp.com is the site of the app
- cooldev.com is the WP site of the developer in which I defined the app as multitenant
- cooluser.wordpress.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/ is the WP site of the user who wants authorize coolapp.com to interact
01- User access to coolapp.com and says “Hey, I want to use this cool app”
02- coolapp.com ask for its server and user writes cooluser.wordpress.com
03- coolapp.com ask to cooluser.wordpress.com to identify the user
04- the user writes his credentials in cooluser.wordpress.com
05- cooluser.wordpress.com redirects to coolapp.com with a code saying “Yeah, this man is my man”
06- coolapp.com then ask to cooldev.com and says “Hey, I have a user with a code that wants to acces to the resource cooluser.wordpress.com and I am the coolapp.com (this is my client_id and this my client_secret)”
07- cooldev.com generates a token
08- cooldev.com says to cooluser.wordpress.com “Hey, I just generated this token that expires in 3600 seconds and its privileges are read and write”
09- cooluser.wordpress.com says “I would prefer not to work, but you know, it’s ok”
10- cooldev.com sends the response to coolapp.com with the token
11- then coolapp.com using the token, can now ask to cooluser.wordpress.com to do some stuff

If you look at this diagram https://tools.ietf.org/html/rfc6749#section-1.2

Client = coolapp.com
Resource Owner = cooluser.wordpress.com
Authorization Server = cooldev.com
Resource Server = cooluser.wordpress.com

The RFC says:

“The interaction between the authorization server and resource server
is beyond the scope of this specification. The authorization server
may be the same server as the resource server or a separate entity.
A single authorization server may issue access tokens accepted by
multiple resource servers.”

but with some conversation like the one in 8 and 9 it could be resolved.
- javilopezg 6:39 am on February 25, 2016
  
  I did a mistake last night. Is the resource owner who says what policies the user authorizes, so at point 08 cooldev.com only says “Hey, I just generated this token that expires in 3600 seconds”.
  
  Regards

Comments are closed.

Welcome!

Communication

REST API Authentication

Welcome!

Communication

Share this: