fusionauth-issues

> - Do you support SAML 2.0 clients? There be dragons. (Disclosure: I work for FusionAuth.) Funny story. We had a client doing a SAML integration using HTTP-redirect bindings. It worked when you turned off request signature verification (which is fine for testing, but is like using alg="none" for JWTs, a non-starter in production), but failed when that was turned on. We dug in with the client and another vendor, set up some test servers, and identified the bug[0]. Turns out that you can't canonicalize the signature's URL encoded form, because both uppercase and lowercase hex values are allowed, by the SAML spec. Our open source SAML library[1] has been around for years and used by many clients in FusionAuth and our other projects. It'd never run into this particular edge case. It is a wild west out there in SAML land and it takes years to

This is our major need right now: https://github.com/FusionAuth/fusionauth-issues/issues/1393 Basically, providing a static IP to some EC2 instance traffic so that folks can add an IP to their firewall.

Interesting that they are choosing to provide an integrated solution including user management and OAuth IdP ( https://github.com/kanidm/kanidm/pull/485 ) rather than plug into existing open source or even commercial offerings. Here's a design doc about their OAuth choices: https://github.com/kanidm/kanidm/blob/master/designs/oauth.r... It would seem simpler to go with the Ory approach of "best in breed" for, say network management tooling (most of which they already have implemented), and then integrate with Keycloak, Okta, FusionAuth, the Ory suite, etc for user management. Maybe they didn't want to do that because there are synergies with integrated user management? I dunno, seems like there are a lot of user management tools out there. I also find it interesting that they explicitly disallow a goal of building a better LDAP server. I

I've looked at paseto (and even filed an issue in our repo about supporting them: https://github.com/FusionAuth/fusionauth-issues/issues/773 ) but the thing I keep running into is: * JWT can be secure if you are careful * there is wide support for JWT. (See for example this IETF draft https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-13 as well as the numerous libraries) * it does a simple job "well enough". Maybe paseto can eventually displace JWT, but I have a hard time seeing how that happens.

That does clarify things. To be honest I thought "Editions" was a product alongside "Cloud". So Fusionauth looks pretty good - it does a lot more than I need. Though the lack of a "public path" setting is the first roadblock: https://github.com/FusionAuth/fusionauth-issues/issues/88

I work for FusionAuth and we have some comparisons on our website, but I haven't built an application with each of these. I'd say that dimensions that matter vary so widely for each person and use case, it'd be hard to do a great comparison. Dimensions that matter: * open source or not * standalone application or library/framework you integrate * self hosted or SaaS * authentication, authorization, user management or all three? * standards implementation * integrations with other auth tech (LDAP) * which OAuth grants they support * documentation and developer experience And that doesn't get into specific features that you might need. An example: if you want to modify a user object in the middle of a login flow, Auth0 has rules, we have Lambdas, Keycloak has plugins. How are you going to know what features you need