React.js – Born To Be Wild

If you use WordPress as a headless CMS with Next.js, sooner or later you will need to fetch private data. Maybe it is draft posts, a preview page, or content only logged in users should see. Public data works without any login, but private data needs authentication.

In this guide I will show you how to set up auth for WPGraphQL and how to use your credentials safely inside Next.js. I will keep it simple and go one step at a time.

What You Need Before You Start

A WordPress site running on HTTPS
The WPGraphQL plugin installed and active
A Next.js project (App Router in this guide)
Basic knowledge of fetch and environment variables

Step 1: Install and Check WPGraphQL

In your WordPress dashboard, go to Plugins, then Add New, and search for WPGraphQL. Install it and click Activate.

After that, you will see a new GraphQL menu in the sidebar. Your endpoint will be:

https://yourdomain.com/graphql

Open the GraphiQL IDE from the GraphQL menu and run a simple query to confirm everything works.

Step 2: Create an Application Password

This is built into WordPress. It is the easiest choice when your Next.js server needs to talk to WordPress, for example to read drafts. Think of it as your API key.

In WordPress, go to Users, then Profile
Scroll down to the Application Passwords section
Type a name like “Nextjs Frontend”
Click Add New Application Password
Copy the password right away. WordPress shows it only once

A tip from experience: create a separate user with only the role it needs, like Editor, instead of using your admin account. If the key ever leaks, the damage stays small.

Step 4: Store the Credentials in Environment Variables

In the root of your Next.js project, open the .env.local file and add:

WORDPRESS_GRAPHQL_URL=https://yourdomain.com/graphql
WP_APP_USER=your_wordpress_username
WP_APP_PASSWORD=abcd efgh ijkl mnop qrst uvwx

Very important: do not add the NEXT_PUBLIC_ prefix to these names. Any variable with that prefix gets sent to the browser, and anyone can see it. Without the prefix, the value stays on the server only.

Also make sure .env.local is listed in your .gitignore file so it never goes to GitHub.

Step 5: Create a Helper Function for API Calls

Instead of writing the same fetch code again and again, make one helper. Create a file at lib/wp.js:

export async function wpFetch<T>(query: string): Promise<T> {
    const token = btoa(`${process.env.WP_USER}:${process.env.WP_APP_PASSWORD}`);

    const res = await fetch(process.env.WP_GRAPHQL_URL!, {
        method: "POST",
        headers: {
            "Content-Type": "application/json",
            Authorization: `Basic ${token}`,
        },
        body: JSON.stringify({ query }),
        next: { revalidate: 60 }, 
    });

    const json = await res.json();
    if (json.errors) throw new Error(JSON.stringify(json.errors));
    return json.data;
}

Here is what this code does in simple words:

It joins your username and application password, and turns them into a Base64 string.
It sends that string in the Authorization header with the word Basic in front.
WordPress reads the header, checks the user, and then returns data based on that user’s permissions.
The revalidate: 60 line tells Next.js to refresh the cached data every 60 seconds.

Step 6: Use the Helper in a Page

Now let us fetch draft posts, which only logged in users can see. Create app/drafts/page.js:

import { wpFetch } from "@/lib/wp";

const QUERY = `
  query GetDrafts {
    posts(where: { status: DRAFT }) {
      nodes {
        id
        title
        slug
      }
    }
  }
`;

export default async function DraftsPage() {
  const data = await wpFetch(QUERY);
  const posts = data.posts.nodes;

  return (
    <main>
      <h1>Draft Posts</h1>
      {posts.map((post) => (
        <p key={post.id}>{post.title}</p>
      ))}
    </main>
  );
}

This is a Server Component, so the API call runs on the server. Your password never reaches the browser. If you run the same query without the auth header, WordPress returns an empty list. With the header, you see your drafts. That is how you know auth is working.

Common Mistakes to Avoid

Using NEXT_PUBLIC_ on secret values
Using an admin account when an Editor account is enough
Running your site on HTTP. Application Passwords need HTTPS on live sites
Forgetting to add .env.local to .gitignore
Calling private queries from client components, which exposes your keys

Final Thoughts

Setting up auth for WordPress GraphQL is not hard once you know the flow. Create an application password, keep it in a server only environment variable, send it in the Authorization header, and always make private calls from the server side of Next.js. If you need user logins, add JWT on top.

I hope this guide saved you some time. If you get stuck on any step, leave a comment and I will try to help.

