fusionauth-samlv2 VS mundane

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.)

I'm the author of Mundane, which wraps BoringSSL, which is written in C. We have some internal utilities which make it safer to work with C objects by doing a certain amount of automatic memory management and lifecycle tracking.

Most problems with security specs and libraries that implement them are communication problems. They involve people incompletely describing or understanding their requirements, capabilities, or threat model. Usually this also involves providing/using interfaces that are not ergonomic (https://github.com/google/mundane/blob/master/DESIGN.md), which in turn comes from the spec trying to do too much (as XML Signature does).

I don't know how GPT could help with that. If anything I would expect it to bias toward things it has already seen, which is the opposite of what you want when writing a new spec/library aiming to avoid past mistakes.

I'm quite intrigued by mundane which is cryptography library with a Rust interface that contains lots of code from OpenSSL (via BoringSSL, which is a fork of OpenSSL).

(https://sequoia-pgp.org/, https://github.com/google/mundane, etc)