As soon as I get the access token and refresh token from the provider, how can I create a user? @kiwicopple
(I'll post a complete guide on how to authenticate with a custom provider as soon as I get this right 👍)

const userInfo = await spotifyApi.getMe();
const user = {
    aud: "authenticated",
    exp: 1615824388,
    sub: userInfo.body.id,
    email: userInfo.body.email,
    app_metadata: {
      provider: "spotify",
      access_token: data.body["access_token"],
      refresh_token: data.body["refresh_token"],
    },
    user_metadata: {},
    role: "authenticated",
};

// INSERT IN auth.users

@baptisteArno Seems like Spotify OAuth might be landing soon: supabase/auth#245

Have you found a solution?

@kiwicopple is there any workaround you might recommend for now to byo an oAuth provider. Any API in GoTrue we can use or would it work to handle the custom provider callbacks with edge functions and write straight to the auth table?

@baptisteArno Have you found a solution to create user for customized auth provider?

Thanks for sharing the guide, Grace! I was curious what might be the appropriate way to insert that data into auth.users (or is it not a good idea to do that with custom auth providers/jwts). I ultimately want to make sure all my registered users are in one place in the auth side of the database.

How can we handle token refresh with this?

Same question: How to generate the correct refresh tokens this way?

@gracew So in your solution, the auth tables would contain no user info(for example, the user_id would not be genreated), while only depends on the customized jwt playload to do RLS in posrgresql?

Information on how to use custom auth AND RLS is available in various Supabase docs but it took me a few hours last night to pull it together. So I wrote up this guide, hope it helps some of you!

TL;DR:

1. Obtain the Supabase JWT secret

2. When the user authenticates, set a cookie containing a signed JWT from the server

3. Call setAuth() from the client to make requests as the user

4. Use the JWT data in either your RLS policy or in column default values

Would you mind updating your guide, now that setAuth is deprecated?
https://supabase.com/docs/reference/javascript/release-notes#deprecated-setauth

@gracew You are awesome! Looks like that is a great way to integrate with any authentication layer. I hope supabase would have official support for custom auth (maybe that can be done with functions)

have you found a solution

Pretty sure Keycloak got support in the latest Launchweek!

Yup

https://supabase.com/docs/guides/auth/auth-keycloak

I attempted a PR for Steam provider support
However, I think the main problem is Supabase's reliability on user emails, so I am not sure if this will (fully) work.

+1 for Tiktok

+1 for Tiktok

Anotherrrrr +1 for Tiktok pls!

+1 for these OAuth login options, thanks @kris for mentioning this.

@kiwicopple these networks combined have a total 4.282 BILLION monthly active users, this would be massive for supabase to support these OAuth login options and will increase adoption of builders using supabase and more users using the apps on your platform.

Please consider TikTok, Instagram and Pinterest login.

+1 for tiktok

I'll upvote. So few plugins supporting this very popular Asian network.

Agreed. LINE is also used in a lot of Southeast Asia too. If you counted by the numbers... it probably is just as popular as telegram. Probably more so.

I think SAML 2.0 integration is possible with Authentik and Supabase

+1 for Steam

VK and Yandex

I attempted a PR for Steam provider support
However, I think the main problem is Supabase's reliability on user emails, so I am not sure if this will (fully) work.

Possible workaround for now, until Supabase implements support for generic OAuth2/OIDC provider: https://github.com/orgs/supabase/discussions/6547#discussioncomment-9049664

Hey, yeah I saw this and I like the idea. The only issue is that you can have only one provider of each type right? This limits us on partners we can work with because we'll only be able to create one keycloak provider.

In this case maybe you can install Keycloak and use it as an identity broker instead of Supabase.

Yeah I'm considering this, we're actually just keen on dropping Supabase entirely in favor of something like Ory that doesn't make that an issue, as our use case might require us to add multiple custom oauth providers in the future to our login solution.

Hey @blechatellier, any chance you could link the information regarding starting this feature in September? We're contemplating on moving away from Supabase, but if the waiting time is ~5-6 months, we might just not do that - depending on what's in store.

@J0 - would love to hear your input - is this in the works? And will we be able to eg register different providers with the same provider type? the solution is currently quite limited, but Supabase offers us what we want in terms of experience - so we would rather stay :)

@RobbyUitbeijerse second hand information from a convo I had on Twitter https://x.com/stojaaan/status/1795421822114005163?s=46&t=zIzrZmJzfRoF4kjsueapFA

Thanks @blechatellier! Let's see...

@hf Hello there! Is this still planned in to be started in Sept?

@hf Any update on this?

Completely agree. Decided I have to move away from Supabase. Assumed this was going to be an option, spent a ton of time investing in the platform and now poof. wasted

Same. Switched to auth.js because of this

@antonlvovych Hey was it easy to switch?

I see there is https://authjs.dev/getting-started/adapters/supabase?framework=express

Do you use row level security?

Also interested

And also Gosuslugi? =)

and MAX messanger ? 😂

same for us!

Hey! What are you planning on switching to? Custom OIDC is a dealbreaker for us too

Hey! What are you planning on switching to? Custom OIDC is a dealbreaker for us too

Hey! For us, keycloak has always been on our radar, it was actually one of our first considerations. However, its operational complexity (setup, scaling, maintenance) didn't align with our needs when we initially adopted supabase. Now, though, the lack of custom OIDC support forces us to reevaluate.

Switching to another baas (firebase, etc.) felt counterproductive, we'd just end up in the same situation in a few month, dependent on someone else's roadmap for critical features. While self-hosting supabase could work technically (we've looked into modifying GoTrue for extra providers), it defeats the purpose of using a managed service in the first place. If we're going to invest in infrastructure overhead, we'd rather pick a battle-tested, extensible solution like keycloak, even if it means sacrificing some of supabase's cool features (storage, functions, etc.).

Just to be clear: supabase has been doing very good for our auth workflows, and this isn't a reflection on the project or the team (y'all are doing incredible work). But since we're only using supabase for auth/oauth, the cost-benefit calculus shifts. keycloak, despite its steeper learning curve and a few other drawbacks, feels like the best option right now.

Would still love any updates on oidc timelines, though, if priorities shift, we'd absolutely revisit supabase.