You build a login system. It works perfectly on your laptop. Then you deploy the React app to Vercel and the Express API to Render, and suddenly nobody can stay logged in. The login request returns 200, but the next request returns 401.

If your MERN cookies are not working in production, you are not alone. This is one of the most common problems after a first deployment. The good news is that it always comes down to a few settings. In this post I will show you why it happens and how I fix it step by step.

Why cookies work on localhost but not in production

On your machine, the frontend runs on localhost:5173 and the backend runs on localhost:5000. Browsers do not care about ports when they decide if two URLs are on the same site. So both are the same site, and cookies flow freely.

After deployment, your URLs look like this:

Frontend: myapp.vercel.app
Backend: myapp-api.onrender.com

These are two different sites. Both vercel.app and onrender.com are on the public suffix list, so every project under them counts as its own site. Now your API cookie is a third-party cookie, and browsers treat it very differently.

How to check what is broken

Before you change any code, open DevTools and look at two things:

Go to the Network tab, click your login request, and check the response headers for Set-Cookie.
Go to the Application tab, open Cookies, and see if your cookie was saved.

Here is how to read what you see:

What you see	Likely cause
No `Set-Cookie` header at all	Wrong `secure` setting, missing trust proxy, or a CORS block
`Set-Cookie` has a warning icon	`SameSite=None` is used without `Secure`, or the browser blocked it
Cookie is saved but not sent on the next request	`withCredentials` is missing on the client
CORS error that mentions credentials	Wildcard origin or `credentials: true` is missing

Step 1: Set the right cookie options on the server

For a cross-site setup, your cookie needs HttpOnly, Secure and SameSite=None. I keep these in one file so login and logout always use the same values.

// utils/cookieOptions.js
const isProd = process.env.NODE_ENV === "production";

export const authCookieOptions = {
  httpOnly: true,
  secure: isProd,
  sameSite: isProd ? "none" : "lax",
  path: "/",
  maxAge: 7 * 24 * 60 * 60 * 1000, // 7 days
};

Browsers reject SameSite=None if the cookie is not also Secure. That is why I only turn it on in production. On localhost over plain HTTP, lax works fine.

Also make sure NODE_ENV is really set to production on your hosting dashboard. If it is missing, your app will silently use the development values.

Now use the options in your login controller:

import jwt from "jsonwebtoken";
import { authCookieOptions } from "../utils/cookieOptions.js";

export const login = async (req, res) => {
  // check email and password first, then:
  const token = jwt.sign({ id: user._id }, process.env.JWT_SECRET, {
    expiresIn: "7d",
  });

  res.cookie("token", token, authCookieOptions);
  res.status(200).json({ message: "Login successful" });
};

If you still need to set up your database layer, read my guide on how to connect MongoDB with Node.js using Mongoose.

Step 2: Tell Express to trust the proxy

Render, Railway and most hosts put a proxy in front of your app. The proxy handles HTTPS, then passes plain HTTP to Express. Because of this, Express may think the request is not secure, and libraries like express-session will refuse to set a secure cookie.

Fix it with one line, placed before your other middleware:

app.set("trust proxy", 1);

This tells Express to read the X-Forwarded-Proto header from the proxy, so req.secure becomes true.

Step 3: Set up CORS with credentials

Your API must allow your exact frontend origin and allow credentials. This is the full server setup:

import express from "express";
import cors from "cors";
import cookieParser from "cookie-parser";

const app = express();

app.set("trust proxy", 1);

app.use(
  cors({
    origin: process.env.CLIENT_URL, // https://myapp.vercel.app
    credentials: true,
  })
);

app.use(express.json());
app.use(cookieParser());

These are the mistakes I see most often:

Using origin: "*" together with credentials: true. Browsers reject this.
Adding a trailing slash, like https://myapp.vercel.app/. The origin must match exactly.
Forgetting to add CLIENT_URL in the hosting dashboard.
Placing cors() after your routes instead of before them.

Step 4: Send credentials from the frontend

Even if the server is perfect, the browser will not send cookies unless you ask it to. With Axios, set withCredentials once on your instance:

// src/lib/api.js
import axios from "axios";

export const api = axios.create({
  baseURL: import.meta.env.VITE_API_URL,
  withCredentials: true,
});

With the Fetch API, use credentials: "include":

fetch(`${import.meta.env.VITE_API_URL}/auth/me`, {
  credentials: "include",
});

If you are still on Create React App and import.meta.env does not work for you, see my guide on migrating a MERN app from CRA to Vite.

