External OAuth Provider Requests

[J0]

This issue is for tracking requests/demand for integration with External OAuth Providers. Give a comment a thumbs up if you want the connector built or drop a comment if you wish to work on any of the providers below.

We will prioritise providers based on the number of upvotes/thumbs up so do upvote your favourite providers

[J0]

Support Steam as an external OAuth Provider

Currently, Supabase does not support Steam as an external OAuth provider.

Describe the solution you'd like

Support Steam as an external OAuth Provider. https://partner.steamgames.com/doc/features/auth

Describe alternatives you've considered

N/A

Additional context

This article describes how Steam's login method works.

[J0]

Add Patreon as OAuth provider

Support Patreon oauth.

Describe the solution you'd like

See feature request netlify/gotrue#312

[J0]

Add Quickbooks as an OAuth provider

[J0]

Add Orcid as an OAuth provider

Hi

I'd like to publish an app that other researchers can contribute to without signing up to anything, just using the orcid credentials they have for publishing to journals. Could you please add Orcid to the OAuth providers?

https://info.orcid.org/documentation/features/public-api/orcid-as-a-sign-in-option-to-your-system/

All the best and many thanks for the great work!

[J0]

Add global.id as OAuth Provider

Link to homepage
Link to docs

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

Letting users in with a privacy-friendly OAuth Provider while accessing/verifying user data in a privacy-friendly manner if required.
For (at least currently) no cost.

Describe the solution you'd like

Adding global.id as sign-in/up option and storing requested data in the user metadata.

Describe alternatives you've considered

Didn't really find a good alternative to this provider.

Additional context

I would like to implement that but I have never used go before, nor do I have a clue on how to integrate it in the existing codebase.
Also, the global.id docs are somewhat odd and I've never really dealt with implementing OAuth.
Maybe it can be done similar to using Auth0 but instead, use global.id but idk. Article about Supabase with Auth0

[J0]

Singpass login

• Sign-in with Singpass
• https://api.singpass.gov.sg/library/identiface/developers/backend-oauth2-jws

Note: Singapore government might move to use SGID

[J0]

Foursquare/Swam login

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

Would love to be able to authenticate users with Foursquare/Swarm

Describe alternatives you've considered

Currently using passport-foursquare

[J0]

SoundCloud Login

Please add SoundCloud OAuth provider.

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

To extend music streaming platform authentication.

Additional context

https://developers.soundcloud.com/docs/api/guide#authentication

Note: there is an existing PR -- #269 which contains an initial implementation

[J0]

Ethereum Login

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

I'd like to let my users log in with their Eth wallet (Metamask, etc)

Describe the solution you'd like

Just like Uniswap does.

Describe alternatives you've considered

Looks like Redwood has an Eth login.

Additional context

n/a

Note: there is an existing PR -- #269 which contains an initial implementation

[J0]

Auth0

Would it be possible to include Auth0 as a login provider. Would like transition over to Supabase however this is preventing me from doing so.

Describe alternatives you've considered

Tutorial on importing users from Auth0.

Relevant resources:

• https://github.com/nextauthjs/next-auth/blob/main/src/providers/auth0.js

[J0]

Tik Tok

TikTok recently published their OAuth flow
https://developers.tiktok.com/doc/login-kit-web

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

For the application that I am working on, we convert users from TikTok. Currently, we plan to authenticate them from using Phone authentication, but TikTok support could drastically improve our conversion.

Describe the solution you'd like

Social login with TikTok is supported similar to existing 3rd party providers.

Describe alternatives you've considered

The only other alternative would be to host our own authentication server and use it in tandem with Supabase. Not particularly ideal.

Additional context

Note: there is an existing PR -- #269 which contains an initial implementation

[J0]

Netlify

Additional context

https://twitter.com/jlengstorf/status/1429611357356187652

https://app.netlify.com/user/applications

Relevant Comments:

Might need to hold off on this one until some of the security issues here are covered: https://community.redwoodjs.com/t/i-implemented-a-netlify-oauth-not-identity-auth-provider-but-im-not-sure-i-should-have-and-why/903

[J0]

Kakao [ Completed ]

Requested on: supabase/supabase#5200

Developer docs: https://developers.kakao.com/product/kakaoLogin

Corresponding PR: #366

[J0]

Add Snapchat as External OAuth Providers #436

Relevant PR: #449

[carlobeltrame]

