auth

Mixed fealings cause the full context should include plans on both Authorization and Authentication flows at least withing Cloudflare ecosystem. No github examples Anyway good start in the right direction from Cloudflare, yet still long way to go especially compare to the full Ory's offering its built on. Ory's Kratos handles identity, login, registration, recovery, MFA... https://github.com/ory IMHO full scope should include plans on user store, SAML, multi-tenant org model. Good example - Zitadel https://github.com/zitadel has managed UI for orgs multitenancy, OIDC/PKCE supports, etc you can even partial glue RBAC to it Subabase offers managed and opensource https://github.com/supabase/auth Siding "MCP is dead, Skills forever" what bother me about all of them is planning to plug MCPs and rotate keys ... this start hitting the fan very s

Supabase's auth is MIT licensed and OSS, is it not? https://github.com/supabase/auth/blob/master/LICENSE

This is great. Competition is definitely needed in the Authentication/Authorization space. Quick question. How would this compare to supabase/gotrue [0] and permify [1]? [0]: https://github.com/supabase/auth [1]: https://github.com/Permify/permify

thanks for the links > https://github.com/orgs/supabase/discussions/4444 This discussion is about configuration: self-hosters configure configure their services in code[0], using .env vars / docker-compose.yml and should be checking it into source control. Self-hosters are not missing any functionality - the opposite actually: we have a subset of configuration items available on the platform I get that it's different to the platform, but it's (IMO) the more "correct" way - all configuration should be version controlled > https://github.com/orgs/supabase/discussions/4421 This one is about Auth providers. They are also configuration: https://github.com/supabase/auth?tab=readme-ov-file#configur... [0] Configuration in code: https://supabase.com/docs/guides/self-hosting/docker#configu... [1] Terraform: https://supabase.com/docs/guides/platfor

People keep writing this, doesn't Supabase rely on spinning up additional services to leave, meaning you can't leave to another managed offering? Off the top of my mind, PostgREST and go-true? https://github.com/supabase/auth - If you use Postgres you're "locked" into Postgres: a technology with a laundry list of providers. If you leave Supabase, you'll lose the fully managed aspect of 99% of the Postgres providers out there, which confirms the pain the parent comment is describing.

> Microsoft scans to check the website contains malware. IMHO the security blunder is a self-implemented magic link. It's not self-implemented, you can check it out here: https://github.com/supabase/gotrue > Not password protected if the password is part of the URL. It's a token that's valid for a couple of minutes – just like a password reset token. Indeed, in the given implementation, it's the very same as the password reset token. If you consider this implementation as "not password protected", any website with a password reset functionality is "not password protected".

I hate to be this guy, really. I would like to adopt Supabase in my company, but I cannot yet. I commented on a HN post almost a year ago about how hard is to do custom Auth with Supabase. I still haven't find a good solution about it. For example, LDAP Auth is quite crucial in most enterprise settings, yet I have no idea how to do it with Supabase. I can find a workaround for PostgREST by putting a secondary API written in some other language and fiddling with reverse proxies. But how to do with Supabase, such that all other services (realtime,...) works nicely? Is it so hard to provide a function that accept a custom strategy given the HTTP request data? I created an issue[0] almost a year ago on Supabase, which was transferred to Gotrue. I even provided some code examples from Laravel. Even if it is not specifically for LDAP, make some

PSA: Supabase Auth is based on their fork [0] of Netlify's Gotrue [1]. If you are migrating out of Supabase completely you can just drop in Gotrue for authentication. [0]: https://github.com/supabase/gotrue [1]: https://github.com/netlify/gotrue

we integrated Gotrue with PostgREST at Supabase and it works beautifully together https://github.com/supabase/gotrue (forked from Netlify)

Broken how? Feel free to open an issue on http://GitHub.com/supabase/gotrue/issues

For more context, here is the the GoTrue repo: https://github.com/supabase/gotrue You can see how it fits into the full Supabase Architecture here: https://supabase.com/docs/guides/getting-started/architectur...

The advantage of ORY was that it required this somewhat custom frontend (since it's not password based) -- I'm not sure how much easier that would have been with Keycloak (my guess is it would have been harder), and I haven't used Authentik before so I'm not sure. Keycloak is definitely more setup and a bit more clunky. I've never deployed Authentik though, I really need to kick the wheels on it and see how it works. BTW in the simple auth/login space there is also: - Keratin[0] - GoTrue[1] (and Supabase's improved version[2]) - Authelia[3] [0]: https://keratin.github.io/authn-server/#/ [1]: https://github.com/netlify/gotrue [2]: https://github.com/supabase/gotrue [3]: https://github.com/authelia/authelia

In Supabase we use a separate Auth server [0]. This stores the user in an `auth` schema, and these users can login to receive a JWT. Inside the JWT is a "role", which is, in fact, a PostgreSQL role ("authenticated") that has certain grants associated to it, and the user ID (a UUID). Inside your RLS Policies you can use anything stored inside the JWT. My cofounder made a video [1] on this which is quite concise. Our way of handling this is just an extension of the PostgREST Auth recommendations: https://postgrest.org/en/v9.0/auth.html [0] Auth server: https://github.com/supabase/gotrue [1] RLS Video: https://supabase.com/docs/learn/auth-deep-dive/auth-row-leve...

{supabase ceo} You can! A lot of people do. Or you can use the Auth server directly: https://github.com/supabase/gotrue

We run a fork of GoTrue, using the migrations in this PR: https://github.com/netlify/gotrue/pull/254 tbh, our fork[1] has deviated a bit from Netlify's so we need to spend some time with them upstream'ing any changes that they would want to merge (perhaps magic links, Azure logins, OAuth scopes). Long term, I think we will need to run 2 different forks because we have different requirements for multi-tenant. So the benefit here would be sharing "OAuth providers" (eg, if we add Okta, we upstream it, if they add Twitter logins, we pull it) [1] https://github.com/supabase/gotrue