Hacker News Reader

This is the first time I've heard of the "don't roll your own auth" crowd. You don't roll your own crypto (unless you're damn good at crypto, and most people aren't) but a simple username+bcrypt/argon2 solution works just fine for most applications.

You'll likely need to integrate with stuff like OIDC if you're planning to sell your software to enterprises with their own existing authentication mechanism (which isn't all that hard if you pick the right software stack as Apache and Nginx can do that layer for you!) but in other cases I don't see the need for it.

It's important to know your stuff when you're designing a security barrier, though. Good auth can be hard if your development framework doesn't already take care of edge cases. Things like JWT and refresh tokens can be a pain to get right and MFA can be even worse. Grabbing someone else's auth solution can sure be the quickest, easiest option, but there's no real need for all of that if your system doesn't need all that much complexity.

Personally, I would go with Keycloak or a similar product, but not integrate directly. With both Apache and Nginx you can let the web server do all the OpenID Connect work for you for paths you specify. All you need to do is take the header your reverse proxy hands you (make sure this can't be spoofed) and take that as your account ID. You'll have all the fancy enterprise features like MFA and LDAP integration at the ready if your customers demand it, but more importantly you don't need to bother with implementing refresh tokens, WebAuthn, TOTP generation, or password resets.

More importantly, this stuff can be hosted on your own hardware without any cloud subscriptions. You can outsource auth to an external provider later if you run into scaling issues, but you probably don't have to because servers are fast these days.

I think your 2nd/3rd lend favour towards "don't roll your own auth" - it's hard and more often than not there will be buggy implementations. People aren't good at crypto and they aren't good at authentication workflows either, when an application starts to scale it becomes a liability.

That crowd tends to say don't roll your own anything until they get replaced by bots or "AI".

Building auth is hard, but so is properly integrating with external auth providers. You'll be surprised how many applications you'll find online that accept unsigned JWT tokens because many people don't know they need to turn those off. You also need to cater to the specifics of your auth solution (i.e. how to prevent spoofing, how it deals with brute force attempts, how to set up the proper session lengths). You end up learning about things like "OAuth 2 scopes" and other fun terminology that will have you become an expert in the specific auth solution you've chosen before you can reliably roll it out.

I'd guess that for most platforms that work with a simple username and password, rolling your own auth is probably a lot cheaper and easier. With 2FA this becomes trickier to pull off, but depending on your platform you may be able to build it in the same time it takes to properly configure, style, test, and document an external auth setup.

> With both Apache and Nginx you can let the web server do all the OpenID Connect work for you for paths you specify.

Seems like at least the official nginx solution for this requires their paid subscription: https://github.com/nginxinc/nginx-openid-connect

Got any tips for how to do it with their open-source solution?

There's an nginx Lua build that can do it on nginx through a Lua module: https://github.com/zmartzone/lua-resty-openidc

Apache is a lot easier to configure, though.

Gotcha, I tend to think of openresty as more of an nginx-based-application-platform than just as nginx.

Disclosure: I work at FusionAuth.

Heya, it depends!

I think if you have one app and don't plan to have any others, it can make sense to use an open source library like Devise/Omniauth (Rails) or Spring Security (Spring/Java). Passport.js is pretty good for javascript. You can also use some of the simpler SaaS options like Supertokens or Clerk.

If you plan to have more than one app, especially if you want commercial off the shelf software to hang off it, then you should start looking at auth servers (Keycloak and FusionAuth are both such servers, as are others mentioned in sibling threads).

Then the choice becomes SaaS or self hosted. If you are looking for ease of use, SaaS is where it's at. Most every auth server has a hosted version; Auth0 is the most popular one but I believe the free tier is 7k users and MFA options are limited. FusionAuth doesn't have a free SaaS option, but if you stand it up in EC2 or some other provider, we offer TOTP MFA, unlimited SAML, OIDC and social connections, and unlimited users and clients (we call them Applications). But of course you run it yourself, which is not free.

Anyway, lots of options out there. Based on the little I've seen here, I'd probably recommend an auth server (because you have many apps). Self-hosted or SaaS probably depends on your appetite for running an auth server; I don't have context to recommend one way or another.

Hey really appreciate this advice! It's quite refreshing to here someone who works at an Auth provider not understating the usability of some of these libraries and frameworks.

FusionAuth seems really great too, in my journey down this path I've come across quite a few people using your hosted service on very large apps who have nothing but praise, so kudos!

One question I have is, when you say multiple apps, are you speaking in a sense of they are at all related? Or every small app/project you have related or not?

> One question I have is, when you say multiple apps, are you speaking in a sense of they are at all related? Or every small app/project you have related or not?

If you think that people will want to subscribe to more than one app, or if you think you'll want to be able to have a single view of customers/users across multiple apps, that's when I'd extract auth to an auth server. You can use a dedicated auth server or have other apps rely on one app which uses a library/framework.

Think of it as normalizing user profile info. Just like when you normalize data, you get wins (one place to change things, consistent data structure) and you lose things (more complex, have to do joins across tables [or in the auth case, use tokens]).

If you don't ever forsee the need to look across all your users, or for users to log into multiple apps, and you don't need some of the isolation and features an auth server can offer, then it makes sense to continue to silo each set of user data in each app.

You can always make the investment to migrate to an auth server later. Of course, the longer you wait, the more hairy it will be.

Hope that helps, and thanks for the shout out to FusionAuth. If you want to download the free Community version to kick the tires for your own needs, here's the link: https://fusionauth.io/download

The big auth companies have been really good at creating those "Don't roll your own auth EVER!!!" articles.

You're not alone. I take it a step further and don't deal with passwords. I use login through email, in which I send a nonce to the user's email. The users enter that nonce to log in. This is what many online bank apps do. That reduces the security surface area to CSRF, securing cookies and session expiry. Most popular frameworks should handle that part of it.

I like this solution and use it on a system where MFA is not an option, and people log into it very infrequently.

Initially people told me to use a login link or 'magic link'. However it quickly became clear that they also wanted to receive the code on a different device to the one they logged in with.

> That reduces the security surface area to CSRF, securing cookies and session expiry

How do you keep the user logged in? Do you just keep a token in-memory on your frontend app?

I've gotten by with bcrypt + self generated tokens so many times it's not even funny anymore. Don't listen to these bigots. You don't always need 800 layers of Oauth etc

It's SO FRUSTRATING that these services put MFA behind hundreds of dollars worth of subscriptions. For example, Auth0 goes from $23/month for the "essentials" then jumps to $240/month if you want any sort of MFA.

TOTP codes / authenticator apps should be the least overhead so I'm not sure why they don't offer that at the lower tiers.

I'm curious whose telling you not to roll your own auth. I've worked on far more software that handles its own auth than integrates with Okta/Keycloak/Whatever.

In fact the general advice I've heard is "just use bcrypt"

Oh really? I mean I'm almost to relived to hear this because the "never roll your own auth" crowd is honestly deafening.

You ask any question on a lot of sites and communities (twitter, reddit, stack overflow) just about anything to do with auth and you'll get slammed with comments preaching about this.

I think Hacker News is somewhat an outlier in this I will say, as in previous threads this doesn't seem to be anywhere near as common.

They always have the same "you think you know better than the 1000s of auth and security experts working on Auth0 or xyz". Which, no obviously not. But there's clearly defined standards such as bcrypt and how to handle sessions etc; and even the OWASP cheatsheets too.

I feel I could implement an auth service wrong too with calling their API if I really tried.

Keep in mind that this site is filled with snake oil salesmen that will try to push anything to you. (Among many honest commenters, obviously.) I've never used third-party authentication and do not plan to. Web frameworks usually handle most of that stuff anyway.

As mentioned in multiple comments, https://zitadel.cloud/ It's free for 25k requests / mo, then you either earn enough to pay, or self-host :)

Appreciate the call out, will definitely check this out. I haven't seen them mentioned much before..

Very interesting to have a per request model, instead of MAUs. I think I prefer that too.

Have a look at Jackson from https://boxyhq.com . Spin up one container and a couple of simple endpoints - voila, up and running. And a really cool team too!