Add generic OAuth2/OIDC provider

#451 (comment)

I'd like to work on a generic OAuth2 provider. Since the comments of @rohanliston in August, @kangmingtay has updated the CONTRIBUTING.md text to suggest that such a generic provider is officially regarded as a possible way forward.

By default, I would go for a generic OAuth2 client, similar to the one described by the auth0 docs. This is as opposed to a generic OIDC flow, which was previously present in gotrue but was then removed in #927, for reasons which are explained here, and which sound like the Supabase team needs to resolve things internally first. If the generic OAuth2 client is the wrong direction to head in, please let me know.

Edit: See #1372 for the PR.

[MonsterDeveloper]

@J0 any updates on the Telegram provider? It has been more than a year now since its request, and as far as I can see it is one of the most requested providers in this thread.

[Mutondi]

Add generic OAuth2/OIDC provider

A generic OAuth2/OIDC provider similar to what Auth0 offers would cover most (if not all) of the provider requests in this thread in one hit.

This would enable developers to simply provide, at a minimum:

• Authorisation Server URL (which provides a .well-known/openid-configuration endpoint to discover token URLs etc).
• Client ID
• Client Secret
• Callback URL
• (maybe) a mapping for claims?

I'm surprised this hasn't already been suggested. Is there some complexity that I'm missing?

Is there any progress on this?

[stripuramallu3]

Linear

I would like Linear as an OAuth Provider

Documentation: https://developers.linear.app/docs/oauth/authentication

[carlobeltrame]

Is there any progress on this?

@Mutondi I have started working on it, currently I am looking into how I can extend the database schema in order to store the additional information required for genericity, such as the field mapping.

I could use this extension myself in February 2024. So if you have the time to test the feature with your own provider once I open the PR, that would be great news.

Edit: See #1372 for the PR.

[Whats-A-MattR]

Support Steam as an external OAuth Provider

Currently, Supabase does not support Steam as an external OAuth provider.

Describe the solution you'd like

Support Steam as an external OAuth Provider. https://partner.steamgames.com/doc/features/auth

Describe alternatives you've considered

N/A

Additional context

This article describes how Steam's login method works.

Is there an ETA for Steam as an Auth Provider? Or even a Custom Provider option?

[jessebot]

Support Zitadel as a provider

Please consider adding support for ZITADEL. I see there is already KeyCloak support, so I could try to copy that for Zitadel, as in most instances Zitadel drops in as a replacement pretty fine as both are OIDC compliant and common self-hosted open source Identity Providers.

• Zitadel Go backend quickstart
• https://github.com/zitadel/zitadel-go

I am not sure if I should hold off on it based on the comment in the CONTRIBUTING.md. Let me know if I should go ahead and work on this.

But I did also find this in the code so maybe I don't need to do this after all?:
https://github.com/supabase/gotrue/blob/379b06665052261122482acf2c9d47e81346f1a4/internal/api/provider/oidc.go#L329-L340

Still happy to do the work, just need a little guidance 🙏

[carlobeltrame]

@Mutondi, @rohanliston, @kangmingtay, @bdelwood, @James3UK, @sannajammeh, @bluengreen, @jessebot, @chrisjh, @agrantdeakin, @mstade, @WildEgo, @kermado, @JoaquimLey, @naohiro-t, @BayTec, @jamiefolsom, @point-source, @Whats-A-MattR and everyone else who has mentioned or reacted to a generic OAuth provider:

I have implemented a first version of a generic OAuth provider at #1372.

If you have the means, it would help a great deal if you could test it with some real-life identity providers (even ones which are already supported by gotrue would help). I have so far tested it using an application of my own. But the more we can test this new all-purpose OAuth provider the merrier.

[rahul3399]

add miniOrange as OAuth Provider

[Wintersboy]

Would love to see Yahoo in the list of auth providers. Would make accessing the Yahoo Fantasy API so much better.

[MiryangJung]

Is there any progress on the generic OAuth provider, is possible submit PR that adds another social login provider?

[biblebreeze]

Add Yahoo as OAuth provider

Support Yahoo oauth.

Describe the solution you'd like

See feature request #1191

Any feedback on adding Yahoo oauth?
https://developer.yahoo.com/oauth2/guide/

[FredrikCarlssn]

Epic as OAuth provider

Saw this request in the discussions and thought I will bump it by posting it here as well.

Would be great to see this feature being added!