Step 5: Clear the cookie on logout the right way

A cookie is only removed if the clear options match the options used to set it. Do not pass maxAge when clearing, because it can stop the cookie from being deleted.

import { authCookieOptions } from "../utils/cookieOptions.js";

export const logout = (req, res) => {
  const { maxAge, ...clearOptions } = authCookieOptions;

  res.clearCookie("token", clearOptions);
  res.status(200).json({ message: "Logged out" });
};

The problem that config alone cannot fix: blocked third-party cookies

You can do everything above and still see broken logins for some users. Safari blocks third-party cookies by default. Firefox isolates them per site. Chrome blocks them in Incognito mode and when users turn on the setting.

So a cross-site cookie setup works for you in Chrome, then fails for a client on an iPhone. This is why I do not rely on cross-site cookies for real projects. There are three better options.

Option 1: Use one domain for both apps (best option)

Put your frontend and backend on subdomains of the same domain:

app.yourdomain.com for the frontend
api.yourdomain.com for the backend

These are the same site, so the browser treats your cookie as first-party. You can then use sameSite: "lax" and it works in every browser. Both Vercel and Render support custom domains.

Option 2: Proxy API calls through Vercel

If you cannot use a custom domain yet, use Vercel rewrites. The browser talks only to your Vercel domain, and Vercel forwards the request to your API. Add this to vercel.json:

{
  "rewrites": [
    {
      "source": "/api/:path*",
      "destination": "https://myapp-api.onrender.com/api/:path*"
    }
  ]
}

Then set VITE_API_URL=/api in your frontend environment. Every request now looks same-origin, and the cookie becomes first-party. One thing to know: this works for normal REST calls, but WebSocket connections need to go straight to the backend, so real-time features can still run into cookie problems.

Option 3: Add the Partitioned attribute (CHIPS)

CHIPS (Cookies Having Independent Partitioned State) lets a cross-site cookie work in supporting browsers, as long as it is stored per top-level site. You add one option:

res.cookie("token", token, {
  ...authCookieOptions,
  partitioned: true,
});

It needs secure: true and sameSite: "none", and you should use a recent Express version. It mainly helps Chromium browsers, and it does not solve the Safari problem. I treat it as a backup, not the main fix.

Do not forget CSRF

When you use SameSite=None, you lose some of the built-in protection against CSRF attacks. If your app changes data with cookie auth, add a CSRF token, or at least check the Origin header on write requests. Using a same-site setup like Option 1 avoids this problem entirely.

Quick checklist

Run through this list before you spend hours debugging:

NODE_ENV is set to production on the server
Cookie has httpOnly: true, secure: true and sameSite: "none" in production
app.set("trust proxy", 1) is added before other middleware
CORS uses the exact frontend URL, with no trailing slash and no *
CORS has credentials: true
Axios has withCredentials: true, or Fetch has credentials: "include"
Logout uses the same cookie options, without maxAge
Tested in Safari and in a Chrome Incognito window
Considered a custom domain or a Vercel proxy

If your auth check runs through TanStack Query and you see stale data after login or logout, my post on common React Query issues and invalidate queries will help.

Frequently Asked Questions

Why do my cookies work in Postman but not in the browser?

Postman does not enforce SameSite rules or CORS. It only proves your API logic works. Browsers add extra security checks, so a request can pass in Postman and still fail in the browser.

Should I use localStorage instead of cookies?

It avoids the cross-site problem, but any script on your page can read localStorage, so an XSS bug can leak the token. An HttpOnly cookie is safer for auth tokens. I prefer to fix the cookie setup instead of moving the token to localStorage.

Does SameSite=Strict work when the frontend and backend are on different domains?

No. Strict blocks the cookie on all cross-site requests. For separate domains you need None, or better, move both apps under one parent domain and use Lax.

Why does my cookie disappear only on iPhones?

Safari blocks third-party cookies by default. The fix is to make your API same-site with a custom domain or a proxy, not to change cookie flags.

Final thoughts

Most MERN cookie problems in production come from one idea: on localhost your apps share a site, and after deployment they do not. Set the correct cookie flags, trust the proxy, configure CORS with credentials, and send credentials from the client. Then, for a setup that works in every browser, move your frontend and API under the same domain.

If you want help with authentication, deployment or a full build, take a look at my MERN stack development service and Node.js backend development service. You can also see my past projects, read more on the blog, or contact me directly.

Tag: React.js

How to Set Up Auth for WordPress GraphQL in a Next.js Project