PSA: Don't outsource either your authentication or authorization. Run it in-house. Don't give away the keys to the kingdom to a third-party to fail like Okta or lose the ability to police access that becomes incredibly difficult to audit and classify. There is no panacea work or headaches alleviation by relying on SaaS when the business risks are too great.
Building authentication in-house is non-trivial to say the least. It is a dynamic service that fundamentally needs a database and is fundamentally accessible both to the wider public Internet (networking-wise) and to unauthenticated users (which attackers always start out as), which makes it incredibly difficult to secure. DoS, keeping everything patched on a moment's notice, rate limiting clients, emailing resets, ensuring your emails continue to be deliverable, suspending accounts hit by credential stuffing, having support processes for unsuspending accounts that are not themselves susceptible to social engineering... the sheer complexity of security engineering required to do this correctly and at scale is not even remotely trivial. Not to mention very strict performance/latency requirements because auth is overhead on everything, which gets to be difficult once services start to scale globally, and runs into direct internal contradictions when revocations compete against internal caching.
I appreciate the business risk of depending on a third-party for part of the foundation of your value offering, but the truth is, if you're not running your own datacenter and hosting your own databases (and therefore your databases are located in some vendor's offering, be it co-lo or cloud), you're dependent on a vendor for part of the foundation of your value offering. In and of itself, that's a pretty normal, expected, and acceptable business risk to take.
Not all businesses are the same, and I'm sure there are some where you need to run auth in-house (like if you're selling on-prem software), but I'm mindful that most companies simply cannot run auth securely. And when their security fails, their users' data leaks, and in a modern era, that too is a real business risk.
I'm sorry, I'm not against using 3rd party services, but such a strong statement about so relatively not complex functionality I've heard 1000s of times in my 24 years career and these never stood itself for long.
Every then and now I hear some IT "priests" screaming don't do this, do that and people follow it. But I see it always leads to something being "cheap, easy and fast", being actually expensive (at scale), difficult (to adjust to specific needs, holding back the business) and slow (because of all work-arounds) :-D
Companies literally burn a ton of money in long run because their CTO can't get them proper evaluation of what is really needed for their expected scale. And even large business with billion of dollars revenue may not need really an infrastructure of google scale.
I just use MTLS, MDM software like intune deploys the certificates.
Elsewhere in the org we have openAM which ties into AD and provides an OIDC/SAML integration.
Your blanket “don’t do authentication” statement is filled with so many specific circumstances and caveats which don’t apply to many difference cases it just sounds uninformed and thus arrogant.
GP did agree that there are some cases where this doesn't apply:
> Not all businesses are the same, and I'm sure there are some where you need to run auth in-house (like if you're selling on-prem software), but I'm mindful that most companies simply cannot run auth securely.
I couldn't disagree more strongly; you will screw this up if you roll your own. The only secure option is to push as much as possible outside of your infrastructure. The concerns that it won't be "auditable" or that you "give away the keys to your kingdom" are nonsense and implementation-specific. If it's important, then don't build your integration with those flaws. You will still have substantial control, so you can decide how "auditable" the auth actually is and what to do with users authed from one platform or another.
If you can avoid managing authn, you will be substantially better off. I don't think you can so easily do this for authz; however, it depends on what you're building.
> you will screw this up if you roll your own. The only secure option is to push as much as possible outside of your infrastructure.
In my experience the integration with outside infra (OAuth, OIDC etc.) carries significant complications in itself, and Im not convinced that you really gain that much in terms of reducing complexity or attack surface by using these technologies. See this article that was on the front page yesterday for an example of non-obvious things that can go wrong https://trufflesecurity.com/blog/google-oauth-is-broken-sort...
> Im not convinced you really gain that much in terms of reducing complexity or attack surface by using these technologies.
In the case you mention (which I posted), integration of some kind offers functionality that would be otherwise impossible to get--single sign-on which lowers friction of user acquisition. SAML is one alternative method, but from my experience it has some sharp edges too.
Of course, whenever you're integrating a third party solution, you need to do so carefully.
Our current production deploys for our B2B/SaaS banking product run "in-house" authentication.
We were essentially laughed out of the room when we showed our biggest prospect how we managed users in our legacy product. I felt really smug about my fancy hand-coded user management tooling until about 50% into the presentation when I could see an equivalently-smug look + mild sideways head shaking coming from the customer CTO. Running in-house authentication is literally a joke to many of these orgs in 2023. Most developers probably won't ever experience this. I think it is a shame, because this one experience forced us to embrace a new kind of light that much of HN probably won't ever see. Our roadmap was accelerated by this rejection.
Realizing that we might have lost a multi-million dollar customer over an ego trip was a bit of a wakeup call. I have some skin in this game. I don't know about the rest of HN. At a certain point, it's about making money and being able to sleep at night. Running in-house anything typically works against that (i.e. spending finite innovation tokens). Like it or not, if you are dealing with a big crusty organization, outsourcing authentication might become mandatory at a certain point.
Further, if something goes wrong and one of our customers gets breached, I don't want the investigation to wind up at a line of code in my codebase. That means I have to get involved in legal proceedings. I am completely out of the game of touching end-user passwords or MFA tokens now. We get claims from an IdP and that's that. We don't even write SAML/OIDC integration code because our tech partner has done that for us by way of a happy DDL election on our FaaS runner config. The authenticated user's claims are injected into our HTTP trigger function arg list, and since we do stupid-simple PHP-style SSR web apps, the rest is fairly obvious. We still have a "Users" table, but all that password hashing/salting/iterations crap is replaced by a simple UPN string field (i.e. the user's email address).
Above all this, use case matters most. If you are unregulated and dealing B2C with 100m customers, you'd have to be the maddest hatter to ever live to consider paying someone else for authentication duty like we decided to do. If you are working B2B with US banks and other regulated orgs, the exact opposite appears to be true.
1000x this - each and every CAIM has their own "interpretation" of what the various constructs actually mean in the various RFCs and it leads to a lot of hodge-podge integrations that organizations outgrow. Things like Okta and Auth0 might seem shiny and easy on the face of it, and they are for very small startups, but quickly devolve into dogshit as you scale.
Ah, someone else here has probably encountered CIAM pain too. ;@]
For internal use, FreeIPA is neat (389ds + dogtag). Some people use AD or Azure AD (which again, is outsourcing). Shibboleth provides a FOSS SSO solution. https://www.shibboleth.net/products/
For k8s IdP, there are numerous FOSS, on-prem solutions like pinniped.
I wonder why this got downvoted. I looked over the alternatives a while back, and I thought Ory looked the best too, with Keycloak as a good number 2.
I agree with the OP that it's good to not be dependent on SaaS for something as central as user management.
I do agree with the others that it's best to write as little as possible of security critical code yourself. However, integrating with a third party OAuth thing can be hard (and leave plenty of room for security fuckups) especially if you have anything implemented at all already user-wise.
There are plenty of solutions you can run in-house like Keycloak or PingFederate. Not using Okta or Azure AD doesn't meant hand-crafting your own tooling.
> Don't outsource either your authentication or authorization
This is why a solution like FusionAuth (my employer) or Keycloak is a good option. You can self-host the authentication server.
If you do that, you outsource the development of the auth solution, but keep the data and the operation of it firmly in your control, lowering the business risks.
As other comments mention, there's a lot that goes into building and maintaining auth, and it's rarely a differentiator for your application.
Running your own system also, frankly, lowers the target value of your system. Okta and other centralized auth solutions are of greater value than the users of only one system. Of course, they can also hire specialized security experts on a scale you might not be able to, so you have to balance those risks too.
I agree, with the implicit "build it in-house with OIDC certified 3rd party dependencies ". The foundation already goes a long way towards providing conformance suites and several certificates. I don't understand how we came into this status quo of "I'm just gonna outsource users data, XP and all to this company I have little transparency over, and its gonna be fine because I don't waste time maintaining infrastructure for auth which is my core business, much better to maintain the several sync points, settings pages they won't possibly do, and waste man hours inquiring about why this user password changed when they are telling us it didn't, and I can't tell them to ask Auth0?"
They're desperate to get off keycloak at my org. Not sure the specifics, but our users complain about Auth issues often, and the keycloak web interface is painfully slow too.
I’ve read you need to partition usage to limit each keycloak instance to about 1500 total users to avoid performance issues. Does this hold true in your org?
I work with an org that has 10's of thousands of users on keycloak, so there must be a way around the problem. I'm not administering the instance for this project, so I have no direct insight into how they deal with it.
It looks like it's 'entities' and not just 'users'. From the docs [0]:
Keycloak allows you to create any number of realms and any number of clients and users in them. But you need to be thoughtful as you scale up because as the number of entities grows, Keycloak slows down. When you log in as a superuser in the admin panel, even if you have only 1,500 realms, it will take a few minutes or even crash on timeout. Creating a new realm will take about 20 to 30 seconds. You need to change your logic and interaction with Keycloak.
I have to disagree with your assessment. It's not that rock solid, "supports everything" is a very vague term and "trusted everywhere" I'm not even sure that that is supposed to mean.
I work for FusionAuth which has a free community edition[0], so I'm a bit biased. You can read some of our community stories talking about what folks have built on top of it[1].
Other alternatives I've heard mentioned for self-hosting include:
* Ory
* Platform specific OSS (Devise for Rails, Passport/NextAuth for javascript, Spring Security for Java, etc)
* IdentityServer (may have to pay something now, not sure)
FreeIPA is pretty good for internal users when money is tight. It's a FOSS almost AD but for *NIX and it does HA. For the SSO part, Shibboleth2 or CAS.
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.
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 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...
Please don't write your security code from scratch and lean in the direction of just gluing various tested options together.
Heya, you might want to check out FusionAuth community edition (my employer). It's very comparable to Keycloak and definitely simpler to set up and run. It's free for unlimited users.
This advice is wrong on some many levels. Building your own OIDC/OAuth/SAML infrastructure is incredibly expensive, error prone and dangerous; and not mention you need people to code it, run it securely, audit it, test it.
Even running something like a self-hosted Keycloak instance/cluster is not easy either and comes with its own set of problems.
Have you actually rolled out such a solution yourself? Yes, the contractual obligations of the protocol are deceptively shallow, but that is the easiest part. We’re not just talking about assembling a JWT and asserting it. We’ve got to hook up all the plumbing for signing, key management, credential management, various auth flows (after all, not all apps are created equality), RBAC, SSO, federation, custom rules, and all the accoutrement in between. Yeah, great, you can hack in a solution for your simple app, and if your use case lets you get away with it then go with god. A fully compliant system, batteries included, is a staggering amount of work.