[maurotrigo]

Support Instagram as an external OAuth Provider

Currently, Supabase does not support Instagram as an external OAuth provider, although it does support Facebook. I understand that the flow would be very similar.

Describe the solution you'd like

Support Instagram as an external OAuth Provider. More here.

Thanks!

[mekkoo]

Support LINE as a provider

LINE is a dominant IM app mainly in East Asia. The social login is widely used, and there are many people who want to use it with Supabase Auth.

LINE's user numbers in different countries as of 2024 are as follows:

• Japan: Approximately 95 million monthly active users
  • About 88% of Japan's adult population uses LINE
• Thailand: Approximately 51 million monthly active users
• Taiwan: Approximately 21 million monthly active users
• Indonesia: Approximately 13 million monthly active users

Other notable statistics:

• LINE's global monthly active users are estimated to be around 224 million
• The total monthly active users in the four main markets (Japan, Taiwan, Thailand, and Indonesia) is approximately 178 million
• LINE offers its services in more than 230 countries

Official document (ENG): https://developers.line.biz/en/docs/line-login/overview/
Other topic: https://github.com/orgs/supabase/discussions/4500

[ekankr2]

Support NAVER as a provider

Please consider adding NAVER auth sign in provider.
Almost half of South Koreans use NAVER auth signin.
There is Kakao login as a provider.
I think NAVER auth provider would also be necessary too.

Official docs : https://developers.naver.com/products/login/api/api.md

[purpleKarrot]

Support GitHub Apps as provider

Both OAuth apps and GitHub Apps use OAuth 2.0.
In general, GitHub Apps are preferred over OAuth apps.
For more information, see "Differences between GitHub Apps and OAuth apps."

[wolfspyre]

I'd love to see Gitlab SELFHOSTED as an option for an auth provider.

[Whats-A-MattR]

I'd love to see Gitlab SELFHOSTED as an option for an auth provider.

I'm not sure that would serve the purpose of the project. That would only be useful for internal use cases, unless you're going to write it and submit a PR I can't see time being spent on this. Sorry to be blunt.

[wolfspyre]

I'd love to see Gitlab SELFHOSTED as an option for an auth provider.

I'm not sure that would serve the purpose of the project. That would only be useful for internal use cases, unless you're going to write it and submit a PR I can't see time being spent on this. Sorry to be blunt.

Heya, Matt!
I hear you, and both agree and disagree with you... :)

There's already a Gitlab provider, I'd expect that the only difference between the two is the endpoint.

Gitlab encourages self-hosting.
Github does not.

While many selfhosted rigs don't use legitimate ssl certs, the vast majority do.
I would expect that the only change needed would be to allow one to override the endpoints involved.

If it were truly that simple, I disagree with your assertion that it would serve the purpose of the project.

if it were NOT that simple, (I don't know, with confidence, one way or the other, quite honestly.) I can concede the point that time/energy spent likely aren't worth the effort.

However, assuming it is that simple, (hey, gotta be optimistic sometimes, right?) I don't see much of a downside... altho admittedly I'm likely missing some significant facet of complication due to ignorance ;)

so... can you help me understand what I'm missing? :)

[Whats-A-MattR]

The main thing I would suggest may prevent this is that the package is focused on Social Auth. ie. Everyone can have a Facebook account, or a Twitter Account, or Google, or x ,y ,z, etc. and if the developer chooses, they can use those services to authenticate.
Not everybody (I hope?) can have an account on YOUR GitLab, which is what differentiates it from hosted GitLab.
I can sign up for (hosted) GitLab right now, as a regular old user, and then sign in to a site made with Supabase, where GitLab is enabled as an Auth Provider using my GitLab account.
I cannot, however, simply sign up for your hosted GitLab - at least I shouldn't be able to as per my understanding where self-hosted GitLab is a companies own thing for their people only.

Hope that makes sense.

[wolfspyre]

The main thing I would suggest may prevent this is that the package is focused on Social Auth. ie. Everyone can have a Facebook account, or a Twitter Account, or Google, or x ,y ,z, etc. and if the developer chooses, they can use those services to authenticate. Not everybody (I hope?) can have an account on YOUR GitLab, which is what differentiates it from hosted GitLab. I can sign up for (hosted) GitLab right now, as a regular old user, and then sign in to a site made with Supabase, where GitLab is enabled as an Auth Provider using my GitLab account. I cannot, however, simply sign up for your hosted GitLab - at least I shouldn't be able to as per my understanding where self-hosted GitLab is a companies own thing for their people only.

