Cannot use access token from auth0-nextjs with Supabase Auth's Third-Party Auth

[dagingaa]

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

I have followed the guide on how to set up Auth0 with the new third-party auth feature, but it doesn't seem to work with the preferred method of using Auth0 with NextJS - auth0-nextjs.

When I use an access token obtained using this library, I get an error PGRST301 - JWSError (CompactDecodeError Invalid number of parts: Expected 3 parts; got 5), likely because the token is encoded.

import { getAccessToken } from "@auth0/nextjs-auth0";

const supabase = createClient<Database>(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
  {
    accessToken: async () => {
      const { accessToken } = await getAccessToken();

      return accessToken ?? ""; // eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIiwiaXNzIjoiaHR0cHM6Ly9kZXYta2swd25vZGpvdmMzMzV0Yi5ldS5hdXRoMC5jb20vIn0..qzkE9GTllWTzxy6X.3eTfkT1Ro-6nFWooHqv4Bu4aZbUUqjlpEyiPqNu6heH-zU2Z6YQkNSYABtsWWgdjaZfcjiKKhGWNWmjR6ifyuMb1Ue-XTGyWMpnDmhpOd8uMENctH6U3lgIKejjD7Ff1NUlJ7rGsbvNfYxl7jnX1nAmz9c3o66QVVExRgLJ--c_dNukXb23Op1BdAHqstx6Jl4LcN_gqAY1QEz6E-cz8D7z0NBBLrBH2_e-xO-4KUm_IF4b2Cdf3JjLCDMhr8h988k4rvE9Ny2JkQluetW_U7mHr--wLQ5SX7wio7mJB2xOvt2pQbHNO7TrAQmiexAD_HjAotBB4FVzQYN78YgrlK5Hxbxrjpqz0Zi_Lu16I_0nmMf9gfng3hn37tTYlJA38wWPJxwCFxi6ooAjdNaOGBDmtRO2FZilji0FpEdLNYQLKlYbAfPZn3gEIN8A.P6b_WlgM6Mjred5L7fcGkg
    },
  },
);
await supabase.from("table_that_exists").select("*")

When I try to use the idToken, which I can decode and verify does contain the "role" claim, I get the following nonsensical error: PGRST106 - The schema must be one of the following: but no schemas listed.

import { getSession } from "@auth0/nextjs-auth0";

const supabase = createClient<Database>(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
  {
    accessToken: async () => {
      const session = await getSession();

      return session?.idToken ?? ""; // eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjUyaEhmRFlZdXBncUFqNE1LamlUQiJ9.eyJyb2xlIjoiYXV0aGVudGljYXRlZCIsIm5pY2tuYW1lIjoiYW5uZWkiLCJuYW1lIjoiQW5uZSBJc3RhZCIsInBpY3R1cmUiOiJodHRwczovL3MuZ3JhdmF0YXIuY29tL2F2YXRhci8yZjNjODdjNjJmZjE0NTk2OGY1ZTBlNzk0ZjI2OWQ4MT9zPTQ4MCZyPXBnJmQ9aHR0cHMlM0ElMkYlMkZjZG4uYXV0aDAuY29tJTJGYXZhdGFycyUyRmFpLnBuZyIsInVwZGF0ZWRfYXQiOiIyMDI0LTA5LTA1VDExOjU4OjQ4LjIyM1oiLCJlbWFpbCI6ImFubmVpQHRlc3QuZmVpZGUubm8iLCJpc3MiOiJodHRwczovL2Rldi1razB3bm9kam92YzMzNXRiLmV1LmF1dGgwLmNvbS8iLCJhdWQiOiJmejByczlldUY3dklZTTMwb0VkS29obWRtVVZxbFJBQiIsImlhdCI6MTcyNTU0MDg2MSwiZXhwIjoxNzI1NTc2ODYxLCJzdWIiOiJvYXV0aDJ8RmVpZGV8NjM3NTQ1NjYtZmJhYS00YmUyLThhMmMtMjk0ZTUzMDNkN2MzIiwic2lkIjoiVVZPZTlCM0tIR095cWdSX2pmWjBqQ1RxZFR5Z2dpckgiLCJub25jZSI6IllocW9oX21zVmhmVGhmeXo1WVdoc3JlaVJJZzJwS3lhVHI2QkRMSHY2bjQiLCJvcmdfaWQiOiJvcmdfSUJQZENHZ2c1aGZ6NEFmWiJ9.Y8s3RdRPzyZFK-RuWZxzN3XWodM5ouEDfKbNODjcCnfGzKR9xJVFS-2UfO2vfDT-fxv0c9XMlfPuQIm6IiyIf1yWhP0z403wxBbuMyRVwvQfALCvIzHfqMlbw7kAoathvvt5yooJxmx4ILhajZE3WvZMHKyHnmxV035myF3PtJ5RVue-VJdIc-gzAcODSN47SLj_pobe-h8waukFRXcoF-RV9dFD8J1AppE1BaGskSsKALCILuRfAYavXdgLstSsdb7FQLDm8qhjhNExKtSlmrk4-Wa8mUvbzDWxjT1X8uzSTJERYSL53TnXfde1paMf_rRlOvOxsqXh1Ogl3RnGRQ

    },
  },
);
await supabase.from("table_that_exists").select("*")

I'm not sure what else to do here. As far as I can understand, there is a difference in tokens supplied by Auth0 between a Single Page application (what your guide seems to be using), and a Regular Web Application (what I'm using, and you should use, with NextJS) which might explain the issue, but afaik the idToken seems to be valid.

What's going on here?

System information

• OS: macOS
• Version of supabase-js: v1.191.3 although technically I needed to apply the fix from fix: Use discoveryURL when fetching third-party OIDC config cli#2655 to even get Auth0 to work in the first place
• Version of Node.js: 20.16.0

Additional context

See also supabase/cli#2655 and supabase/cli#2654 for more bugs related to this feature. Both have PRs out to fix them, but no reply.

[dagingaa]

Turns out at least partially the error PGRST106 - The schema must be one of the following: was related to a change in config between supabase cli version 1.172.2 and 1.191.3. In the initial config I've had running since I started using Supabase I didn't specify public schemas:

[api]
# Port to use for the API URL.
port = 54321
# Schemas to expose in your API. Tables, views and stored procedures in this schema will get API
# endpoints. public and storage are always included.
schemas = []
# Extra schemas to add to the search_path of every request.
extra_search_path = []
# The maximum number of rows returns from a view, table, or stored procedure. Limits payload size
# for accidental or malicious requests.
max_rows = 1000

which maps well to the help present in the comments when I generated my initial config.toml file. However, by adding in public explicity, as well as the other schemas present in the current template, it now kinda works.

I still get an error: 22P02 - invalid input syntax for type uuid: "oauth2|Feide|63754566-fbaa-4be2-8a2c-294e5303d7c3" when I try to run my simple select query, but running supabase.rpc("get_my_claims") now returns a 200 OK at least, which should mean I'm authenticated. I suspect my uuid error comes from the still outdated RLS policies, so I'll dig deeper into that.

Anyway, for others attempting this, make doubly sure your config is up-to-date, and that you use the idToken, NOT the accessToken when using auth0-nextjs.