State_Error in Firefox / Chrome but not Safari

[MauriceArikoglu]

Description 🐜

The expected state changes while performing the sign-in requests (grant access, issue auth code, use auth code to get access token, ...) which leads to this: http://localhost:3000/api/auth/error?error=OAuthCallback (OAuthCallbackError).
The same code runs fine in Safari though - the state is matched correctly there and the user is successfully created.

How to reproduce ☕️

• Implement simple demo service conforming to rfc6749
• Create a custom provider
• Use Prisma Adapter from @next-auth/prisma-adapter@canary
• Call signIn with custom provider id

Screenshots / Logs 📽

[next-auth][debug][oauth_callback_protection] Comparing received and expected state {
  state: '83a88c0dd8f5ff505b1b72133d844a2142fc54ba8f2dbbe71fb45c6e091753c8',
  expectedState: '3e18670ab7e21f1716fe01ea5e1741bdf9438fc3d985b195e21f2b305831ec70'
}

state=83a88c0dd8f5ff505b1b72133d844a2142fc54ba8f2dbbe71fb45c6e091753c8 was passed to my oauth webservice. expectedState changes in Chrome/Firefox but not Safari - the code runs fine there (except for an issue with cors redirecting).

Environment 🖥

Please run this command in your project's root folder:

Binaries:
Node: 14.16.1 - ~/.nvm/versions/node/v14.16.1/bin/node
Yarn: 1.22.10 - ~/.nvm/versions/node/v14.16.1/bin/yarn
npm: 7.9.0 - ~/.nvm/versions/node/v14.16.1/bin/npm
npmPackages:
next: 10 => 10.0.1
next-auth: ^3.27.0 => 3.27.0
react: ^17.0.1 => 17.0.1

[balazsorban44]

Please provide a full reproduction. We cannot implement a simple OAuth 2 service in our free time. 😬

If configured correctly, I can assure you that Chrome and Firefox will work properly as well. You can test it through our growing list of built-in providers that use state as a protection check https://next-auth.js.org/configuration/providers

You could also check if you don't block cookies in your browser. It might be some settings there, since you claim that Safari works.

[MauriceArikoglu]

@balazsorban44 Hi Balazs, I am going to open source the OAuth service when I have the time. I will then create a simple spike project to demonstrate the issue. Until then: is there an exchange board / server to discuss next-auth related things?
Best,
Maurice

[balazsorban44]

Yes, we have Issues and Discussions 😁. I am not a big fan of authed/obscured places like Discord and Slack for OSS projects like this. Not easily searchable by those who need it the most (newcomers, who may haven't even heard of those services, or don't wish to register yet another platform just to get help). Not to mention, that as maintainers, it is a considerable overhead for us to jump between platforms to manage everything. (We are working on next-auth in our free time)

If you have any additional questions/information, please add it here.

[MauriceArikoglu]

@balazsorban44
Cool. I was just wondering whether there was a place to also hold casual conversation.
Maybe I can ask your for a favor regarding the other issue / q&a I posted regarding issues with CORS configuration.

On my OAuth service which integrates with the Authentication layer of my server side application "App A" I expose a simple login page where users can login with their "App A" credentials. Upon authentication the user is presented with the OAuth grant page, where they decide to allow access for the requesting app "External App". Once they accept I initiate a fetch request to the OAuth service, which then handles the "marriage" between the user account from "App A" and an auth code to be used by "External App" to obtain the access token and refresh token (all done as per rfc6749).
If all succeeds I am returning by sending a res.redirect(302, redirect_uri_with_params) - this is where the Cross Origin Policy seems to break the redirect. The browser console shows a 400 Bad Request for the CORS preflight even though I set up my next.config.js in "External App" to respond to all request with the appropriate CORS headers (I confirmed these being sent in the browser's request analyzer).
Now the thing is, I could accept this and just make a call to window.location.replace with the returned redirect_uri from the fetch request, but I believe this should also work by just hinting the browser at the resource with the 302 redirect response.
I thought about implementing a cors middleware, but I don't yet know how I would do that, as next-auth doesn't seem to provide a way to hook into the actual request context.
What do you think is the best way to go here / or am I missing something entirely right now?
Best,
Maurice

[balazsorban44]

I saw it, and it's in discussions now, as it didn't propose a change or reported a bug

#2250

let's keep this issue focused on a single problem. 🙂

[MauriceArikoglu]

@balazsorban44 yeah, I thought maybe you had something to contribute to this discussion ;)