[HN Gopher] Why outsource your auth system?
___________________________________________________________________
Why outsource your auth system?
Author : mooreds
Score : 45 points
Date : 2021-01-20 16:29 UTC (6 hours ago)
(HTM) web link (fusionauth.io)
(TXT) w3m dump (fusionauth.io)
| pmontra wrote:
| The sweet spot is using some well known library. A classic in the
| Rails world is Devise. There is usually one for any language or
| framework.
| _0o6v wrote:
| A sweet spot only is as much as the code is already written,
| but there's a huge amount of ops and security work that goes
| into rolling your own auth.
|
| For 99.9% of businesses, don't roll your own auth. Just don't
| do it. Use an auth service.
| robotdan wrote:
| Yes, this is an excellent choice as long as all of yours apps
| live in the Ruby world.
| pmontra wrote:
| Actually I built a single sign on system for a Rails app and
| a WordPress site many years ago, based on Devise and probably
| (can't remember) some PHP code on WP. Probably also a
| Rails+phpBB SSO. They were meant to be short lived services
| and luckily they did. The reason is that in a mixed language
| / framework environment it's better to have some centralized
| authentication and authorization service and a standard API
| to access it. Having to write and maintain N adapters is
| going to take a toll on the development team. However I never
| self hosted a service like that so I don't want to give any
| suggestions about what to use.
| hashmymustache wrote:
| Is there a good one that integrates with Express?
| victorbojica wrote:
| Passport. It provides a lot of authentication schemes
| bradyd wrote:
| Passport is an Express middleware for authentication. It
| supports pluggable "strategies" for supporting different
| types of authentication, from basic username/password to
| OAuth and many others.
|
| https://www.npmjs.com/package/passport
| _0o6v wrote:
| For 99.9% of businesses, don't roll your own auth. Just don't do
| it. Use an auth service.
| dgb23 wrote:
| I think you are assuming a certain _type_ of business? Most web
| applications have moderate requirements... 1 code repository, 1
| server, 1 database, dozens or maybe hundreds of users.
|
| This service is dealing with stuff like OAuth, SAML, two
| factor, logging, monitoring, scaling and apparently even does
| authorization (from skimming) and more.
|
| In other words, tons of stuff that many businesses don't need
| or want.
| _0o6v wrote:
| There are certain fundamental security requirements that
| don't change, regardless of whether you have 10 users or 10m.
| If you have a breach, you have a breach. Numbers of repos,
| databases, servers have very little (nothing) to do with the
| security requirements of storing personal data.
| dgb23 wrote:
| Yes and no. Complexity, source code volume, data volume and
| amount of users naturally introduce failure states that are
| not found in a simpler system. They also reduce your
| facility for reasoning about the whole, and the amount and
| type of assumptions you are allowed to make.
|
| Google, an indie game, a SaaS, or a custom web app shop all
| have different security engineering requirements, including
| authentication, often per project.
|
| Also outsourcing auth and not having full control over it
| is not feasible or even allowed for some domains or
| projects for a multitude of reasons. Not to mention that
| using an external service has at least a constant
| complexity cost.
|
| That said, these kind of services are definitely worth
| considering for many. There is something to be said about
| advantages of specialization and cost-benefit as well.
| Reliability is not optional for an auth system, and I'm
| sure these engineers are really good at what they do.
| However the challenge would rather be convincing business,
| not engineering.
| dgellow wrote:
| If there is something I would not delegate it's my
| authorization/authentication flow. That's just too much of a
| risk to depend from an external service for such a critical
| part of my systems.
| _0o6v wrote:
| This is an attitude that makes absolutely no sense to me. Ask
| yourself - can I afford to get this wrong?
|
| The risk of your home-rolled auth, with all the edge cases
| and requirements that go with it, vs. outsourcing to a
| company who's entire reputation relies on doing it properly
| with an army of experts, running on enterprise-grade
| architecture, with round the clock support/updates/ops?
|
| Are you seriously saying that you can roll your own auth
| better than Auth0, Fusion etc. can do? And that the hours
| startups spend on setting it all up vs. an afternoon wiring
| in an auth-as-a-service provider is time well spent?
|
| If you're a small company, don't risk it, don't invest time
| in it, just buy it it and plug it in and know that it's all
| enterprise-grade under the hood and you're covered (far more
| than you could ever afford to be).
|
| If you're a big company, and you've done the maths and figure
| that the risk/effort vs. expense is worth it, fine.
| dgellow wrote:
| I don't need all the features Auth0 offers. And I can for
| sure implement an auth system, that's a well known and
| solved problem since a while.
| jsnell wrote:
| > I have never seen a major auth provider compromised
|
| Linkedin, https://en.wikipedia.org/wiki/2012_LinkedIn_hack
|
| Yahoo, https://en.wikipedia.org/wiki/Yahoo!_data_breaches
|
| Or if we don't limit it to just data breaches but include
| compromises that would have allowed a full account takeover of
| any account using this identity provider in a third party app:
|
| Apple, https://bhavukjain.com/blog/2020/05/30/zeroday-signin-
| with-a...
| gowld wrote:
| Also it's strange for a minor auth provider to promote "major
| auth provider". Seems that would drive away potential
| customers.
| CountVonGuetzli wrote:
| TL;DR: We use Keycloak with millions of users and it works fine.
| You don't have to shell out for outsourced auth if you would
| consider a self-hosted solution. You also don't need a team to
| run it.
|
| I work for a large organization that incorporates multiple other
| businesses with millions of users under their own domains. After
| using Auth0 and other SaaS auth providers, we've settled on using
| Keycloak and are happy with it. Cost, security (you own all data)
| and extensibility were the driving factors.
|
| + If you have Java developers, you can extend its features via
| SPIs. Worked great for some custom authentication and migration
| flows we had to build for legacy systems.
|
| + It comes with batteries included: Install it, hook it up and
| for most cases you are done.
|
| + Redhat seems quite invested in it, so it has corporate backing.
| This could also be a bad thing, depending on your view of Redhat
| and which direction they take the product.
|
| - It is a big pile of java. Since it works so well, even in
| cluster mode and containerized, we've never had to dig into its
| internals. But it is still a big pile of java. They are working
| on a rewrite with Keycloak X, but that is still in development.
| mooreds wrote:
| >It is a big pile of java
|
| It looks like Keycloak.X is going to be a slightly smaller pile
| of java :)
|
| https://www.keycloak.org/2019/10/keycloak-x.html
|
| You say you haven't had to dig into the internals at all, but
| has having a "big pile of java" even containerized, affected
| your operations significantly?
| striking wrote:
| I've run it inside a container and not experienced tremendous
| issues with RAM or CPU usage, but this is for very few auth
| calls per day.
|
| Also, I needed to apply some not-obvious environment / config
| changes to make it work behind HTTPS and inside a container
| without /dev/random being remounted.
| mooreds wrote:
| Awesome, thanks for the on the ground feedback.
| CountVonGuetzli wrote:
| Yeah, no issues here either in containers. We did have to
| make some custom tooling at the time to get all
| configuration files under source control though
| CountVonGuetzli wrote:
| Not really. But we also haven't had any issues that required
| taking a closer look. We're used to hosting JVM stuff since
| our devs produce a lot of scala code.
|
| I'm looking forward to them switching to Quarkus, which will
| make it more ameneable to be run in containers.
| robotdan wrote:
| > + Redhat seems quite invested in it, so it has corporate
| backing. This could also be a bad thing, depending on your view
| of Redhat and which direction they take the product.
|
| Yes, true. :-) We'll see if IBM feels the same way.
|
| https://www.servethehome.com/red-hat-goes-full-ibm-and-says-...
| http://techrights.org/2020/08/02/red-hat-layoffs/
| [deleted]
| grinich wrote:
| Have you had any issues with reliability or downtime in running
| it yourself? Or any use cases it hasn't supported? Interesting
| to hear you're running it with so many users!
| CountVonGuetzli wrote:
| No issues with reliability.
|
| We did some load testing and noticed that the first thing to
| become a bottleneck was the database, after running 4k
| concurrent logins or so. I suspect we'd have to introduce
| propper postgres connection pooling to overcome that (we were
| running a single postgres instance).
|
| You do need to watch out for the way it caches things though
| . I suggest to read the relevant documentation, as it works a
| bit differently in cluster mode https://www.keycloak.org/docs
| /latest/server_installation/#_o...
|
| One thing to keep in mind as well is that if you create an
| SPI extension to cover a spicific usecase, you'll have to add
| your own metrics collection. It was a bit of overhead to
| configure in prometheus, since you'll end up having a metrics
| endpoint to scrape for each SPI.
| konha wrote:
| Thanks for your insight!
|
| Do you happen to have experience with a large number of realms
| in Keycloak? I was looking at it a while ago and found
| conflicting opinions on how suitable realms would be to model
| multi tenancy in a saas. Mainly for performance reasons I
| think.
| CountVonGuetzli wrote:
| Hmm no, sorry. We only ever had a small number of realms. I
| would be cautious and test it with the number of realms you
| intend to use it with. We used locust (https://locust.io/)
| successfully to do loadtesting on a few of keycloaks auth
| flows.
| tremon wrote:
| Which "auth" would that be? I get the feeling the article means
| authentication only, but halfway through it says "When your [..]
| authorization systems are down". Outsourcing your authentication
| isn't that much of a problem, especially in the context of
| decentralization of services. But authorization is rather tightly
| coupled to your service, and outsourcing that part would be much
| more of a challenge -- keeping authorization rules up-to-date
| with external systems is a difficult dependency management
| problem.
|
| But regardless of which "auth" was meant, I feel this part is
| dangerous:
|
| _Auth may be unrelated to your core competency_
|
| No, please no. Both authentication and authorization must be
| considered a core competency for every online service, even if
| you decide to partly outsource it. You can't afford to have blind
| spots there.
| brokenwren wrote:
| 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.
| dsr_ wrote:
| For most businesses, the database is a required part of the
| functioning of the business. That means:
|
| - the database must be secured against unauthorized or
| improper use
|
| - the database must be accessed efficiently
|
| - the database must have some degree of resilience
|
| - the database must be recoverable
|
| - the database must be available
|
| Each business will have different weightings for these
| properties -- does a dating website care more about database
| security than a bank does? -- which will lead to different
| decisions about who should own and manage the DB.
|
| But a business is, absolutely, a group of people who are
| doing things together. If you can't identify, authenticate,
| and authorize those people, you don't have a business. And if
| the database that stores that information isn't among your
| highest priorities, I think that business is rather
| misguided.
| brokenwren wrote:
| 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.
| robotdan wrote:
| I think @tremon is just getting at that auth must be
| considered critical, and thus you should maintain some level
| of skill and competency to ensure you don't get blindsided.
|
| Perhaps the distinction is just because something isn't a
| "core competency" does not mean it is not critical. And just
| because it isn't a "core competency" doesn't mean you can
| afford to be ignorant on the topic.
| JamesSwift wrote:
| That seems silly though. It is for this very reason you
| "dont roll your own crypto". _Because_ its critical, and
| _because_ others can handle it better when thats what they
| are focused on.
| gowld wrote:
| It's critically important that my office doesn't burn down, but
| that's not my business's core competence.
| robotdan wrote:
| Nailed it.
| ramraj07 wrote:
| What, you want every company to continue storing passwords
| themselves in crappy ways and reinventing the same wheels?
| JamesSwift wrote:
| I absolutely hate hand-rolling auth for every new SAAS system. I
| advocate e.g. Auth0 everytime, because no one gives a shit about
| logging in. It is such an inconsequential part of the product
| offering, yet it consumes _so much_ time and energy because of
| the (justified) importance of "doing it right".
|
| I understand the SAAS offerings are relatively expensive, but its
| just such an engineering sink. Especially once you start getting
| into SSO, MFA, and the like. So yes, I'm 100% in favor of
| outsourcing it.
|
| EDIT: Authorization is different. Absolutely keep that in your
| database if you can.
| softwarefounder wrote:
| As a startup with 2 engineers, yes, we use Auth0 and love that it
| handles everything for us at the moment.
|
| Especially since we have to handle b2b clients who have their own
| SSO, etc.
| afandian wrote:
| Do you have an exit plan?
| ramraj07 wrote:
| We use auth0 at work and I've thought about it. With time
| given most users are SSO based, it's probably doable but
| annoyingly so over a month to move to another service. Not
| that we would want to.
|
| Outsourcing auth is acceptable for saas customers. For
| consumer apps it's probably not a good idea, pricing models
| typically don't seem aligned in your favor for that.
| NDizzle wrote:
| Gotta have a good exit plan. I originally used Mozilla's
| authentication system, which I can't remember the name of,
| but they got rid of it.
| warp wrote:
| Mozilla Persona, for anyone curious:
| https://en.wikipedia.org/wiki/Mozilla_Persona
| afandian wrote:
| I LOVED that. Persona was a profoundly disappointing
| product cancellation.
| brokenwren wrote:
| 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.
| robotdan wrote:
| I don't know that I'd even refer to this at outsourcing. If you
| can run it on premise, it is just "not building it yourself".
| lucideer wrote:
| I don't see anything in this article that's specific to auth. Why
| not entitle the blog post "Why outsource?".
|
| The points made in the article seem equally applicable to any
| piece of a software service. It effectively boils down to this
| first line of the _Maintainability_ section:
|
| > _There are trade-offs here_
| mooreds wrote:
| Well, for one because it was posted on an outsourced auth
| provider's website :) . (Full disclosure: they are my
| employer.)
|
| Seriously, though, while the headlines (cost, maintainability,
| etc) are applicable to any non-core software functionality, the
| arguments below the headlines are focused on authN/authZ.
| Security, standards compliance, auth breach consequences: these
| are all factors that matter more for outsourcing auth than they
| might, say, outsourcing your brochure website hosting, or
| outsourcing analytics. All outsourcing decisions will involve
| some of these dimensions, but with a different emphasis.
| jarym wrote:
| Lots of good points but 'outsource' here can mean a variety of
| things.
|
| We have SuperTokens (self-hosted or SaaS I think) and Keycloak
| (self-hosted only if I'm not mistaken) so most people don't need
| to 'roll their own'.
|
| But would I outsource the essential gateway to my service?
| Unlikely for the moment.
| mooreds wrote:
| Agree that "outsource" can mean different things. If I'm
| building a rails app, I should "outsource" authentication to
| Devise or Omniauth (typically). There are lots of great
| options, libraries and services, commercial and open source,
| self hosted and operating as a SaaS.
|
| What I always want to avoid is anyone running "create table
| user ( id int(32) ... )".
|
| > But would I outsource the essential gateway to my service?
| Unlikely for the moment.
|
| Do you outsource the operation of your database? Some people
| would never do that, as they consider it core to their business
| operations and have the skills to run it. Others evaluate the
| options and decide that outsourcing running a database makes
| sense for their situation.
|
| Engineering is all about tradeoffs.
| marcosdumay wrote:
| > What I always want to avoid is anyone running "create table
| user ( id int(32) ... )".
|
| Hum... I have never seen a system that could ditch a user
| table, whatever authn and authz schema it's using. (An
| independent authn service only makes it more complicated,
| because you now have redundant user tables.)
|
| But a password column can be avoided.
| mooreds wrote:
| Fair point, as most systems need to refer to users for
| internal relations, though with a fully outsourced solution
| you can get by referencing the external user ids.
|
| As you suggest, I should have mentioned the big things to
| avoid are password hash and salt columns.
| erwincoumans wrote:
| So storing password hashes is better done in a file than
| in a database?
| marcosdumay wrote:
| It's better done by some code that you (or anybody not
| focused on authn) didn't hack-up on half a day.
|
| Knowing that the hashes are not stored on the database
| that most of your external interfaces access can bring a
| lot of tranquility, but you'll get some PII there anyway,
| so I'm not sure that tranquility is warranted.
| erwincoumans wrote:
| Any recommendation for an open source, self-hosted auth solution
| would be good (useable with c++, javascript etc)? OAuth 2.0?
| Keycloak?
| tomduncalf wrote:
| I'm currently investigating this area and have been recommended
| Parse and Supabase
| erwincoumans wrote:
| Looks like C++ client support is still a request?
| https://github.com/supabase/supabase/discussions/5
| dljsjr wrote:
| The ORY stack: https://www.ory.sh
| erwincoumans wrote:
| Thanks! Can you recommend any C++ client example to use the
| ORY stack?
| mtalantikite wrote:
| The ORY SDKs are auto-generated using OpenAPI, so you could
| probably request one or generate one yourself
| (https://github.com/ory/sdk). I just put in a request for a
| Rust SDK and was able to auto-generate one locally for
| testing purposes pretty easily.
| [deleted]
| brokenwren wrote:
| (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.
| ithrow wrote:
| Is the self-hosted solution limited in some sense or feature
| complete?
| brokenwren wrote:
| 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.
| brabel wrote:
| Not open source, but free as in beer:
| https://curity.io/product/community/
|
| It's a complex server, but if you need to connect to lots of
| third party systems it may be a good choice as it has support
| for all sorts of things and its plugins are open-source (e.g.
| BitBucket plugin: https://github.com/curityio/bitbucket-
| authenticator)
| grinich wrote:
| We've taken a slightly different approach to this at WorkOS. (I'm
| the founder.)
|
| We decided to handle authentication but explicitly _ _not_ _ user
| management or authorization.
|
| This means our API is essentially just an OAuth2 wrapper around
| enterprise identity systems like Okta, Microsoft ADFS, generic
| SAML, OpenID Connect, etc. We don't require developers to migrate
| users into WorkOS, handle access policy, or "own" the user
| object. The primary user database always stays in the developer's
| app and WorkOS just serves as an authentication gateway. This
| turns out to be much more flexible, faster to integrate, and
| ultimately what developers actually want when adding advanced
| authentication strategies to their app (like enterprise SSO).
|
| So I guess what I'm saying is this article title is a bit of a
| misnomer. It's actually about outsourcing your user management
| and identity infrastructure to FusionAuth, which is a much larger
| decision with architectural effects. And unfortunately that
| results in strong vendor lock-in to a platform like FusionAuth
| (or Auth0).
|
| (For anyone curious, you can see more about the WorkOS approach
| here: https://workos.com/docs)
| Stierlitz wrote:
| > Why outsource your auth system?
|
| To make it easy for the spooks to backdoor your clients systems?
| freitasm wrote:
| I particularly like this one FTA: "When your competitors'
| authorization systems are down at the same time yours are,
| nobody blames you for it, but when you're the only company
| having issues, you suffer reputationally. No matter what your
| outsourced auth system is (FusionAuth, Cognito, AAD, etc), you
| can be almost certain that you won't be alone in the event of
| an outage."
|
| Ok...
| fmajid wrote:
| They give the real reason: because if your auth provider is
| breached other clients will be as well and that diffuses the
| blame. (non)-security by herd instinct.
___________________________________________________________________
(page generated 2021-01-20 23:02 UTC)