Next.js to Drupal Authorization

1. Password Grant (For API Grants)

The Password Grant (also known as Resource Owner Password Credentials Grant) is an OAuth2 flow that allows a client application—such as a Next.js app—to directly exchange a user's credentials (username/email and password) for an access token from an authorization server, like Drupal configured with the Simple OAuth module. This flow is particularly useful in scenarios where the client is a trusted first-party application, meaning it's developed and maintained by the same organization or entity that owns the server. For instance, if you're building a mobile app or web app that integrates tightly with your Drupal site and you want to authenticate users without redirecting them through a separate login page, the Password Grant can streamline the process by handling authentication internally within the app. Token-based. It exchanges credentials for an access token (via /oauth/token), which is used for API calls. No cookies involved—pure OAuth tokens.

Why Use the Password Grant?

• Simplicity for Trusted Clients: It's ideal for first-party apps where users trust the client with their credentials, as it eliminates the need for complex redirects or additional authorization steps. The client collects the user's login details, sends them securely to the server, and receives an access token in return. This token can then be used to make authenticated API calls to Drupal, such as fetching user data or performing actions on behalf of the user.
• Direct Authentication: In setups where the app and server are closely integrated (e.g., a company-owned mobile app connecting to its own Drupal backend), it reduces friction by allowing seamless login without involving external browsers or third-party intermediaries.
• Historical Relevance: Before more secure flows became standard, this was a common method for server-side apps or trusted environments, especially in legacy systems or when integrating with existing user databases.

However, due to its inherent risks, this flow has been deprecated in modern OAuth2 standards (e.g., OAuth 2.1) for most use cases, and Drupal's Simple OAuth module (starting from version 6.0) removed built-in support for it, requiring an additional module like simple_oauth_password_grant to re-enable it. This reflects a broader shift toward more secure alternatives.

• What It Is: An OAuth 2.0 flow where the client (e.g., your Next.js app) directly sends the user's username and password to Drupal's OAuth server endpoint (e.g., /oauth/token) to request an access token. This is part of Drupal's Simple OAuth module.
• How It Works: The client exchanges credentials for a token (and optionally a refresh token), which is used for API calls. No session cookie is created—it's token-based.
• Pros: Secure for API-heavy apps, supports token expiration/refresh, and is decoupled (headless-friendly). Ideal for third-party clients or when you need revocable access.
• Cons: Deprecated in OAuth 2.1 for public clients due to credential exposure risks. Requires HTTPS and is less suited for direct user logins.
• Use Case: Best for machine-to-machine or app-based auth where tokens are managed programmatically.

Marking per Table:

• Stays on your site? Yes
• Secure? No (deprecated & insecure)
• Recommended for production? Never
• Notes: Don’t use

2. Session Authentication (de-facto standard for headless Drupal)

Built-in Drupal session authentication (cookie-based) + Next.js middleware Cookie-based. It posts to /user/login to set a session cookie (e.g., SESS*), which is used for auth. It's traditional session management, not token-based.

This method leverages Drupal's native session management (which stores user authentication in secure HTTP cookies) combined with Next.js's middleware for request interception and protection. It's a straightforward, server-side approach ideal for integrating a Next.js frontend with a Drupal backend, especially for sites where users log in directly through Drupal's forms. Or instead of redirecting to a Drupal page, use Next.js to make API calls to Drupal's REST endpoints (e.g., POST to /user/login with credentials). This can set the session cookie without rendering a page, essentially making it headless. You'd handle the login form in Next.js and use JavaScript (e.g., fetch) to authenticate. Drupal supports this via modules like rest or custom endpoints.

• What It Is: Drupal's built-in REST API endpoint for logging in via a POST request, which authenticates the user and establishes a session by setting an HTTP cookie (e.g., SESS*).
• How It Works: You send credentials (username/password) to /user/login via an API call (e.g., from Next.js with fetch). Drupal validates them, logs the user in, and sets a session cookie. Subsequent requests use this cookie for auth.
• Pros: Simple, familiar (like traditional web logins), and integrates with Drupal's session system. Good for quick, cookie-based integrations.
• Cons: Relies on cookies (less ideal for non-browser clients like mobile apps), and sessions can expire or require re-login. Not as flexible for token-based APIs.
• Use Case: Suitable for web apps where you want to mimic standard login behavior without full OAuth complexity.

Marking per Table:

• Stays on your site? Yes
• Secure? Yes (if done right)
• Recommended for production? Very common & solid
• Notes: The de-facto standard for headless Drupal

3. Full OAuth2 Authorization Code + PKCE flow (Best Choice - login with popup)

Token-based. This OAuth flow issues tokens after user consent, with PKCE for security. Tokens are used for subsequent requests.

Add a consumer in /webserveces /consumers + Add consumer add client id full_oauth add description full oauth description add secret 1234 Grant types all.

• Client ID: my-nextjs-app
• Client Secret: Leave empty (public client, required for PKCE)
• Grant Types: authorization_code, refresh_token
• Redirect URI: http://localhost:3000/api/auth/callback/drupal
• PKCE: Check "Use PKCE (Proof Key for Code Exchange)"
• Scopes: openid profile email (or customize based on your app's needs)

Exposed Endpoints (Automatic with simple_oauth)

• Authorization: https://your-drupal.site/oauth/authorize
• Token: https://your-drupal.site/oauth/token ???
• UserInfo (optional but recommended): https://your-drupal.site/oauth/userinfo ???
• JWKS: https://your-drupal.site/oauth/jwks

Marking per Table:

• Stays on your site? Yes
• Secure? Yes
• Recommended for production? Best choice
• Notes: Keeps user on your page

4. Custom Credentials Provider in NextAuth

This method involves setting up a custom credentials provider in NextAuth.js (now Auth.js) that calls Drupal’s password grant endpoint or token endpoint for authentication. It allows you to handle login directly in Next.js without redirecting to Drupal pages, using API calls to exchange credentials for tokens or sessions.

Token-based (if calling Drupal's endpoints). It can POST to /oauth/token (Password Grant) or similar to get tokens, then use them in NextAuth sessions. If it calls /user/login, it could shift to cookies.

• What It Is: A NextAuth provider that posts user credentials to Drupal's OAuth or REST endpoints (e.g., /oauth/token for password grant or /user/login for session auth) and manages the resulting tokens/sessions in Next.js.
• How It Works: User enters credentials in a Next.js form; NextAuth sends them to Drupal via API, receives a token or cookie, and stores it for subsequent requests. Middleware can protect routes.
• Pros: Keeps users on your site, integrates with NextAuth's session management, and can use Drupal's OAuth without full redirects.
• Cons: Requires implementing CSRF protection and rate-limiting to avoid security risks. You re-implement Drupal’s login logic, which can be error-prone.
• Use Case: Short-term solution for headless auth where you want NextAuth handling but still leverage Drupal's backend.

Marking per Table:

• Stays on your site? Yes
• Secure? Only if you add CSRF + rate-limiting
• Recommended for production? Acceptable short-term
• Notes: Works but you re-implement Drupal’s login logic