Personally I think of Authelia and Keratin as really good projects in the don't-build-auth-into-your-apps-ever-again space. If auth isn't already built into your app gateway/mesh/proxy, then these services might be something worth dropping alongside.
A few more projects in this space:
- Keycloak (you won't get fired for picking this)[0]
- CloudFoundry's UAA[1]
- Gluu [2]
- ORY (Hydra + friends)[3]
- Keratin [4]
- OpenUnison [5]
- Dex[6]
- Netlify's GoTrue[7]
All of these solutions are a bit different but here are some of the axes:
- Whether or not they function as an OAuth provider
- Whether they're centered around application-user-login via mechanisms like email/password, application auth, or SSO
- Whether or not they serve as a proxy to another down-the-line OAuth provider (Dex, GoTrue)
- GUI availability
- F/OSS-ness (basically all of them have very permissive licenses)
Exist other 2 major things that I have tried to find but is rarely missed:
1- GOOD multi-tenant support.
Without extra weird hoops like with ORY.
How this must be? Just passing a subdomain is all necessary to route and it need to make easy to create/remove tenants as part of MY logic, not need to orchestrate stuff.
2- Use my own tables. (or allow to set FX/new fields)
I appreciate to have automated all the stuff but I have much logic around what is a "user" (and in a recent project, 2 kinds of user in 2 different tables: salesman/customers).
Ideally, this stuff only need to do "SELECT fields_for_auth FROM my_table"
As a side note, I'd be willing to work specifically with someone wishing to utilize this to improve it. Feel free to reach out on our matrix or discord.
If managing data directly and personally is a requirement for you, then you probably don't want these tools. Part of the reason they exist is to manage user data (passwords, tokens, etc.) correctly and with minimal surprises.
ORY Kratos, as an example, will happily create different conceptual types of users and you can store arbitrary data in those user documents, but it is modified through an API and exposes to you stable IDs against which you can code the rest of your application.
> ORY Kratos, as an example, will happily create different conceptual types of users and you can store arbitrary data in those user documents, but it is modified through an API and exposes to you stable IDs against which you can code the rest of your application.
The stable-ID solution was how I handled this when I wrote one of these as an internal tool (guess you'd call it a "microservice") for a startup I worked for back in like 2010. In hindsight I guess I should have pushed to pivot to selling that as our product since we ended up selling the company for barely-pay-back-the-investors money, but who knew? Hahaha.
Also identified permissionable-objects as UUIDs, which let me handle authorization in addition to authentication. Creating a new "permission" object meant asking for one from the service, then you'd receive a UUID, associate that with whatever thing you were applying the permissions to on your end, and tell the service to assign the desired permissions. Then you could just query the permissions for that UUID (which could, potentially, represent a bundle of items, a single item, or permissions to an entire service—how to interpret it was left up to the consuming service) and of course cache them as much as you felt was proper. IIRC there as also a concept of owning-objects so you could let permissions be inherited, then override on a case-by-case basis, plus it'd let you ask which objects belonged to a given collection. IIRC I used that to represent organizations, too, since they were basically the same thing as a permissionable-object container themselves needing to be permissionable.
Not a perfectly-flexible system (billions of items that all need distinct permissions might have eventually forced sharding or something, but luckily we didn't have to worry about that) but it was rock solid for our purposes and made spinning up new services or products sharing login with our main product super-easy.
The problem is that this tables are like "foreign" to the db, in a micro-service mindset (the worst anti-pattern to date!).
That is a major complication.
In Django, this solve neatly, because I can point to my own table or easily integrate the ones of Django without much fuss. This turn all this in a non-issue.
Yes, they're foreign to your application's database. That's the point: by using these tools you're buying into a service-oriented architecture.
What you are advocating is to collapse the service-oriented architecture into a "everybody parties on the database" architecture. These tools are very much invested in you not doing that. There already exist user-auth libraries for what you want and run inside your application itself.
Is this so you can easily private label the application? Or is there some other use case for which multi tenant support is critical?
> Use my own tables. (or allow to set FX/new fields)
I'm not sure what 'FX' is (maybe a typo for 'FK'?).
Do you mean the ability to store arbitrary data on the objects provided by the auth system (even if it is via API like a sibling comment mentions) or are you talking about the ability to create tables or have a foreign key directly into your application's database? Would stable GUIDs solve this for you?
> Or is there some other use case for which multi tenant support is critical?
To support multi tenants in software-as-services. I need to support "company1.app.com, company2.app.com" in my apps.
> Do you mean the ability to store arbitrary data on the objects provided by the auth system...
The thing is that a "user" have different means. I have salesman's, customers, operators, etc.
Them have fields, like email, is_active, personal info, that are critical for the logic of the app.
IDEALLY the auth server manage the security and read only the fields that are needed to operate this (like for send a password reset).
The other fields, triggers, indexes, etc are more important the rest of the time.
And I don't want to use a "will create corrupted integrity for sure, aka: micro services" because I work in the "sync data across dbs" and it ALWAYS will happened if data is not in single transaction.
I have definitely seen folks use the id created by the auth system but nothing else. Everything else keys off the GUID, which should be immutable, and is stored in application specific tables.
The password and username are in the auth system, but everything else stays in control of the application, in one database.
I don't see why you couldn't use that pattern no matter which external auth provider you are using. You'd just give up things like self service registration, but that may be the right choice for your app.
Keycloak has a couple of things than can go wrong with multi tenancy especially if you consider using one keycloak realm for each customer after 100 realms keycloak can just become unresponsive and the tokens from the master admin realm become to big. (https://issues.redhat.com/browse/KEYCLOAK-4593)
Keycloak (you won't get fired for picking this) Not if you're just picking it, but possibly if you have to administer it. We're in the process of replacing it, possibly with Hydra.
We switched from Keycloak-on-CentOS to Keycloak-in-Docker, and it made configuration & updating so much easier. It is no longer necessary to fight with JBoss xml config, but there are nicely defined env vars to configure exactly the things that are interesting to anyone who uses Keycloak, instead of random Java stuff.
Please note this the next time someone in your organization or outside rails against dockerizing crucial infrastructure versus maintaining some well manicured packer/ansible/puppet/chef/salt scripts that rely on apt/deb/rpm/apk for instances that are occasionally manually tweaked in emergencies.
Docker isn't always the right choice, but I personally feel a lot more empowered to run infrastructure pieces that are dockerized because the inputs and outputs are much more explicit and easier to manipulate and change in isolation (I don't have to remember 3 directories where config could be, I just mount the one volume for example).
When you want an off-the-shelf component that you don't have to tweak or maintain, Docker containers are fantastic. Most projects that publish a container also integrate features so you almost never have to build a custom image.
I only had to deal with administering it once, and I didn't like the experience but also could have imagined the company picking so many things that would have been worse/more awkward to manage.
I get a little intimidated by Ory's multi-app approach to all of it (who wants to deploy & manage 4 containers/VMs versus 1 with Keycloak?), but I know I need to give it a proper chance one of these days. Hydra seems to be a very polished entrant in the space.
Depending on your use case, for example if you only have one application, you might be better off running something embedded in your app, or independent but using the same runtime/deployment environment. Then, when you are ready to add another app or integration, you should be able to introduce a standalone auth system more easily if appropriate (because all your auth interactions should be relatively standardized). I'm a big fan of standalone auth systems as a way to simplify access control and give a single view of a user/customer, but you can also succeed using open source embedded libraries.
When the moment comes to introduce a standalone system, you should consider a few dimensions (this list pulled from a previous comment of mine: https://news.ycombinator.com/item?id=26360048 ):
* open source or not
* standalone application or library/framework you integrate
* self hosted or SaaS
* authentication, authorization, user management or all three?
* standards coverage
* SSO support
* integrations with other auth tech (LDAP)
* which OAuth grants are supported
* cost
* operational complexity/support for your deployment environment
* specific features if needed (for example, customization of the look and feel with themes, or customization of the login flow with something like Keycloak's plugin system)
* documentation and developer experience
These dimensions all matter to varying degrees depending on your team and needs.
Disclosure: I work for https://fusionauth.io/ which has open source supporting libraries and docs, but which is itself not open source.
EDIT: added cost, operational complexity and customization to the list.
I actually did exclude those on purpose, because I think they're somewhat out of scope -- arguably the point of running something like Authelia/Keratin/Dex/Keycloak/etc is to not write a single line of auth code, even if it's just wiring up a module/component.
That said, here are some more in the space that I personally have earmarked:
- (all-in-one) jsso2[0]
- (all-in-one, embeddable) a12n-server[1]
- (embeddable) node-oidc-provider[2]
- (embeddable) node-oauth2-server[3]
- (all-in-one, embeddable) authboss[4]
- (proxy) vouch-proxy for NGINX[5]
- (proxy) Grant with support for over 200 provider (!!)[6]
I am using vouch-proxy as it is a very simple addon that lets me use my existing OpenID Connect compatible IDP for authentication on anything fronted by Nginx. This works really well for services not really designed to have their own auth.
The only downside is that it seems to require a second DNS entry for the vouch portion of the process. Awkward configuration in some ways. But, the price is right, and the Nginx config is reasonably clean once you understand what it's doing.
If you are looking for an open source solution, it is definitely the 800 lb gorilla.
If you are looking for a commercial solution, I would say that the top competitors are Okta, Auth0, Azure AD, and Firebase (though the latter, from what I've heard, doesn't play nicely with standards).
And now that Okta and Auth0 are the same, the big two options are Okta/Auth0 and Azure AD. I don't know how much Firebase gets used at scale but the price "scales" so well that I think most people switch off of it after the MVP validation phase. Just conjecture though, no numbers to back that up -- an enterprise client is probably not going to use your product because it has Firebase login integration.
> And now that Okta and Auth0 are the same, the big two options are Okta/Auth0 and Azure AD.
I mean, it's yet to be determined how Okta and Auth0 are going to integrate. I have read that Okta has three sets of APIs, maybe Auth0 will be a fourth?
> an enterprise client is probably not going to use your product because it has Firebase login integration.
LOL. It might even be a negative signal.
But I hear Firebase is thinking about supporting standard OAuth, which would be great.
I wouldn't say they're the same thing except from a brand name perspective. Okta is barely app-focused; much more enterprise SSO. Auth0 is extremely app-focused, although they can do some enterprise SSO as well.
Okta bought Stormpath (and killed it) and now Auth0 because of this difference, and because there's a finite total addressable market for employees, but an almost infinite total addressable market for app users.
And as others have noted, this is probably the most enterprise-grade/production-hardened solution out there in the list that I made that represents my current list in the F/OSS space. If I were to think hard about it, there are probably lots of much older options (depends on where you put the scope of AuthN to be, is LDAP a competitor?), but Keycloak is probably the one you're going to find the most resources and scrutiny around.
A large financial institution I worked with two years ago was using Keycloak. I was annoyed with some UI bits and terminology that was very confusing but it was overall a great choice back then IMO, has probably mostly/only gotten better since.
Thanks for this list, it is very useful. Do you know of a "real world" example use for Keratin Authn? I see the diagrams and it looks like it could be useful but it kind of looks like moving the login/password part of the backend to another service (OK), but what happens with authorization? (user roles have ability to do specific tasks)
I don’t know about real world implementations but to answer the last question: IMO authorization responsibility belongs to the backend service. I like setups where the API Gateway talks to Keycloak for authenticating a request and passes a JWT with user/role info to the backend. The backend can then use the info from the JWT to perform authorization, and if necessary performs extra queries against an ACL table (or service).
> Werther is an Identity Provider for ORY Hydra over LDAP. It implements Login And Consent Flow and provides basic UI.
So basically, turn your LDAP into OAuth2, if I'm reading the features right:
> Support Active Directory;
> Mapping LDAP attributes to OpenID Connect claims;
> Mapping LDAP groups to user roles;
> OAuth 2.0 scopes;
> Caching users roles;
> UI customization.
Unfortunately this doesn't really free you from maintaining an LDAP server, it just... let's you login using OAuth instead, by bringing pieces of the ORY ecosystem along.
If anything I'd like something like the inverse of Werther - I don't necessarily want to have a complete LDAP db and setup. It's just those couple of softwares that support LDAP and nothing else, so just providing an LDAP authentication interface to some other auth/identity solution would be great.
Not having the time to implement that ourselves, we're stuck with LDAP as a backend as the common denominator.
Ahhhh, so that's really interesting, LDAP as the frontend to an anything-but-LDAP backend!
This feels like it might exist so I went looking, looks like Auth0 had this[0][1]. I'm not sure there are any open source projects that actually do this ldap-in-the-front-something-else-in-the-back, but you can get very close:
Seems like this is quite the unsolved problem (unless you're using Auth0). Maybe it's worth using Auth0 only for this. If you're going with the F/OSS solutions then it feels like you could either add a plugin (DB, OAuth maybe?) to glauth, or hack together some sort of system that updates the YAML/S3 as accounts get added.
[EDIT] - Also looks like Joyent has put together a framework for LDAP clients and servers in JS... (http://ldapjs.org/server.html). The raw pieces are there but someone would really need to put them together to offer the facade.
I would really like to see an open source IDP that can be run as a Lambda or similar for small scale employee OAuth, etc. without a permanent VM footprint. I’d write one, of course, but I’d be nervous about doing security critical code as a hobby. Do any exist?
Suggestions? GitLab/GitHub? I don't really use Google sheets and these links actually just come out of my book marks (I've got a 'Self-Hosted > Authentication' folder) and years of bookmarking.
... if you have the courage of dealing with Mediawiki tables (although the WYSIWYG editor has improved kind of enough to make that workable nowadays...)
is not an OAuth or OpenID Connect provider yet (planned in the roadmap)
is not a SAML provider yet.
does not support authentication against an OAuth or OpenID Connect provider yet.
does not support authentication against a SAML provider yet.
does not support using hardware devices as single factor.
does not provide a PAM module yet.
oauth2_proxy is a great tool that lets you create a transparent OAuth proxy to provide SSO for any internal service. Protect an entire subdomain of services using one identity provider! Guides exist for integrating it with K8s, but luckily it's just a binary so you can protect non-K8s services with it too. It's also super easy to deploy, as you can configure the whole thing with just environment variables, or a config file. The docs are decent too. https://github.com/oauth2-proxy/oauth2-proxy
They all have different OAuth providers, so check them each out to see which one works with your identity provider. (GitHub OAuth + SSO makes using these a no-brainer)
The only sso provider I've really used is keycloak, so I am looking forward to having more lightweight alternative in this domain! though it doesn't seem to be a oidc server yet.
What confused me a little is that it aims to put the authentication into the proxy layer, which sounds awesome... But I haven't been able to figure out from the docs how I'd be able to identify the user in my application now?
/Edit: it's set as a header and can be verified it seems
With the ory platform one could use their oathkeeper but also Traefik with forward auth plugin would work. The latter gives more options. Food for thought, I’m sure Traefik forward auth would work here too.
One of the Authelia devs here. This is correct. Also we're looking to implement OIDC/OAuth2.0 provider functionality. It has been somewhat delayed by COVID19, specifically additional personal burdens that arose because of it.
Any product supporting API Keys (ala github personal access tokens) out of the box ? In our case, we are only interested in a service to service scenario.
I really liked Expresss API Gateway, a middleware for express that gives a nice API for creating and using auth tokens: https://www.express-gateway.io/ It can act as a proxy to downstream services and secures access to them with those tokens.
Also check out bigger players in the API gateway space. Kong, Krakend, etc. Most of them all support auth tokens out of the box in the open source versions.
As with Keycloak, Auth0 can implement access tokens via a client and some code.
However, that would assume you use a custom policy within your token for access control, as Auth0 does not provide the same level of RBAC for clients as it does to users.
One of the Authelia devs here. Not yet as we currently are not a OIDC provider. However this is a feature we are prioritizing, and forward auth / auth request are viable alternatives for apps that have any RBAC or support a user/group header.
I’ll preface this with I’d rather not trust cloud infra for auth, but:
In a world where cloud providers can drop known botnet IPS, and have access to far more intel based on sparse infra and AI / secops teams, I’m struck between trusting them and trusting a self hosted product. How do you plan to be competitive with the security tech available to large auth as a service providers?
Why Open Source? Paragraph 1 "in the face of* the battlefield"
Definitely on the side of open source when it comes to security. But not because it lends itself to cheaper solutions but because it allows you to be sure your not being siphoned for corporate profit.
as soon as you want to enable users to self-host, esp on-prem/airgapped, any internet dependencies, unscannable code, etc, will fail basic env and security reqs.
In general, also loses control, which is a risk, and for technically unnecessary reasons, elevating that to radioactive. provide both oss and paid hosting, and becomes fine.
> as soon as you want to enable users to self-host, esp on-prem/airgapped, any internet dependencies, unscannable code, etc, will fail basic env and security reqs.
Hmmm. My employer has people who have used our commercial, closed source, self hosted auth software and obtained PCI compliance. I'm not a security expert, but my understanding is that is a relatively rigorous security process. Am I incorrect?
> provide both oss and paid hosting
How do you deal with the "Amazon/GCP/Azure takes the OSS software and cross sells it to their customer base" problem? This is something I've been thinking about for years and years.
Not that this is your problem to solve :) and I get that as a customer of a software business one typically doesn't care, but thought I'd ask.
One answer I've heard is "be better at running your software than AWS" which makes sense, but doesn't address cross selling. AWS doesn't have to be the best at running ElasticSearch, they just have to be good enough because they own a major distribution and payment channel.
Another answer I've heard is "you should be so lucky as to have a public cloud pick up your OSS project" which I totally understand (obscurity is a bigger competitor than the public could for most projects). But it doesn't address the very real threat to the business which may arrive just when the project can start to throw off profits to pay back the initial investment.
Again, I realize there's nuance here and that if a company takes the contributions of the community that can accelerate their growth and feature set. But I'm just curious on your take on the public cloud provider angle.
self-hosting solves the saas dependency part, which is great! saas should be a value add, not a req.
Proprietary & closed source means risk sign-offs and having to work w an extra party for sign-offs, so unattractive. I'm not sure an auth dependency merits that. (And nowadays, a negative signal for security...)
re:business model... I don't know VC-scale ($1-10B/yr), but not every infra project has to immediately turn into a 10K employee company. That's someone putting their global domination ambition over their users, so a sniff test for me on a co's management. Maybe there is a way to do it, and imo, a $50M/yr co here is totally doable, a fine achievement, and can be used to figure out Product 2. As an infra user, esp with our own users having us make high-trust decisions for things they don't really understand, I prefer adding dependencies to projects I don't think will do a quick flip / flameout / sell me out / etc.
Thanks, definitely appreciate the perspective and thoughtful answers.
I don't think that worries about a cloud provider eating the lunch a company has set (to get metaphorical on you) is solely limited to VC funded companies, but I do appreciate they're more likely to worry (see ElasticSearch, of course).
> but not every infra project has to immediately turn into a 10K employee company.
Also, I'm not sure I buy the concern about aws & friends in this space for a few reasons:
-- Now that SaaS for identity is established, the natural next step is OSS versions that come with SaaS, so if you're starting fresh and know that's coming... it seems short-sighted to start without that
-- aws & friends have their own identity products, so given the already-commoditized market, they're unlikely to want to be pushing your n+1 one
OSS seems more like a growth driver here than a risk b/c of the competitive market, though I can see that being unsettling to traditional business/VC types who are out of touch with the market. What the value-add for a managed layer is seems like "a lot possible", e.g., scale, support, multi-cloud, so I'd expect customers to pull you pretty quick if they didn't already.
In our case, quite explicitly, we're evaluating a path where on-prem single-tenant users can bundle & self-serve something (SSO/LDAP/...), while for our saas tier, we can hook into something normal by aws/azure/someone else. Lack of full-featured OSS (w/ no SaaS necessary) for on-prem, or at least a clear way to let us transparently swap something like Keycloak for those folks, is an instant no.
Good points about AWS, though I will say that AWS has multiple different document databases and caching engines, so if there was customer demand, I don't doubt that they would run a different identity service. I have not used it, but from what I've seen, Cognito doesn't seem to get much love.
> OSS seems more like a growth driver here than a risk b/c of the competitive market, though I can see that being unsettling to traditional business/VC types who are out of touch with the market.
I hope you weren't talking about me :) . We'll see, I certainly some funded auth startups going the open core/OSS route (SuperTokens, Clerky, WorkOS).
> In our case, quite explicitly, we're evaluating a path where on-prem single-tenant users can bundle & self-serve something (SSO/LDAP/...), while for our saas tier, we can hook into something normal by aws/azure/someone else. Lack of full-featured OSS (w/ no SaaS necessary) for on-prem, or at least a clear way to let us transparently swap something like Keycloak for those folks, is an instant no.
Yeah, we have a number of clients who use us just like this (both SaaS and on-prem, often as an identity broker) and are willing to pay our license fees for the support, the documentation and the functionality. I've also reached out to people who seemed like a fit and they had a hard requirement for OSS.
Containers run on lots of non-Docker runtime environments. You can just install runc, or if you have systemd you can use systemd-nspawn. Or if you want a more Docker-like experience there's podman. Or if you're working with it kubernetes and containerd will run containers.
And if you don't like any of that, look in the Dockerfile and replicate the setup on your server. IMHO in 2021 it's not worth someone's time to worry about the eccentricities of 20-30 year old bespoke unix/linux distributions and their myriad of incompatible decisions.
One of the Authelia devs here, we support a variety of methods of deployment as mentioned by a user below and include a systemd unit. If there is any deployment scenario you feel we've not accounted for that you prefer then we'd be more than willing to look at implementing it.
"Authelia can be installed as a standalone service from the AUR, FreeBSD Ports, or using a Static binary, Docker, or Kubernetes. Assistance to publish a debian package would be greatly appreciated."
This was interesting up until I found this line in the documentation. Which is having authentication based on cookies is a non-starter for many organizations at this point.
> Authelia relies on session cookies to authenticate users. When the user visits a website of the protected domain example.com for the first time, Authelia detects that there is no cookie for that user. Consequently, Authelia redirects the user to the login portal through which the user should authenticate to get a cookie which is valid for *.example.com,
Reading his other comment, koblas was actually talking about bearer tokens.
Not sure how they are actually better than cookies, though. Certainly can be a lot more complex. With cookies you mostly just have to avoid the *.example.com foot gun.
A few more projects in this space:
- Keycloak (you won't get fired for picking this)[0]
- CloudFoundry's UAA[1]
- Gluu [2]
- ORY (Hydra + friends)[3]
- Keratin [4]
- OpenUnison [5]
- Dex[6]
- Netlify's GoTrue[7]
All of these solutions are a bit different but here are some of the axes:
- Whether or not they function as an OAuth provider
- Whether they're centered around application-user-login via mechanisms like email/password, application auth, or SSO
- Whether or not they serve as a proxy to another down-the-line OAuth provider (Dex, GoTrue)
- GUI availability
- F/OSS-ness (basically all of them have very permissive licenses)
[EDIT] More entries for this list in another comment @ https://news.ycombinator.com/item?id=26411457
[0]: https://www.keycloak.org/
[1]: https://github.com/cloudfoundry/uaa
[2]: https://gluu.org/docs/gluu-server/4.2/
[3]: https://github.com/ory/hydra#what-is-ory-hydra
[4]: https://keratin.github.io/authn-server/
[5]: https://github.com/tremolosecurity/openunison
[6]: https://github.com/dexidp/dex
[7]: https://github.com/netlify/gotrue