fusionauth-issues VS OpenID

Gotcha. We definitely don't have fine granularity around when MFA is required (open issue here: https://github.com/FusionAuth/fusionauth-issues/issues/2285 ).

Other than that I'd suggest putting a page in front of our login pages with the domain logic, and modeling each set of emails as either an application, organization or tenant, depending on the specific features you need.

Either way, hope you find the right solution for your needs!

Great question. Appreciate the interest.

I can only speak from my perspective as an employee, not the whole company. It is something I've thought about. I will also ask the CEO/founder or other leaders to weigh in.

Many devs care about open source when they are evaluating a solution, but many really want "free as in beer". They want to try a product without getting out the credit card or engaging with sales. We cater to the latter category, which wants to understand the product quality without talking to any sales people.

Some of these folks use our community product for their production needs, which is perfectly fine. We have people running FusionAuth in production with 1000s of tenants or 10000+ applications. (I always say they "pay" us by filing bug reports, giving feedback and voting on feature requests.)

But some decide they want to pay us for hosting, support or advanced features. Those choices help us build a business.

Devs, and especially buyers, are interested in sustainability of a product they are going to integrate into their system. An auth provider isn't a javascript widget that you can easily drop in or remove from your system. It embeds in your system, even if you stick to a standard like OIDC, and is difficult to switch from, especially at scale. You want to be sure the company and product is going to stick around. (If you want to make sure you can run the product even if everyone at FusionAuth wins the lottery, we do offer source code escrow for a price, but haven't had anyone take us up on it.)

FusionAuth is a profitable company (we did recently raise a round to accelerate growth, you can read more about that here [0]). Open source companies often have a hard time meeting the profit goals of the market or investors. This is a known issue and often results in relicensing or changing the rules, as we've seen with Hashicorp[1] and Elastic[2]. This switcheroo can cause issues, confusion, and ill-will; FusionAuth's licensing avoids that.

FusionAuth also develops in the open[3]. This open development process gives us another common benefit people get from OSS--community feedback.

Also, I don't want to throw shade at Ory and Zitadel, since I have no idea about their finances (apart from a brief look at Crunchbase, which shows they've raised 22.5M[4] and 2.5M[5] respectively). I hope they're building sustainable businesses, but selling closed source software is a sure route to a profitable business that has built many big companies (including in the auth space, such as Okta or Auth0). Again, this is not FUD (or at least I don't intend it to be!), just an honest assessment at the difficulties of making money in open source dev tools [6].

We also compete on features, support and documentation. Again, I can't speak to Ory or Zitadel; they look nice, but I haven't built anything with them, so it is hard for me to know how good they are. I do know that we have had many clients appreciate of those aspects of our product.

To sum up:

* FusionAuth has a free option, which helps reduce friction and gives some of the benefits of OSS. The open process and escrow also give some of the benefits of OSS.

* Some devs and buyers care about business sustainability, especially when integrating a tool deeply into their application. FusionAuth will never have to worry about relicensing a version because AWS is eating our SaaS revenue stream, for example.

* We offer great support, documentation and intricate auth features at a reasonable price.

Hope this helps.

0: https://fusionauth.io/blog/fusionauth-and-updata

1: https://www.hashicorp.com/license-faq

2: https://www.elastic.co/pricing/faq/licensing

3: https://github.com/FusionAuth/fusionauth-issues/issues/

4: https://www.crunchbase.com/organization/ory/company_overview...

5: https://www.crunchbase.com/organization/zitadel

6: I wrote about this a few years ago on my personal blog: https://www.mooreds.com/wordpress/archives/3438

Disclosure, I work for FusionAuth.

> Multi-tenant (each of my customers gets a fully separate directory, with access to all tenants for our admins)

Yup.

> SAML and OAuth (customers can set up SAML themselves via the SaaS interface, or we set the SP up for them)

You'd have to build an interface using our APIs for this. Not available out of the box, but we do have it in the general roadmap (https://github.com/fusionauth/fusionauth-issues/issues/91 is the tracking issue).

> Rule based group assignment based on SAML attribute evaluation (e.g. assign users to this group if the attribute X = Y)

