An analysis of the Keycloak authentication system

Identity, authn and authn are hard. A failure in the code, logic or at the seams messes up everything that it tries to protect. There are a few big commercial players trying to take the market with their "social login", and a few smaller (open-source) players trying to compete and survive, walking a fine line between open-source and open-core.

I feel this is one avenue where a few open-source players should get some solid funding and support from both the organisations and governments that use their software so we don't end up with unmaintained bug-riddled code and have to login with Google or Facebook everywhere.

A lot of the government agencies I work with use open-source IdP software (because they have to privacy- and policy-wise), so some healthy funding model should be possible for people with the skill and interest.

I maintain a reasonably good table of the open source options here: https://github.com/lastlogin-net/obligator?tab=readme-ov-fil...

It's one thing if your domain is hard, and another if you can't be bothered to fix a core problem in your service for ten months. Why would I trust you with my security if that's how long you leave vulnerabilities open after knowing about them?

Assuming this is a rather complete list... It's interesting that most were written in Go.

> Identity, authn and authn are hard.

Just a typo, was one of those authns meant to be something else, or a meta-joke (of the "there are two hard problems" type)?

I assume one was supposed to be "authz"

> Identity, authn and authn are hard.

It would be great if you or somebody else could complete the idea of hardness with a comparison. Am I wrong if I say that this kind of auth systems require formal methods to check them? I don't think that a 10-month timeline is linked to the hard problem.

What is Vanity?

And how it has little dependencies

> Identity, authn and authn are hard

They are technically straightforward problems. The challenge is usually political; who owns the identity, who manages the identity, privacy concerns of users, etc.

Authz can get crazy, there's a lot of over-engineered solutions there because there's basically no hard boundary between authz and general business logic.

But identity and authn are relatively straightforward, technically, and we ought to have a better FOSS solution than just Keycloak.

Any insight on supertokens? https://supertokens.com/