As you said, there are plenty of local options that you only need to run. It also has the largest risk of compromise and data leaking from any service you may use, the largest amount of potential lock-in, and the least need for integration.
If you take any property of a service that makes it a good target for off-shoring, and reverse it, you get auth.
Well, many reasons, to be honest. Yes, you can easily set up some local LDAP/AD/Whatever and setup some OIDC/SAML connectors.
SaaS like Okta, OneLogin, even Google Directory offer many things that you don't have to think about:
- If your organization doesn't use SCIM and you have headcount that requires HR, then your IT department is wasting time. You also probably will fail audit.
- How do you limit which users allowed to use a service that uses OIDC or SAML?
- Where is audit log stored?
- What's your SLA?
- Does it integrate with HR software?
- Does it restrict access based on location? Is there some logic to prevent a user from city X suddenly login from a city 3000 miles away?
- Do you have contractors? How do they access resources they need?
Sounds like BoxyHQ could be relevant here. Plug-n-play for developers that need to build enterprise features like SSO, audit logs, directory sync, privacy vault and other boring stuff that are required to be compliant.
100% free & self-hosted. It's Open source (Apache-2.0 license)
[I am one of the co-founders, sorry for the plug]
> As you said, there are plenty of local options that you only need to run.
I think managed databases are a good analogy here. While I might run my own PostgreSQL/MariaDB instance, many out there won't be overjoyed at the idea of actually needing to run and manage the damned thing, as well as set up some kind of alerting and handling the need to eventually scale it up, in addition to backups and failover.
> It also has the largest risk of compromise and data leaking from any service you may use...
PII is definitely a big concern, even if something like password hashes aren't too useful on their own (provided that they're salted), though in cases like that it might actually make a lot of sense to utilize a widely used and tested solution that's specialized for this particular use case.
In many cases, thousands of people across the globe will be able to develop something and squash any bugs in it better than you might be able to do individually or with your own team, though there might be a few exceptions out there. Auth is probably not one of the cases where you want to write code without a lot of eyes on it.
> ...the largest amount of potential lock-in...
This is debatable: standards like OAuth2 and OIDC technically make many of the solutions and libraries way more pluggable and make it easier to choose between various implementations, depending on your needs.
Of course, something like Keycloak also has its own API (as do many of the cloud offerings) so if you build too much automation around a particular implementation, then that advantage partially goes out the window.
> ...and the least need for integration.
I'm not sure about this, it probably depends on your architecture. If you have a monolithic web app, then you probably don't need a separate turnkey/SaaS solution, whereas if you have an ever growing number of services, whilst you want to manage authentication and accounts against all of them centrally, then something like Keycloak (or one of the cloud alternatives) become way more lucrative.
That said, I'd still opt for self-hostable options whenever possible, albeit I also don't trust cloud based password managers and such, preferring something like KeePass instead. I've probably just come to a different conclusion in regards to usability/responsibility/features/security than some other people.
> I think managed databases are a good analogy here.
There is at least some work in managing a database. The risks are very similar, but at least there is some value in offshoring it.
I have never seen offshoring it being a net positive in terms of labor saved alone (it's way more work to make sure the managed database stays running than doing it yourself), but it can be positive in theory. It can scale down better in theory too.
> whereas if you have an ever growing number of services, whilst you want to manage authentication and accounts against all of them centrally, then something like Keycloak (or one of the cloud alternatives) become way more lucrative.
Well, Keycloak isn't a could SaaS. I bet the clould alternatives will give you all kinds of issues, starting at bad pricing (on that link, you will be enterprise before you can blink). But well, there is no reason at all to go and confirm it, the best they can do is to not add unreasonable operational costs over running your own, and just add some huge risks.
As you said, there are plenty of local options that you only need to run. It also has the largest risk of compromise and data leaking from any service you may use, the largest amount of potential lock-in, and the least need for integration.
If you take any property of a service that makes it a good target for off-shoring, and reverse it, you get auth.