WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 2 weeks ago

#42790 new feature request

Permit basic authentication to the REST API over SSL

Reported by: kadamwhite Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: REST API Keywords:
Focuses: Cc:

Description

The only REST API authentication scheme currently supported in core is cookie/nonce authentication. This is sufficient for front-end usage within wp-admin, themes, and plugins, but prohibits full consumption of the REST API from external applications, particularly the WordPress mobile apps.

After discussion with the WordPress mobile app team, we propose adding core support for REST API authentication via basic auth for SSL-enabled environments.

These mobile apps currently use basic authentication to connect via the XML-RPC API. The XML-RPC API is disabled in some hosting environments, but discussion with the hosting team suggests this is usually to avoid amplification attacks via pingbacks rather than anything related to basic authentication itself. Using this scheme only over secured connections mitigates the primary security criticism of basic authentication. As an example, the Github API (among many others) supports basic authentication: https://developer.github.com/v3/auth/ without any clear drawbacks. These APIs also preference basic auth because it is substantially simpler to use than OAuth schemes, even with a central broker.

From the perspective of a mobile app developer, preventing REST API access via that same authentication scheme on the grounds that we are simultaneously pursuing alternatives unfairly disenfranchises the mobile app team and blocks significant potential code improvements.

Attachments (2)

42790.diff (1.0 KB) - added by georgestephanis 2 years ago.
42790.1.diff (1.5 KB) - added by georgestephanis 15 months ago.

Download all attachments as: .zip

Change History (22)

#2 @kadamwhite
2 years ago

Fast to the punch @georgestephanis ! As you note another implementation would be the json_basic_auth_handler method from https://github.com/WP-API/Basic-Auth -- the technical approach is similar, just with additional filters and error handling. (While that plugin has never made it into the plugin directory it has been used in production in a number of sites over the past few years, in some cases by having that method in-lined into the application code.)

I'm interested in the loop-back to determine whether auth headers are forwarded; how prevalent is that issue across hosts?

Further discussion with @nacin and others at the WCUS contributor day has pointed out that Github's solution permits the use of authentication tokens, which would be preferable to the direct use of user passwords as they can be individually registered and revoked. We'd want to do some design work to find a token generation & registration flow that works for mobile app users if we go that route.

#3 @georgestephanis
2 years ago

It's prevalent enough, my personal site on DreamHost needs the workaround.

#4 @georgestephanis
2 years ago

And re: token generation flow, this isn't merged yet to application passwords, but should handle what you intend, I expect:

https://github.com/georgestephanis/application-passwords/pull/39

Vizrec on the pull.

#5 @dd32
2 years ago

  • Type changed from defect (bug) to feature request

This ticket was mentioned in Slack in #core-restapi by kadamwhite. View the logs.


2 years ago

#7 @rmccue
2 years ago

We discussed this a bunch in today's Slack meeting.

#8 @georgestephanis
15 months ago

New patch gets around the fastcgi mode by accepting the Basic authorization via a WP-Authorization header instead of the Authorization header that is occasionally not passed along.

#9 @pento
13 months ago

  • Version trunk deleted

This ticket was mentioned in Slack in #core-restapi by kadamwhite. View the logs.


13 months ago

#11 @kadamwhite
3 months ago

  • Keywords close added

This may be somewhat controversial, but based on recent discussions in Slack, on GitHub, elsewhere on Trac, and at the WordCamp US contributor day, I think that this ticket should be considered for closure in favor of using an OAuth2 authentication flow which exchanges is a JWT auth token in lieu of a bearer token. See https://GitHub.com/wp-api/authentication, which is currently bare bones but which we hope to get to merge proposal over the course of 2020.

#12 follow-up: @Otto42
3 months ago

  • Keywords close removed

@kadamwhite Disagree. For sites using SSL, we should add Basic Authentication to the login flow. Not just to the REST API, but to all flows, using the general authentication mechanisms. Essentially, add basic auth to the authenticate filter for the case when SSL is enabled.

OAuth2 is a bad mechanism for this, designed for an entirely different purpose. It's for having Facebook talk to Google and the like. Where the user has accounts on two different services and wants them to share information. WordPress is a service in this equation, but more to the point it is a piece of software, actually self-run by the user. It doesn't fit OAuth's original design. Never has. The user wants to authenticate to their own site using their own credentials, and Basic Auth fits that just fine. Yeah, okay, it's not great when you're sending passwords in the clear, but for the case where SSL is enabled, it is a far better user experience and secure enough for a first pass.

+1 to Basic Auth support.

#13 @Otto42
3 months ago

Additional: for the proposal of adding basic auth to the authenticate filter, to allow it for all login flows, I would have the ssl check be capable of being disabled via a filter, or a defined constant.

If I wanna run http on my site and allow basic auth, then that's my call. It shouldn't be the default, but it should be possible.

When credentials are already sent in the clear, then there is no harm in allowing that via add-ons. The benefit here is in bringing this job into core instead of requiring plugins to do the job, perhaps incorrectly.

#14 in reply to: ↑ 12 @georgestephanis
3 months ago

Replying to Otto42:

@kadamwhite Disagree. For sites using SSL, we should add Basic Authentication to the login flow. Not just to the REST API, but to all flows, using the general authentication mechanisms. Essentially, add basic auth to the authenticate filter for the case when SSL is enabled.

Just to confirm, you feel that it should also be expanded so that basic auth can be used in lieu of cookies for http requests to wp-admin, as well as the legacy xmlrpc api?

If it can be switched to allow non-https requests as well, we should also include a switch to disallow it to be used even for https requests -- in the case of two-factor authentication where just the username and password alone are insufficient.

#15 @Otto42
3 months ago

No, I don't think it makes sense to allow it for http requests. I'd say https only for basic auth is sufficient. And any 2 factor case should disable it, although that is still within plugin territory at present.

This ticket was mentioned in Slack in #core-restapi by kadamwhite. View the logs.


3 months ago

#17 @georgestephanis
3 months ago

sorry, i didn't mean http as in non-https for wp-admin -- i meant html api -- that is the normal wp-admin html ui.

#18 @koke
3 months ago

The mobile apps are starting to need this (or an alternative) more and more often. With our focus on Gutenberg in the apps, we are finding many scenarios where Gutenberg obtains data from the REST API that we can't access because we have no good way to authenticate.

I think in the long term we would rather use a token-based approach like the one being discussed in https://github.com/wp-api/authentication but that's still in the early stages, and it looks like it's going to take some time to get right. Besides, we are going to need a migration path for all the existing users for whom we already have usernames and passwords, and basic auth seems like a great solution for the short and medium term.

It would be very helpful for Gutenberg on mobile to have this available on core soon.

#19 @koke
3 months ago

Another thing that would be good to improve is discoverability. I was happy to see that there's built-in support in the API for exposing the available authentication methods, but I haven't seen this implemented by any plugin other than OAuth1.

This ticket was mentioned in Slack in #core-restapi by sergioestevao. View the logs.


2 weeks ago

Note: See TracTickets for help on using tickets.