An alternative to cookies for auth

[divpreet]

What do you want and why?

Based on what @flybayer mentioned here blitz-js/legacy-framework#227 (comment) my understanding is that cookies are used for auth (even for anonymous sessions). This works fine when the blitz app is run in the browser as a standalone application, where setting sameSite: "lax" is fine, but when an app is hosted in an iframe (inside a different domain), these cookies are not included in the requests. The alternative suggestion was to set sameSite: "none" but these cookies are treated as third party cookies and browsers are now starting to stop supporting third-party cookies.
Ref https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies/

Possible implementation(s)

Perhaps use shared storage / local storage / session storage. It kinda depends on what we're relying on the auth cookie for.

[MrLeebo]

You're not likely to find much success replacing auth cookies with localStorage / sessionStorage.

Not only is it less secure, but browsers will typically hold those mechanisms to the same standard as cookies when they're making changes to protect privacy, so if SameSite=None is in the chopping block for iframes, storage APIs would probably be more restricted in the same update.

[divpreet]

Fair point! This was more of a general suggestion, if we do definitely need to verify something.
I am not aware of what blitzjs checks when its an anonymous session, and whether we could make it work without cookies at all.
The legacy version was looking for a cookie and creating a brand new session on every request when the cookie was not found. It looks like the latest version might be doing the same?

[MrLeebo]

This doesn't sound like something that your app should need to code for or that blitzjs needs to address. If you want to share an auth token with the content of an iframe, the easiest thing to do would be to use the same domain for both pages.

You can put them on the same domain using a reverse proxy, which is an easy configuration to make in most hosting environments. For example, by using the "rewrites" option in nextjs config. This pattern insulates your front-end logic from having to know about your network infrastructure anyway.

// <iframe src="/foo" />
rewrites() {
  return [
    { source: "/foo", destination: "https://remote.example.com/foo" }
  ]
}

It isn't practical for blitzjs to implement every possible authentication pattern in existence in the hopes that that'll cover all potential apps. That would create an untestable and unmaintainable code surface area. It's more practical to implement the most typical solution and allow apps that require custom auth to write it how they need it.