Hope that makes sense.

Heya Matt!

First, thanks for talking about it :)

I appreciate the gift of your time and energy.

Thank you.

I think this might be where our lenses diverge...

I'll elucidate my perspective... my intent is not to argue or assert that one or the other is more 'right'.... Rather just trying to express the logic behind my reasoning.. (or what passes for logic between these ears ;) )

As I see it, The package is focused on facilitating external auth for a tool.
It's common for teams to want to offload the responsibility of user auth to $(notmyproblem)

Auth facilitates that offloading, by providing a conduit for brokering auth tokens.

Now, a vast majority of users will absolutely lean on ubiquitously-accessible services to provide those tokens, as such, I wholly agree with you that this functionality will only increase the utility derived from the tool for a small cohort of users.

However, that doesn't mean that there's no value in the ability to additionally support variant-instantiations of those ubiquitously-available services' facades for less-ubiquitously-available auth-brokers.
So long as it behaves the same
Admittedly, that's a significant caveat... and may cause more problems than it solves, as the support burden around snowflakes is .....
well... I don't need to tell you... :) you clearly already know :)

Nevertheless, Is the use-case for Auth ONLY for environments which are exposed to the public Internet?

I'd think that's kinda short-sighted, in that Auth shouldn't REALLY care who it's getting auth from, as
Its role is simply to be the abstraction layer between ${APP-DESIRING-AUTH-VALIDATION} and ${API-PERFORMING-AUTH-VALIDATION}; right?

The audience diversity of ${API-PERFORMING-AUTH-VALIDATION} isn't really relevant, is it?

Allowing customers to use their on-prem services to legitimize their users seems like a thing that devs would derive value from, rather than being burdened by....

I was simply figuring that an upside would be a reduction in external network traffic, latencies around auth, as well as greater flexibility offered to app devs to subsequently offer to their customers..

¯\_(ツ)_/¯

So.. that's the lens I was using when proposing this...
if the expectation is that Auth only provides value to tools that wish to use cloud-connected services, I can totally see why the idea has no merit.

[Whats-A-MattR]

However, that doesn't mean that there's no value in the ability to additionally support variant-instantiations of those ubiquitously-available services' facades for less-ubiquitously-available auth-brokers. So long as it behaves the same Admittedly, that's a significant caveat... and may cause more problems than it solves, as the support burden around snowflakes is ..... well... I don't need to tell you... :) you clearly already know :)

Yeah, quite burdensome - especially when each installation may differ and having to support different environments complicates things greatly.

Nevertheless, Is the use-case for Auth ONLY for environments which are exposed to the public Internet?

The issue I foresee isn't related to cloud or no, it's purely around number of uses that will make use of it.

I'd think that's kinda short-sighted, in that Auth shouldn't REALLY care who it's getting auth from, as Its role is simply to be the abstraction layer between ${APP-DESIRING-AUTH-VALIDATION} and ${API-PERFORMING-AUTH-VALIDATION}; right?

Completely correct, agreed.

The audience diversity of ${API-PERFORMING-AUTH-VALIDATION} isn't really relevant, is it?

Only in terms of priority, very few users would equate to low priority.

So.. that's the lens I was using when proposing this... if the expectation is that Auth only provides value to tools that wish to use cloud-connected services, I can totally see why the idea has no merit.

I think there is a slight miscommunication in my message. I am not saying that such an integration would be useless, more than because of the specificity of it's nature and the small cohort that may end up using this, allocating dev time may be a difficult ask.

I completely agree there is value in it, but it's substantially less value than a larger, less bespoke integration (bespoke in that there are many more variables for the IdP environment etc. despite being ~ hopefully ~ very similar to the cloud version).

I think dev time would be better spent on 'generic' and extensible connectors rather than bespoke solutions for on prem.
Ie. Generic SAML (already exists, could be better), Generic OIDC, Generic OAuth - therefore enabling users to integrate whatever suits their needs.

[wolfspyre]

concur on all. Glad to have interacted ;)

Thanks for your perspective and input...

Totes agree on priority, too. I was mostly just adding the request as if it's not made, there's no way for y'all to gauge interest

Thanks for reducing toil for devs. Its appreciated.
You're apprecaited.

❤️🐺w