custom domains - auth sync

[Soxasora]

Description

Part of #1942
Focuses on synchronizing authentication between SN and a custom domain.
It features a new sync endpoint that checks if there's a session and if so, redirects to the custom domain with a verification token that gets exchanged with a session token via POST.

Media

Auth Sync Login

Screen.Recording.2025-05-25.at.21.39.07.mp4

Additional Context

The interested code is in /api/auth/sync.js and /middleware.js
Edits to /nav/common has been made to accommodate Next Auth

Flow:

1. User, on custom domain, goes to /login or /signup
2. Middleware redirects to /api/auth/sync on SN and checks if there's a session
   ---> yes: Issue a verification token
   ---> no: Redirect to /login or /signup on SN with callback /api/auth/sync so we can resume auth sync
3. Redirect back to custom domain with the verification token
4. Middleware checks if there's a token param and make a POST to /api/auth/sync to exchange this token with a session token
5. Middleware applies the session token to a session cookie

Using a verification token and validating it with a POST is safer than the previous method of exposing a JWT directly

Future TODOs with priority:

• a page asking user confirmation before proceeding - 3/10
• pick an SN account to synchronize - 3/10
• multi auth - 6/10

Checklist

Are your changes backwards compatible? Please answer below:
Yes, only engages on custom domains

On a scale of 1-10 how well and how have you QA'd this change and any features it might affect? Please answer below:
6, Q/A OK, edge cases handled correctly

For frontend changes: Tested on mobile, light and dark mode? Please answer below:
n/a

Did you introduce any new environment variables? If so, call them out explicitly here:
n/a

[Soxasora]

There were some obstacles because of the cross-domain nature, but I think I found a middle ground to safely use CSRF to tie the verification token to the user.
Knowing that:

• messing with next auth is not preferable and thus can't use its protections
• we need to protect the token from being stolen
• middleware doesn't support node
  We have another option, which is to encode the CSRF token in a state JWE and store it alongside the verification token.

When going to the sync endpoint, we

• detect login -> encode CSRF token in state JWE -> /api/auth/sync/?...&state=encodedState

The sync endpoint will then

• create a token like token|encodedState -> redirect back with just the token

Middleware at this point will

• POST /api/auth/sync with body: {token, csrfToken} -> retrieve the verification token object from DB -> decode the encodedState -> match decodedState with csrfToken

If everything is okay, it returns the final ephemeral JWT.

Everything happens blazingly fast, if someone steals the verification token and/or the state, they can’t go that far without the CSRF token that sits and never moves in the user’s browser (well, except for the POST, but that's secure).

---

side note: still checking for less hacky ways/can make it less hacky