You could do this with Lambda HTTP Connect (a paid feature) or webhooks (a free feature. https://fusionauth.io/docs/v1/tech/lambdas/#using-lambda-htt... has more

> APIs to manage users, groups, organisations (tenants)

Yup.

My employer (FusionAuth) has the same feature in our community edition and it's quite popular: https://fusionauth.io/docs/v1/tech/passwordless/magic-links

It is glorious from the user perspective, but there are actually some subtleties from the implementation perspective that caused us some grief.

First of all, you have email configuration and deliverability. The answer is to outsource it to a provider like Sendgrid, SES, or Mailgun.

Then, there's anti phishing email software which can expire one time tokens as it probes to prevent phishing attacks. More on how we built around that here: https://github.com/FusionAuth/fusionauth-issues/issues/629

> just invalidate them after use

I can't speak for Stytch, but I know at $CURJOB, we have run into issues with this where corporate phishing protection software invalidates one time use codes. I believe it does that because it retrieves links in emails before the user clicks on them. This was an issue several of our customers have raised. So it isn't as straightforward as you might think.

There's more details, including the workaround we ended up using, on the GH issue: https://github.com/FusionAuth/fusionauth-issues/issues/629

PS I agree they should absolutely have guidance around link lifetime as well as safe defaults. Converting the links to one-time use seems like a good start.

Such a great idea! I filed a feature request on our GH issues list to implement this: https://github.com/FusionAuth/fusionauth-issues/issues/1888

Another issue that I don't see covered here is that some email clients (looking at you, Outlook) pre-fetch links to see if they are security risks. If you build a magic link system which handles plain old GETs, the one time code gets used up before the user can actually log in.

We ran into this at FusionAuth and had to do implement some workarounds, documented here: https://github.com/FusionAuth/fusionauth-issues/issues/629#i...

Edit: https://news.ycombinator.com/item?id=32081192 mentions some other issues.

We do, extensively, both internally and externally. In fact, we don't have any other explicit way to order engineering work. (There's always the "inside the CTO's head" priority list, but we strive to get that into GH issues.)

https://github.com/fusionauth/fusionauth-issues/issues is our main external facing repo. We use it:

* to track issues. Every code change should tie back to an issue in this repo.

* to get feedback from the community. People can upvote issues that are important to them.

* to take input from the community. If someone wants a feature added or a bug fixed, we ask them to file an issue. This is a desired bit of friction (if you can't be bothered to file an issue, then you probably don't care that much).

* to expose the near term roadmap to customers and community members (we do this using milestones)

* to expose our decision making and prioritization process. We've had customers say they loved that about our product. The product is not open source, but the development process is as transparent as we can make it (see https://github.com/FusionAuth/fusionauth-issues/issues/1577 for example).

It's great for all those things. On to your concerns:

* bug reporting: yes, but make sure you use templates

* sprint/epic management: okay for that. Not easy to tie bugs together in any structured way (we use a 'related bugs' section of the issue description, but that depends on frail humans to keep it up to date)

* release management (from development, to code review, to QE verification, to release): less familiar with this, I know there is a kanban view that we've used. Milestones are useful here.

* integration with non-engineering teams (ie, letting customer support/customer success tag issues that customers have brought up): as long as they are GH knowledgeable, it'll work.

From my limited jira experience, it's much more powerful when you have teams of teams and need reporting and customization. But for a team our size (<10 engineers), GH issues has been great.

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.

I did something similar, though picked Apache with mod_auth_openidc, which is a certified Relying Party implementation: https://github.com/OpenIDC/mod_auth_openidc

In other words, I can protect arbitrary applications through my reverse proxy and require either certain claims/roles, or simplify auth to the point where my downstream app/API will just receive a bunch of headers like OIDC_CLAIM_sub, OIDC_CLAIM_name, OIDC_CLAIM_email through the internal network, not making me bother with configuring OIDC libraries for all of my APIs and configure them in each stack that I might use, but rather contain all of that complexity in the web server.

Basically:

  user <==> Apache (with mod_auth_openidc) <==> API (with OIDC_ headers, if logged in)

> Don't outsource either your authentication or authorization. Run it in-house.

This is hard to do, though. I hope people here will drop a lot of combinations that work for them!

