Send token in query param instead of anchor

[t1v1]

Feature request

Is your feature request related to a problem? Please describe.

I have to create a row in a custom public.users table immediately after a new user signs up (with Google). After logging in with Google, I've specified the redirectTo the /api/auth endpoint (which is a Next.js API route) which creates that row. However, I can't get the access_token sent by Supabase because it's in a URL fragment (i.e. using #) which is inaccessible to servers:

The fragment identifier functions differently to the rest of the URI: its processing is exclusively client-sided with no participation from the web server, though the server typically helps to determine the MIME type, and the MIME type determines the processing of fragments.

Describe the solution you'd like

Instead of sending the #access_token=asdf using a URL fragment (i.e. the # anchor spec), Supabase should make it a query parameter (i.e. ?access_token=asdf) so it's accessible to server-side environments.

Describe alternatives you've considered

Instead of redirecting to /api/auth, I redirect to a client-side loading page, perform the login, and then send the resulting user to the back-end using a POST request before redirecting to the rest of the app. This adds significant loading time to the whole process.

Additional context

Related to #2

[hf]

Hey @t1v1, (and 👍-ers: @nokome, @bhvngt)

This is intentional. Here are a few reasons why we're not going to be providing the option to send the access and refresh token as query string parameters:

1. Query string parameters end up in request / access logs.
   The access token is a JWT and contains some personally-identifiable information (PII) which should be avoided from appearing in logs (for example, for GDPR purposes).
2. Not all developers host SPA on domains / servers they control.
   Both the access and refresh token can be used to impersonate a user, since they are the credentials that identify the user. It is common nowadays for single-page apps (SPA) to be hosted on free platforms such as GitHub Pages, which means that whoever has access to the hosting server will be able to impersonate any user on your app. This is something we want to avoid.

If (2) does not apply for your application, i.e. you have total control over the hosting service, this is a snippet of code you can use to set the access and refresh token as cookies for use on the server-side:

supabase.auth.onAuthStateChange((event, session) => {
  if (event === "SIGNED_OUT" || event === "USER_DELETED") {
    // delete cookies on sign out
    const expires = new Date(0).toUTCString();
    document.cookie = `my-access-token=; path=/; expires=${expires}; SameSite=Lax; secure`;
    document.cookie = `my-refresh-token=; path=/; expires=${expires}; SameSite=Lax; secure`;
  } else if (event === "SIGNED_IN" || event === "TOKEN_REFRESHED") {
    const maxAge = 100 * 365 * 24 * 60 * 60; // 100 years, never expires
    document.cookie = `my-access-token=${session.access_token}; path=/; max-age=${maxAge}; SameSite=Lax; secure`;
    document.cookie = `my-refresh-token=${session.refresh_token}; path=/; max-age=${maxAge}; SameSite=Lax; secure`;
  }
})

We are going to be coming out with an official guide on how to properly use Supabase Auth in server-side rendering soon, though.

[bhvngt]

Thanks @hf. Official guide to use Supabase properly on SSR would be a very helpful.

[Muneeb-Shah]

For reference, here is the official guide for supabase/ssr

This part addresses the issue:

Change the Auth confirmation path

If you have email confirmation turned on (the default), a new user will receive an email confirmation after signing up.

Change the email template to support a server-side authentication flow.

Go to the Auth templates page in your dashboard. In the Confirm signup template, change {{ .ConfirmationURL }} to {{ .SiteURL }}/auth/confirm?token_hash={{ .TokenHash }}&type=signup.