brokenwren

An overview of how FusionAuth selected our SOC 2 software vendor for 2023.

I missed that you left Okta back in 2022, so pardon asking for a disclosure. In any case, I think your last sentence was the part that seemed a bit defensive. Dan was pretty clear that his assessment had overlap and things get fuzzy. Of course, YMMV.

Generally, the HN community prefers if you announce the company you are with. It helps ensure transparency in the communications.

I’m the founder of FusionAuth and have deep knowledge on OAuth and SAML. The groupings Dan used seem like a decent assessment with some caveats.

I think that's actually what most people are waiting for with Loom. They want it to be fully baked into the JDK and ready for production first. Then they will start using it.

For java-http, once it has been tested a bit more, we'll likely release a 1.0.0 version, but it's already in production, so it works right now.

In terms of Netty or Jetty, why pull in all the dependencies and overhead if all you need is an HTTP server? java-http solves the 25 year old HTTP server problem we've had in Java.

In the past, you either had to learn Netty or use Jetty/Tomcat/JBoss/Glassfish/WebLogic/etc. In my opinion, these tools are complex, bloated, and legacy. Most other platform have a simple HTTP server (Node, Ruby, etc). Java has lacked this for a long time and we've been forced to use things like Tomcat when we didn't need JEE or WARs or the complexity.

The JDK team plans to add one in version 20 or 21, I think. But they have specifically stated it won't be production quality (ugh). Not sure why they made that decision honestly.

Need a simple HTTP server that only takes a few lines of code to start, is production quality, requires no dependencies, is crazy fast, scales well, and is only 140k? No problem. Just use java-http! :)

I'm not clear why there is a distinction here. Any HTTP server can easily use a non-blocking Selector to handle the I/O operations and then perform the application logic on Threads or Fibers. My point is that Loom fundamentally is a threading model that works well for blocking I/O.

What is unclear is whether or not Loom will increase performance of the server I/O (not the application logic code) that is already working well with non-blocking Selectors. I doubt it. But if someone has a Loom implementation of a plain HTTP server (nothing complex or JEE), I'd be up for some benchmarking exercises.

Overall though, I don't think Loom negates the usefulness of java-http. We built a super simple API, with no dependencies, that works with Java 17 and above, supports TLS natively, and is insanely fast.

Am I missing something?

I don't think this is accurate. The Loom documentation says specifically that it is a concurrency model to replace native threads with fibers. It says very little about non-blocking IO, except that it is a use-case that it assists with:

https://openjdk.org/jeps/425

The NIO section covers a bit about how the fibers release the channels, but the OS will not know that. Non-blocking IO is about interrupts at the hardware level that let the application code know when bytes are ready to be read or written. Fibers help by fanning out the work, but they don't replace this concept.

Sounds good. Once I get the project published, it will include all of the load tests for each server as well as the setup and code for it all. Might be a couple of weeks or so, but it will be a separate GH project. Something like java-http-performance.

Actually, Loom is about threading and helps support NIO. You'll still need Selectors, Channels, and ByteBuffers with Loom, you'll just be able to pass off the parsing and handling to a Fiber. You might be able to get away with doing the IO blocking with Fibers, but it likely won't scale. Non-blocking IO is still way faster at the OS level so my guess is that Loom will simply replace 10-20 lines of code in java-http and the majority of the IO will be the same.

Thanks! Feel free to log any issues you encounter. TLS is complex, but I think I have it working properly now.

I thought so as well. See my comment on the other thread about Netty. I'm sure someone that is a Netty expert or committer could figure it out, but it's so complex that it makes it nearly untenable.

I ran the load tests and couldn't explain it either. I adjusted the thread pools, buffer sizes and a bunch of other parameters and couldn't get Netty to scale.

I think Netty tries too hard to be everything to everyone. This makes it really hard to determine how to configure it properly across a bunch of different versions with lots of incompatibilities.

I wrote java-http with the concept of not doing that. It's purpose built for HTTP and high performance.

Once I have some time, I'll publish my Netty setup and let the community bang on it and see if they can beat my RPS. At 65k, it might be hard though. :)

I wrote most of the server code for the project and I actually looked extensively at Loom.

We decided to anchor the project to LTS Java versions only. The issue with Loom is that as a preview release, you can't use it without introducing compiled code that is hard to deploy on new LTS versions. We ran into this with Java 14 and used a bunch of the preview features in that release. When we upgraded to Java 17, it caused a number of issues and we had to rebuild almost everything.

Once the next LTS has been released and Loom is top-level, we'll definitely look at using it as long as the Java community is willing to make the jump with us.