Personally, for a small/medium scale project, I went with:

Keycloak: https://www.keycloak.org/

It supports various backing RDBMSes (like PostgreSQL, MariaDB/MySQL and others), allows both users that you persist in your own DB, as well as various external sources, like social login across various platforms, is an absolute pain to configure and sometimes acts in stupid ways behind a reverse proxy, but has most of the features that you might ever want, which sadly comes coupled with some complexity and an enterprise feeling.

I quite like that it offers the login/registration views that you need with redirects, as well as user management, storing roles/permissions and other custom attributes. It's on par with what you'd expect and should serve you nicely.

mod_auth_openidc: https://github.com/OpenIDC/mod_auth_openidc

This one's a certified OpenID Connect Relying Party implementation for... Apache2/httpd.

Some might worry about the performance and there are other options out there (like a module for OpenResty, which is built on top of Nginx), but when coupled with mod_md Apache makes for a great reverse proxy/ingress for my personal needs.

The benefit here is that I don't need 10 different implementations for each service/back end language that's used, I can outsource the heavy lifting to mod_auth_openidc (protected paths, needed roles/permissions, redirect URLs, token renewal and other things) and just read a few trusted headers behind the reverse proxy if further checks are needed, which is easy in all technologies.

That said, the configuration there is also hard and annoying to do, as is working with OpenID Connect in general, even though you can kind of understand why that complexity is inherent. Here's a link with some certified implementations, by the way: https://openid.net/developers/certified-openid-connect-imple...

otherwise connections would randomly drop. I was looking for other ways to make development a bit easier and also settled on mod_auth_openidc, which is an Apache module that lets it act like a Relying Party and handle lots of the heavy lifting (protecting endpoints, refreshing tokens etc.) for me, and lets me work with just a few headers that are passed to the protected resources: https://github.com/OpenIDC/mod_auth_openidc

It works, but I'm still not happy - I realize that there are many types of attacks that have historically been a problem and that certain OpenID Connect flows try to protect against, in addition to the fact that if I wrote my own security code it'd almost certainly be worse and have vulnerabilities (in the words of Eoin Woods: "Never invent security technology"), and it's a good thing to follow standards... but the whole thing is such a pain. Both OpenID Connect, Keycloak and configuring mod_auth_openidc.

Right now I'm moving permissions/roles from Keycloak back into the app DB, with references to the Keycloak user IDs, because I don't want to have to work with the Keycloak REST API every time I want to change what a user can or cannot do in the system, in addition to permissions which might only apply conditionally (one user might be related to multiple organizations, having different permissions in the context of each).

Regardless, it's nice that there are more pieces of software out there to choose from!

Personally I went with Keycloak, because it's fairly well documented and also has Docker images available: https://www.keycloak.org/getting-started/getting-started-doc... although the fact that they want you to create an "optimized" image yourself and have a long build/setup process on startup instead is slightly annoying: https://www.keycloak.org/server/containers

Regardless, with something like mod_auth_openidc or another Relying Party implementation, all of the sudden authn/authz becomes easier to manage (you can literally get user information including roles in headers that are passed from your gateway/relying party to apps behind the reverse proxy), regardless of what you have actually running in your APIs: https://github.com/OpenIDC/mod_auth_openidc (there are other options, of course, but I went with that because I already use mod_md).

It's actually cool that there are plentiful options in the space, since OIDC is pretty complex in of itself and attempts at creating something pleasant to actually use are always welcome, I've also heard good things about Authentik: https://goauthentik.io/

> The user experience with basic auth is not so good.

Apache actually also has an OpenID Connect module, which you can enable to have it work as a relying party: https://github.com/zmartzone/mod_auth_openidc

Basically, the actual UI will be handled by another system that you might be using, for example, in my case that might be a self-hosted Keycloak instance: https://www.keycloak.org/

I'd say that Keycloak is a pretty good solution in general, because it does some of the heavy lifting for you, maybe its shorter release cycle not being the best thing ever, though. I think IdentityServer also tried to fill this niche, but they went full on commercial recently, without OSS offerings.

E.g. for Apache httpd there's mod_auth_openidc available.

More information: https://docs.docker.com/network/

> Load balancing

