New experimental module: OAuth2

Created on 12 December 2016, over 8 years ago
Updated 24 June 2025, 12 days ago

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:

  1. Cookie authentication
  2. HTTP Basic authentication
  3. … 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:

  1. including the 8.x-1.x branch would be signing us up for maintenance of the implementation of a complex spec: dangerous
  2. 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:
  3. 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
  4. the library itself has extensive test coverage (and the Drupal module already has functional tests)
  5. 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"
  6. 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

  1. Consensus about the principle that we want to add oauth2 authentication to Drupal 8 core as an experimental module.
  2. 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.)
  3. After complete consensus:
    1. Review cycle
    2. Commit

User interface changes

None.

API changes

None.

Data model changes

None.

🌱 Plan
Status

Needs work

Component

General

Created by

🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

Live updates comments and jobs are added and updated live.
  • Needs framework manager review

    It is used to alert the framework manager core committer(s) that an issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy draft for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

  • Needs product manager review

    It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the "user experience" of Drupal, and their signoff is needed. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024