In the meantime, I think our threading implementation works quite nicely and scales really well. Let me know what you think if you review the code.

As this applies to access tokens, if your application doesn't need a JWT, it shouldn't care whether the authorization server returns a JWT or an opaque token. On the flip side, if your app needs a JWT, then the authorization server must return one.

Revocation is either offered by the authorization server or managed by the app. If the authorization server manages it, then JWTs vs. opaque tokens are not a concern because the authorization server issues and revokes its own tokens. If the app manages it, then generally it does so based on the token type. If the app revokes based on opaque tokens, it can handle any type of token, including JWTs. If it revokes based on JWTs, then JWTs are required.

Beyond that, the only differences between the two token types are size and data leaks. Size rarely matters (hehe), so just ignore that. Data leaks are only an issue if you app is leaking JWTs, which is usually considered a critical vulnerability. Remember that access tokens are the main units of identity and if I steal an access token, I effectively become that user/client.

I agree with you, but it should be WAY faster than every 90 days. I'm trying to find articles that address the fact that NIST and others are worthless since they recommend every 1-2 years.

So, do you know of anyone that has written this type of thing up? I'd love to have some fodder when having these types of discussions. :)

I completely agree. But even at 15 or 30 days, it's too long. The only way to protect a key would be to rotate it every day or every hour.

We tried to convince Twitch for years that their filters were garbage and they should use CleanSpeak. They kept insisting their engineering team had written the best filter in the world.

Sometimes it’s just not worth the effort to try and help people solve these problems.

FusionAuth also has advanced registration forms and we are working on a lot of really awesome improvements around sign-in and sign-up workflows.

Stay tuned for some major updates in the coming weeks! ;)

We are working on that. Our new website will include a ton of information about the company, our executive team, and our culture. Stay tuned!

You can check out my LI profile for now though ;)

https://www.linkedin.com/in/voidmain/

You can export everything via a support ticket. We have migration scripts you can use if you come over to FusionAuth or tweak them for any other platforms as well:

https://github.com/FusionAuth/fusionauth-import-scripts

Except for all the basics like RBAC with multiple roles, JWT modification, simple MFA, etc.

Come on over to the FusionAuth! The water is great! - https://fusionauth.io

It has all of the same features as the Cloud version, including unlimited Enterprise Connections (SAML and OIDC) for free.

The only features that required a paid-Edition are: Connectors (connecting to LDAP and other backends), Advanced Registration Forms, and Breached Password Detection.

We are adding additional paid features as well, but our Developer Edition is reasonably priced. $125/month to start and that gets you up to 10,000 MAU. You can also test drive Developer Edition free for 14-days.

Exactly. And most businesses "outsource" their database. They might use PostgreSQL for free or they might pay Microsoft for SQL Server. In my opinion, this is analogous to auth.

Are you on their startup plan that allows you unlimited "Enterprise Connections"?

I'd be very careful with how their pricing impacts your business as you increase your B2B clients with Enterprise Connections.

I'm honestly not trying to pitch you on anything, but when you outsource your auth* to a provider, you must consider the long term costs based on your business model and theirs.

(I should disclose upfront that I'm the founder of FusionAuth)

The core of FusionAuth isn't open source, but a good portion of the code built around the core is open source. It is free and has a large, growing community and integrates with any language.

Plus, you get the benefit of a having a company behind it that is constantly improving and updating the product.

I'd be happy to talk more about our licensing model and why we chose it if anyone is interested.

Then you should also group the database in your core competencies and would likely need to consider building this yourself. Or the OS. Or the web framework. Or the wire protocols.

Sure, this is hyperbolic, but it does illustrate that not everything is a "core competency". There are always tradeoffs and decisions when it comes to software.

In my opinion, authentication and authorization are likely not core competencies for 99% of businesses. They are simply capabilities that just need to work and the business doesn't need to own them. This is the same with the database. Using a tool like FusionAuth, Keycloak, or SuperTokens will cover all of their needs.

It's always great to see new companies trying to improve on this problem. I'm the CEO of FusionAuth and we've been working on our product for 6 years now. I can attest to the complexity and challenges that exist in this industry. Our belief is that no one should be building auth anymore.

You should connect with Mike over at Gluu. He's a great guy and very supportive of the industry as a whole. I'm also happy to connect with you all as well.

Steer clear of Auth0, OneLogin and the others. They don't play fair and I'm positive you'll be receiving your first cease and desist letters in the coming weeks. We have stacks of them and their claims are always total BS. But you don't want to go to battle with a company that has $300M in the bank.

Congrats on the launch!