The above will also distribute the traffic based on how many instances you have running, from as many web servers as you have running. Throw in health checks (such as the container running curl against itself, to check that the API/web interface is available when starting up, as well as periodically during operation) so no traffic gets routed before your application can receive them and you're good for the most part: https://docs.docker.com/engine/swarm/services/#publish-ports

> TLS encryption

Let's Encrypt as well as your own custom certificates are supported by most web servers out there rather easily, even Apache now has mod_md for automating this: https://httpd.apache.org/docs/trunk/mod/mod_md.html

Also, if you want, you can encrypt the network traffic between the nodes as well and not worry about having to manage the internal certificates manually either: https://docs.docker.com/engine/swarm/networking/#customize-a...

> Authentication and authorization

Once again, web servers are pretty good at this, you can configure most forms or auth easily and even the aforementioned Apache now has mod_auth_openidc which supports OpenID Connect, so you can even configure it to be a Relying Party and not worry as much about letting your applications themselves manage that (given that if you have 5 different tech stacks running, you'd need 5 bits of separate configuration and libraries for that): https://github.com/zmartzone/mod_auth_openidc

> Metrics aggregation, such as request throughput and response time, Distributed tracing

This might be a little bit more tricky! The old Apache outputs its server status with a handler that you can configure (see a live example here: https://issues.apache.org/server-status ) thanks to mod-status: https://httpd.apache.org/docs/2.4/mod/mod_status.html and there's similar output for the ACME certificate status as well, which you can configure. The logs also contain metrics about the requests, which once again are configurable.

Other web servers might give you more functionality in that regard (or you might shop around for Apache modules), Traefik, Caddy as well as Nginx Proxy Manager might all be good choices both when you're looking to hook up for something external to aggregate the metrics with minimal work, or want a dashboard of some sort, for example: https://doc.traefik.io/traefik/operations/dashboard/

> Rate limiting

In Apache, it's a bit more troublesome (other servers do this better most of the time), depending on which approach you use, but something basic isn't too hard to set up: https://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html

> Routing and traffic management, Traffic splitting, Request retries

I'm grouping these together, because what people expect from this sort of functionality might vary a lot. You can get most of the basic stuff out of most web servers, which will be enough for the majority of the web servers out there.

Something like blue/green deployments, A/B testing or circuit breaking logic is possible with a bit more work, but here I'll concede that for the more advanced setups out there something like Istio and Kiali would be better solutions. Then again, those projects won't be the majority of the ones out there.

> Error handling

Depends on what you want to do here, custom error pages (or handlers), or something in regards to routing or checking for the presence of resources isn't too hard and has been done for years.

But what's my point here? Should everyone abandon using Linkerd or Istio? Not at all! I'm just saying that even with lightweight technologies and for simpler tech stacks, having and ingress as well as something that covers most of what a service mesh would (e.g. the aforementioned Docker overlay networking, or similar solutions) can be immensely useful.

After putting Nginx in front of many of the services for projects at work, path rewriting, as well as handling special rules for certain apps has become way easier, certificate management is a breeze since it can be done with Ansible just against a single type of service, in addition to something like client certs or OIDC (though admittedly, that's mostly on my homelab, with Apache).

Once you actually grow past that, or have your entire business built on Kubernetes, then feel free to adopt whatever solutions you deem necessary! But don't shy away from things like this even when you have <10 applications running in about as many containers (or when you have some horizontal scalability across your nodes).

I really like https://tools.ietf.org/html/draft-ietf-oauth-security-topics with it's evergreen approach and looking forward to oauth2.1 to sum up the current best practices.

Depending on your use case I have good experience with https://github.com/zmartzone/mod_auth_openidc and https://github.com/panva/node-oidc-provider.

https://github.com/OpenIDC/pyoidc also might be a good choice as security researchers in that area did take a look in it...

My prod proxies are apache with https://github.com/zmartzone/mod_auth_openidc for the oidc stuff, for x509 certs, SSLVerifyClient require

I leave that the the module, I believe it uses client cookies by default, but I use a persistent server cache on disk (the session tokens are stored encrypted)

https://github.com/zmartzone/mod_auth_openidc/wiki/Session-m...