I'm struggling to understand your use case here, but here are some thoughts that may be helpful.
You can use one Supabase Auth project to do all of your user management. You can use the JWTs issued by this project across any other system. You need to configure those systems to "trust" those JWTs, usually by sharing the signing key (JWT secret) with them. They can then base their allow / deny decisions on the JWT.
You can even do this with as many Supabase projects you want. You don't have to use Supabase Auth with all of them. Do note that once you use physically different machines, you need to sync them up and that's quite a big can of worms.
> Question for Supabase: Is it possible to just have a form with username + password and POSTing the login details?
Yes this is how basic email+password sign-in works. No redirects are necessary. For the rest of the flows, some form of redirect is mandatory because that's how the authentication protocols work and we've found it convenient to implement other logins like magic links, email confirmations, etc.
Supabase Auth engineer here. PostgREST only has "static" asymmetric JWT support. It can't load from `/.well-known/openid-configuration` endpoints. We are tracking this internally to add better UI and support for third-party OIDC.
Most of the OIDC identity providers don't rotate the keys very often, so you can follow the `/.well-known/openid-configuration` endpoint to get the JWKS JSON, and set that as the JWT Secret in the project's dashboard. (It's a bit hacky I know, we're going to be improving the UI on this.)
I know this has been used with Firebase Auth, which is also OIDC compatible with asymmetric JWTs.
EDIT:
> How do you get SSO to work for auth providers like Auth0 and AAD that only provide public keys via an endpoint?
Actually what you're describing is technically not "SSO" but using another Auth system with the rest of the Supabase stack. OIDC support for SSO -- where you use Supabase Auth with Azure AD for example -- is on the roadmap, but only SAML is supported with this announcement today.
Self-hosting is easier said than done. You can do it, but maintaining the infra, scaling, performance, security, updates, downtime, all of that is a _giant_ overhead. It's not against our business model for self-hosting to not work well. Everything we do is open-source and we don't "supplement" it with features from closed source code.
You can use one Supabase Auth project to do all of your user management. You can use the JWTs issued by this project across any other system. You need to configure those systems to "trust" those JWTs, usually by sharing the signing key (JWT secret) with them. They can then base their allow / deny decisions on the JWT.
You can even do this with as many Supabase projects you want. You don't have to use Supabase Auth with all of them. Do note that once you use physically different machines, you need to sync them up and that's quite a big can of worms.