saml-idp VS fusionauth-samlv2

To be fair, SAML itself isn't that difficult -- Shibboleth is just not very good.

I implemented a SAML IdP [0] in MUCH less time than it took to configure Shibboleth. The specification for SAML is pretty easy to comprehend.

The implementation is really an experiment, but the configuration and usability is significantly better. Improving the implementation doesn't affect this. In some closed-source forks I've written a production version that's been in use for several years.

[0] https://github.com/rkeene/saml-idp/blob/master/lib/saml/saml...

This repository is SAML v2.0 bindings in Java using JAXB.

Disclosure, I work for FusionAuth, which can both integrate with and compete with Supabase.

Welcome, Supabase, to the world of SAML/SSO. It's a hairy one, but single sign-on is undifferentiated and really great for customers, so I'm glad you joined.

A few thoughts:

* Consider adding identity linking to your roadmap. I noticed[0] that you don't support it, and will create duplicate accounts if someone uses SSO with the same email address that an existing account has. As a model, FusionAuth offers seven linking strategies[1]. This flexibility lets you handle more use cases.

* I'd encourage you (and your customers) to test across as many SPs as you can. SAML is an 800+ page specification and even though we've been offering SAML for over 10 years and have open sourced our bindings[2], we still have edge cases that pop up.

* I'd love to add FusionAuth as a SAML SSO provider to your docs, so will put that on our team's doc roadmap and submit a PR. :)

* Not related to SAML, but I'm glad that you are working towards supporting PKCE. I hope you deprecate the implicit grant; the XSS threat is very real and the OAuth 2.1 spec (still in progress) basically deprecates that grant[3] throw omission. Also, we agree that setting cookies (HTTPOnly and secure, please) is a great way to store tokens[4] and that is worth requiring a server side component in applications.

Finally, I understand why this is part of a paid offering; SAML is often used to segment out enterprise customers with $$$. You like to make money, as do we all. But I'd encourage you to think about a free tier because it is so helpful to the user experience. Maybe 1 SAML connection could be part of the base offering?

0: https://supabase.com/docs/guides/platform/sso

1: https://fusionauth.io/docs/v1/tech/identity-providers/#linki...

2: https://github.com/FusionAuth/fusionauth-samlv2/commits/mast...

3: https://oauth.net/2.1/

4: https://fusionauth.io/learn/expert-advice/oauth/oauth-token-...

We recommend OIDC, but support SAML because customers.

We implemented our own SAML processing library, too: https://github.com/FusionAuth/fusionauth-samlv2

(We pay for valid security bugs.)