Fixing Supabase Auth Session Issue on Local Dev without HTTPS

I’ve been using Supabase as the backend and database for my personal project, lab-scholarships.kr (opens in a new tab), and naturally, Supabase Auth (opens in a new tab) became my go-to option for developing authentication feature on the project. It looked straightforward from the documentation, so I jumped right in. Unfortunately, I ran into an unexpected issue: the authentication flow didn’t work properly in my local development environment.

The strange part was that the login process seemed successful, but immediately after logging in, the application behaved as if no user was authenticated. Essentially, the session didn’t persist. Checking the Supabase dashboard confirmed that the login itself was successful, which made the problem even more confusing.

I spent several frustrating hours troubleshooting this issue, including going back-and-forth with an AI-assisted coding tool (Cursor). The AI suggestions mostly revolved around minor changes like changing the methods to retrieve the user/session data. Unfortunately, none of these tweaks fixed the issue.

After spending a significant amount of time on it, I finally decided to closely inspect the browser’s developer tools. That was when I noticed Supabase Auth relies on cookie-based authentication and the session cookie wasn’t being stored by the browser because by default the secure flag of HTTP-only cookies are set to true. Since my local dev server doesn’t use HTTPS, this caused the cookie to be rejected.

Armed with this information, I went back to Cursor and asked specifically how to fix this issue. It then quickly identified the solution: explicitly set the cookieOptions parameter when initializing the Supabase client to allow cookies over non-secure HTTP connections.

Here’s how I did it:

createBrowserClient(PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_ANON_KEY, {
  db: { schema: 'lab-scholarships' },
  global: {
    fetch,
  },
  cookieOptions: {
    secure: process.env.NODE_ENV !== 'development',
    sameSite: 'lax',
    path: '/'
  },
})

Basically setting the secure flag to false on development environment and setting the sameSite flag to lax to allow the cookie to be saved even when the local development domain is not the same as server. After applying this fix, authentication worked flawlessly on my local environment.

Interestingly, at the time of writing, Supabase’s documentation didn’t mention this configuration at all. While using HTTPS even for local dev environments is undoubtedly the best practice, this particular solution is especially useful for quickly setting up local testing environments where simplicity and speed are more important.

Closing

My main takeaway from this experience isn’t necessarily about Supabase Auth itself because once I figured out the core issue, the fix was pretty straightforward. What stood out more was how AI coding assistants can still struggle when the issue is uncommon or not well-documented. A key indicator of this struggle in my case was that it kept repeating the same response, even after I told it the issue still wasn’t fixed.

Even though the tool eventually gave me the right solution after I provided the key hint, it reminded me that domain knowledge still matters. We still need to understand the fundamentals of our field to guide these tools in the right direction. In my case, having a solid foundation in software engineering was what helped me get unstuck.

Hopefully, this post saves someone else from a few hours of confusion and frustration!