-
Notifications
You must be signed in to change notification settings - Fork 609
Description
Bug report
- I confirm this is a bug with Supabase, not with my own application.
- I confirm I have searched the Docs, GitHub Discussions, and Discord.
Describe the bug
A regression in @supabase/supabase-js version 2.91.0 causes OAuth/SSO session persistence to fail in Next.js SSR environments (Next.js 15/16).
While the exchangeCodeForSession call appears to succeed on the server, the resulting session cookies (sb-*-auth-token) are either missing from the response headers or are rejected by the browser due to invalid attributes (specifically Domain attribute issues on localhost). This results in the user being redirected to the success page as an unauthenticated user, triggering a loop back to the login page.
Downgrading to 2.90.1 resolves the issue immediately without any code changes.
To Reproduce
- Use
@supabase/supabase-js@2.91.0and@supabase/ssr@0.8.0in a Next.js 15/16 project. - Implement a standard PKCE OAuth flow with a Route Handler (
/auth/callback). - Call
supabase.auth.exchangeCodeForSession(code)within the GET handler. - Redirect to a protected route using
NextResponse.redirect(). - Observe the Network tab: The
auth-tokencookies are often missing from theSet-Cookieheaders, or the browser shows a warning: "Set-Cookie was blocked because its Domain attribute was invalid with regards to the current host url". - The user arrives at the destination page without a valid session.
Expected behavior
The exchangeCodeForSession call should correctly set the auth-token and refresh-token cookies in the response headers, and these cookies should be accepted by the browser (especially on localhost where the domain attribute should be handled correctly to avoid rejection).
System information
- OS: Windows 10 / 11
- Browser: Chrome 144+
- Version of supabase-js: 2.91.0 (Broken) / 2.90.1 (Working)
- Version of @supabase/ssr: 0.8.0
- Version of Next.js: 16.1.4 (also reproducible on 15.x)
- Version of Node.js: 20.10.0+
Additional context
The issue seems related to how version 2.91.0 handles cookie options during the code exchange in an SSR context. On localhost, it appears to be attempting to set a Domain attribute that causes browser rejection, or failing to synchronize the new session cookies with the Next.js cookies() store in time for the redirect response.
The issue was consistently reproducible on 2.91.0 and was fixed immediately by pinning to 2.90.1.
P.S. Folks, I spent hours trying to figure out what the heck was going on.
Bunch of tokens in Cursor and a lot of frustration.