Comment by jonathaneunice

"Enterprise Software" is what Tobi Lutke called that in a keynote once. A focus on hitting as many feature checkboxes as possible at the cost of quality.

Auth providers are among the hardest systems to secure. It's not just a question of the underlying code having vulnerabilities - for companies with Internet logins, auth systems (a) are exposed to the internet, (b) are not cache-friendly static content, (c) come under heavy expected load, both malicious (the DDoS kind) and non-malicious (the viral product launch kind), (d) if they ever go down, the rest of the system is offline (failsafe closed).

It's hardly surprising that the market prefers to offload that responsibility to players it thinks it can trust, who operate at a scale where concerns about high traffic go away.

Keycloak has various vulnerabilities they haven't even responded to after a month of reporting them.

Apart from auth0 getting hacked, before getting acquired by Okta. [0]

[0] https://auth0.com/blog/auth0-code-repository-archives-from-2...

Auth0 spent more time documenting and blogging about standards than documenting their own software. It was a bit bizarre. Their documentation was absent and or terrible IIRC

Thanks for the mention! (Authentik Security CEO here.) We've become something of Okta migration experts at this point... Cloudflare moved to us a couple years back after they had to be the ones to let Okta know it'd been breached yet again. [1]

[1] https://blog.cloudflare.com/how-cloudflare-mitigated-yet-ano...

Constructing a new OAuth2/OIDC Identity Provider from the ground up is an undertaking fraught with complexity – and not of the elegant variety. The reasons are numerous, entrenched, and maddeningly persistent.

1. OAuth2 and OIDC are inherently intricate and alarmingly brittle – the specifications, whilst theoretically robust, leave sufficient ambiguity to spawn implementation chaos.

2. The proliferation of standards results in the absence of any true standard – token formats and claim structures vary so wildly that the notion of consistency becomes a farce – a case study in design by committee with no enforcement mechanism.

3. ID tokens and claims lack uniformity across providers – interoperability, far from being an achievable objective, has become an exercise in futility. Every integration must contend with the peculiarities – or outright misbehaviours – of each vendor’s interpretation of the protocol. What ought to be a cohesive interface degenerates into a swamp of bespoke accommodations.

4. There is no consensus on data placement – some providers, either out of ignorance or expedience, attempt to embed excessive user and group metadata within query string parameters – a mechanism limited to roughly 2k characters. The technically rational alternative – the UserInfo endpoint – is inconsistently implemented or left out entirely, rendering the most obvious solution functionally unreliable.

Each of these deficiencies necessitates a separate layer of abstraction – a bespoke «adapter» for every Identity Provider, capable of interpreting token formats, claim nomenclature, pagination models, directory synchronisation behaviour, and the inevitable, undocumented bugs. Such adapters must then be ceaselessly maintained, as vendors alter behaviour, break compatibility, or introduce yet another poorly thought-out feature under the guise of progress.

All of this – the mess, the madness, and the maintenance burden – is exhaustively documented[0]. A resource, I might add, that reads less like a standard and more like a survival manual.

[0] https://www.pomerium.com/blog/5-lessons-learned-connecting-e...

We use WorkOS to support some of our offerings but not for our own corporate identity/authentication. I’m not close to the project so I don’t have experience using WorkOS but definitely curious about replacing Okta.