Problem/Motivation
Drupal 7 only supported cookie authentication. Drupal 8, because it wants to be API-first, has the concept of
authentication providers →
. The only one included with Drupal core is \Drupal\basic_auth\Authentication\Provider\BasicAuth
, in the basic_auth
module.
This means that when you use the REST module in core (or the
JSON API →
or
GraphQL →
modules in contrib), you can only use:
- Cookie authentication
- HTTP Basic authentication
- … and no authentication (anonymous)
Neither of these are considered best practices when interacting with REST APIs. In fact, all of them are terrible choices, and are heavily looked down upon.
The vast majority of these APIs use OAuth 2.0. Specifically, OAuth 2 bearer token.
Proposed resolution
As part of the API-first initiative (
#2757967: API-first initiative →
), we'd like to propose to add OAuth2 to Drupal 8.3 core as an experimental module. This should come as no surprise because #2757967 has mentioned it since being published on June 29.
@e0ipso →
is the maintainer of the
https://www.drupal.org/project/simple_oauth →
module, which implements OAuth2 bearer token. Unfortunately, it's all Drupal-specific code. Even though the OAuth 2.0 spec is notoriously difficult to implement correctly/completely. So, bringing this module to Drupal 8 core would've had quite a big associated risk: we'd be taking on building and maintaining our own implementation of an OAuth 2 server.
A much lower risk would be to use the PHP library that is the most widely installed/depended upon library in the entire PHP ecosystem to build an OAuth 2 server: thephpleague/oauth2-server
. We proposed he rewrite his module on top of that. e0ipso started doing so, and in fact finished doing so a few days ago:
https://www.drupal.org/project/simple_oauth/releases/8.x-2.0-alpha1 →
is the first release of the 8.x-2.x branch.
Even though this branch of the module has only existed for a very short time, we think it's appropriate to include it in Drupal 8.3:
- including the 8.x-1.x branch would be signing us up for maintenance of the implementation of a complex spec: dangerous
- we're building on top of a mature, broadly used, battle-hardened implementation:
thephpleague/oauth2-server
with more than one million downloads and extensive test coverage. This library is used for OAuth purposes in popular frameworks like Laravel and Cake PHP 3. The library implements the following RFCs:
- not having Oauth2 in core could lead to many more people not using Oauth2 at all, thus being less secure and giving decoupled Drupal a bad reputation
- the library itself has extensive test coverage (and the Drupal module already has functional tests)
- this module would never get as much usage in contrib as it would in core, even if only for discoverability reasons. So only if it's in core, we'll get the massive real-world feedback we need for something like this to mature & graduate to "stable in core"
- There are 4 types of OAuth2 grants — we can decide which grants we want in core and leave the rest for the
oauth2_advanced
contrib module.
Remaining tasks
- Consensus about the principle that we want to add
oauth2
authentication to Drupal 8 core as an experimental module.
- After that basic consensus: we need to agree on which types of grants make sense for Drupal core to support. (Any grant types we agree don't make sense for core can be supported by a
oauth2_advanced
module in Drupal 8 contrib.)
- After complete consensus:
- Review cycle
- Commit
User interface changes
None.
API changes
None.
Data model changes
None.