Signing in with a generic OAuth2/OIDC provider

[OliverM]

Hi, I'm really struggling to implement a login flow that uses a generic OAuth2/OIDC external provider rather than having to use a specific one like Google. I feel like I must be missing something really obvious since all the supported providers are all just minor variations on the standard OAuth2/OIDC flows, so surely there's a way to integrate with them without having to open a Supabase PR for a new provider??

Can the code in this PR be used with arbitrary OIDC providers like Okta, or am I still bound to the pre-existing list of external OIDC providers (google, apple etc)?

Thanks!

[megacherry]

@OliverM

If you read in this issue i also struggle at this point. I get various errors if i use react-native-google-signin/google-signin or invertase/react-native-apple-authentication.

My last try was to get apple authentication working. But i struggle with this error: {"message": "oidc: invalid configuration, clientID must be provided or SkipClientIDCheck must be set", "status": 400}. I get a valid token and the nonce, but it doesn't matter how you configure the external oauth provider in supabase (for example https://supabase.com/docs/guides/auth/auth-apple).

I hope they will make a statement soon, because we want to integrate apple and google sign in for almost a half year.

[corasan]

Were you able to figure it out? This is exactly what is happening to me.

[megacherry]

Were you able to figure it out? This is exactly what is happening to me.

No, but I think that at least fixes the problem with Apple authentication: supabase/auth#689

[nietsmmar]

Is there a solution by now? I need to implement OIDC auth for a provider that is not listed. How can I do this?

[dtinth]

I was able to integrate Supabase with a custom authentication provider by using Keycloak as the provider (as it’s one of the few providers where you can configure custom URL for it).

When I sign in with this code:

client.auth.signInWithOAuth({
  provider: 'keycloak',
  options: { scopes: 'openid' }
})

Supabase Auth performs a standard OAuth 2.0 authorization code flow through the OpenID Connect protocol, but rather then consulting the /.well-known/openid-configuration file, it uses hardcoded URL patterns, so you may have to do some workaround (e.g. setting up some kind of proxy or redirector) to match Supabase’s expected URL structure:

• ${url}/protocol/openid-connect/auth
• ${url}/protocol/openid-connect/token
• ${url}/protocol/openid-connect/userinfo

Note that if userinfo doesn’t include "email_verified": true in the response, signing in will fail (and a confirmation email will be sent from Supabase) unless you turn off the Confirm email setting in the Email provider. (This setting takes effect in other providers even if Enable Email provider is turned off.)

[weslien]

Why not just bundle the ory stack (ory.sh, https://www.ory.sh). It covers all the functionality needed, has the proper licensing, modular architecture and postgres as a backend. I'm working on adding it as an extension for my own use, but it feels like it would make a lot of sense.

[jsanko9]

My solution just sets up Supabase’s expected endpoints to redirect/proxy to the real endpoints.

• https://github.com/creatorsgarten/creatorsgarten.org/blob/main/src/pages/protocol/openid-connect/auth.ts
• https://github.com/creatorsgarten/creatorsgarten.org/blob/main/src/pages/protocol/openid-connect/token.ts
• https://github.com/creatorsgarten/creatorsgarten.org/blob/main/src/pages/protocol/openid-connect/userinfo.ts

This is great solution, but doesn't it interfere with PKCE ?
When I tried this trough Nuxt/Nitro, I have ended up with

{"message":"no Route matched with those values"}
at ?error=invalid_request&error_code=400&error_description=OAuth+state+parameter+missing

due to error at
http://localhost:54321/auth/v1/callback?error=server_error&error_code=500&error_description=Unable+to+exchange+external+code

[patrickjmcd]

@jsanko9 did you ever get this figured out? I'm pretty stuck too

[jsanko9]

@jsanko9 did you ever get this figured out? I'm pretty stuck too

I did progress through it, but I didn't solve it completely.
I don't recall exactly, but this issue could have been due to running wsl docker and docker desktop at the same time - backend and frontend were split. OR it was due to docker routing where you can't access docker locally unless you can route it through the network. I solved that by altering the host file.

But after all this I was still stuck on issue with it not being able to verify code(PKCE).
Could be an issue with me trying to do it all locally. Unfortunately I will be out for a month now before I can continue.

[APTy]

Appreciate this thread 🙏 I was able to implement this with Keycloak and went into some detail on it here: Supabase generic OIDC authentication. Hope it's helpful to whoever find this thread in the future 🙌

[yairyairyair]

I really need this feature.... What can we do?

[nietsmmar]

Sadly only what APTy wrote here. This seems to be on the roadmap but I did not hear from the supabase team about any more concrete schedules to work with. Lacking this feature is really tough for us.

[yairyairyair]

I would PAY for this feature and I am sure others would as well....

[nietsmmar]

Are there any news to this? If this is on the roadmap in 2026? it is very critical for us.

[cemalkilic]

Hey everyone, Cemal here from the Supabase Auth team.

UPDATE: Custom OAuth2/OIDC providers are available in Supabase Auth. Docs here: https://supabase.com/docs/guides/auth/custom-oauth-providers

We’re working on support for generic OIDC/OAuth2 providers, and the auth server work is already done:
supabase/auth#2357

We’re now working on making this available in the platform (i.e. the Supabase Dashboard) so you can start using it easily.

[cemalkilic]

Coming to the Supabase Dashboard next week!

[nietsmmar]

Coming to the Supabase Dashboard next week!

@cemalkilic
It is not there yet right? At least I can't find it.

[cemalkilic]

Hi @nietsmmar , this was released earlier last week. Docs here: https://supabase.com/docs/guides/auth/custom-oauth-providers

[nietsmmar]

@cemalkilic I already saw and I am already using it! Thank you so much for this feature!

[elyobo]

@cemalkilic this sounds great, but it doesn't seem to work with the local dev env yet, is that coming (is there an issue I can follow - can't seem to find one)?

Edit: I'm doing an Okta sign in myself (i.e. I don't need Supabase to do the flow, wouldn't provide the secret anyway) and only need Supabase to validate the token, it seems like we can (ab?)use the Keycloak config to do this locally and in production so the new custom provider setup is redundant when simply verifying an id token.

Edit 2: in dev yes, but in prod no (Keycloak auth errors with provider_email_needs_verification, Okta does not provide email_verified in the id token.

Edit 3: inviting the user with a magic link and then authing them with it to create the session instead, I guess I don't need supabase to verify the Okta token, I can do that on my side. Would be nice to have this supported in local dev though!