Authentication and OAuth in Drupal

Core ships only the first two. OAuth 2.0 is contributed code, not part of Drupal core, and JSON:API itself is "zero configuration" but does not authenticate anybody: it uses whichever authentication providers are active.

Authentication providers are services tagged authentication_provider in a *.services.yml file. On each request the authentication manager asks providers in priority order whether they applies to the request (for example, whether an Authorization header is present) and, for the first that does, asks it to authenticate and return an account. If none applies, the request is anonymous. A tag can be global, in which case it is considered on every route; a non-global provider is used only by routes that name it in the _auth requirement.

Two tag lines from the sources show the difference. Core’s Basic authentication registers itself with { name: authentication_provider, provider_id: 'basic_auth', priority: 100 } and no global flag, while Simple OAuth registers { name: authentication_provider, provider_id: oauth2, global: TRUE, priority: 35 }. Cookie authentication (provider_id: cookie) is the default provider for routes that do not say otherwise. A custom route that must accept bearer tokens or Basic credentials declares it explicitly:

Source: Creating modules: Defining a route

The same list is used by REST resource configuration (authentication: [oauth2] in a rest.resource.* config object). Remember that authentication only answers "who is this?". The route’s _permission, entity access and field access still decide what that user may do, which is covered in Users, roles and permissions.

When a person logs in at /user/login, Drupal starts a session and sets a cookie. Any later request that carries the cookie is authenticated as that user. For safe methods (GET, HEAD) that is all that is needed. For unsafe methods (POST, PATCH, DELETE) on API routes, Drupal requires a CSRF token in the X-CSRF-Token header, because browsers send cookies automatically on cross-site requests. The token is available from the /session/token path:

Source: Getting Started with JSON API and REST

Session cookies are configured under session.storage.options in services.yml. In the shipped defaults, cookie_samesite is Lax, which stops the browser sending the cookie on most cross-site sub-requests. A decoupled front end on another site (not merely another subdomain) therefore cannot depend on the cookie, and a SameSite change to None widens the attack surface; use bearer tokens instead. Logging out through /user/logout is itself CSRF-protected since Drupal 10.3.

The core basic_auth module lets a client send Authorization: Basic <base64(user:password)>. Enable it with drush en basic_auth. It has no configuration screen. Because it is not global, it applies only to routes that list basic_auth in _auth (JSON:API and REST resources must be configured accordingly), and the credentials are the user’s real login password. Use it only over HTTPS, for dedicated low-privilege integration users, and never for browser applications, since the password would have to be stored in the client. It is stateless and needs no CSRF token.

Source: Getting Started with JSON API and REST

Basic authentication does not protect against brute force by itself. Core’s flood control applies to login attempts, so repeated failures lock the account or IP out for a time, which is a denial-of-service surface worth monitoring.

Simple OAuth implements the OAuth 2.0 Authorization Framework (RFC 6749) on top of the PHP League’s OAuth 2.0 Server library. As of 2026-10-30 the project lists 6.1.3 (requires Drupal 10.3 or 11) and 6.0.9 (Drupal 10.2 or 11) as the stable lines; 5.2 (Drupal 9 or 10) is announced as reaching end of life on 2026-12-09, and the project states the 5.2 to 6.x upgrade path as unstable. Install it per project with Composer:

Source: Simple OAuth (OAuth2) & OpenID Connect project page

The module depends on Serialization, Consumers, Options and Path Alias; enabling simple_oauth pulls in the consumers project that stores client applications.

If the Next.js application runs on another origin than Drupal, the browser enforces CORS (see What is CORS?). Drupal core has supported opt-in CORS since 8.2 through the cors.config parameters in services.yml. It is off by default because it has security consequences. Copy default.services.yml to services.yml in the site directory (editing the default file has no effect), set the values, and rebuild caches:

Source: Change record: Opt-in CORS support

The shipped defaults are enabled: false, empty allowedHeaders and allowedMethods, allowedOrigins: ['*'], exposedHeaders: false, maxAge: false and supportsCredentials: false. Pitfalls:

Older tutorials and books written for Drupal 8.x and 9.x often show the password or implicit grant for decoupled front ends; Simple OAuth 6.0 removed both. They also describe the 5.x settings form for token lifetimes, which in 6.x moved to the consumer. For any new decoupled integration use authorization code with PKCE or client credentials, and do not start new sites on Drupal 10, whose support ends on 2026-12-09.