[jonathaneunice]

> I was pretty appalled to see such a basic mistake from a security company, but then again it is Okta.

Oh. Em. Gee.

Is this a common take on Okta? The article and comments suggest...maybe? That is frightening considering how many customers depend on Okta and Auth0.

[parliament32]

We evaluated them a while ago but concluded it was amateur-hour all the way down. They seem to be one of those classic tech companies where 90% of resources go to sales/marketing, and engineering remains "minimum viable" hoping they get an exit before anyone notices.

[kenhwang]

I'm convinced Okta's entire business model is undercutting everyone with a worse product with worse engineering that checks more boxes on the feature page, knowing IT procurement people aren't technical and think more checkboxes means it's better.

[ecshafer]

"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.

[CalRobert]

When I was working at Auth0 the repeated phrase about the value of getting bought by Okta was that they had the best sales org in the industry. It was implied that this was why we were getting bought by them, instead of the reverse.

[icedchai]

Okta is already public and has been for years. They had an exit already. For whatever reason, many large organizations trust them.

[Y_Y]

Okta sucks balls. That's from my perspective as a poor sod who's responsible for some sliver of security at this S&P listed megacorp that makes its purchasing decisions based on golf partners.

[lq9AJ8yrfs]

Among the reasons to leave my last job was a CISO and his minion who insisted spending $50k+ on Okta for their b2b customer and employee authentication was a bulletproof move.

When I brought it up, they said they didn't have anyone smart enough to host an identity solution.

They didn't have anyone smart enough to use Okta either. I had caught multiple dealbreakers-for-me such dubious / conflicting config settings resulting in exposures, actual outages caused by forced upgrades, not to mention their lackluster responses to bona fide incidents over the years.

I use Authentik for SSO in my homelab, fwiw.

[ecshafer]

Keycloak is a great authentication suite, not that hard to configure and rock solid.

Ill never understand this thinking.

[solatic]

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.

[lq9AJ8yrfs]

I rather disagree on the difficulty of pulling it off. The problem space is well-defined and there aren't that many degrees of freedom in functional design.

I'll concede there is some complexity in integrating with everything and putting up with the associated confusion. And granted the stakes are a little raised due to the nature of identity and access, and like you point out what could go wrong. Implementation is annoying, both writing the identity solution and then deploying and operating it. But the deployment & operation part is still there if you go with Okta or 1Login or Cognito or whomever.

The implementation is a capital type thing that is substantially solved already with the various F/OSS solutions people are mentioning - it's just a docker pull and some config work to get it going into a POC.

There are much harder problems in tech IMO, anything ill-defined for starters.

The C-level folks seem to think they are buying some kind of indemnity with these "enterprise" grade solutions, but there is no such thing. They'll even turn it around and take Okta's limitations as existential--"if even Okta doesn't get it right, there is no way we could pull it off". Out of touch, or less politely, delusional.

[solatic]

> The C-level folks seem to think they are buying some kind of indemnity with these "enterprise" grade solutions, but there is no such thing.

Something you need to understand about executives, is that they're not really individual God-like figures ruling the world; at the end of the day they answer to their CEO, to their Boards, and want to look good to executive recruiters who might consider them for a C-level role at a larger company for higher pay; and a good many of them lead not-so-affordable lifestyles to keep up appearances among aforementioned folk and might be worse off in their personal finances than you.

All of which is just to say - "nobody got fired for buying IBM." It might be tragic, but going with peer consensus is what helps them stay with their in-crowd. The risks for departing from the herd (holding up deals on compliance concerns, possibly higher downtime for whatever reason, difficulty of hiring people who demand cheaper salaries but already know an Industry Standard Solution) are too high compared to the potential benefits (lower total cost of ownership, increased agility, better security/engineering quality, higher availability assuming for the sake of argument that is actually the case), particularly when increased agility and better quality are difficult to quantify, higher availability is hard to prove (Okta and peers don't exactly publish their real availability figures), and the difference in TCO is not enough to move the needle.

It's very rare to find executives who care more about their company's engineering than their peer group - folks who care that much rarely become executives in the first place.

[mmsc]

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

[nh2]

Disclose publicly then, if you haven't already?

Definitely makes things safer than users not knowing about them.

[dspillett]

Are these documented anywhere? A full month with no response at all puts you firmly in “responsible disclosure” territory if they are not already publicly known. I'm pretty sure DayJob uses keycloak (or at least is assessing it - I'm a bit removed from that side of things these days) so that information could be pertinent to us.

[swiftcoder]

Yeah, I have the misfortune of inheriting a SaaS that built on auth0, and the whole stack is rather clownish. But they tick all the regulatory boxes, so we're probably stuck with them (until they suffer a newsworthy breach, at any rate...)

[inkyoto]

Okta and auth0 are, fundamentally, two distinct products – conceived, designed, and engineered by entirely separate entities.

auth0, as a product, distinguished itself with a modern, streamlined architecture and a commendable focus on developer experience. As an organisation, auth0 further cemented its reputation through the publication of a consistently high-calibre technical blog. Its content goes deeply into advanced subjects such as fine-grained API access control via OIDC scopes, RBAC, ABAC and LBAC models – a level of discourse rare amongst vendors in this space.

It was, therefore, something of a jolt – though in retrospect, not entirely unexpected – when Okta acquired auth0 in 2021. Whether this move was intended to subsume a superior product under the mediocrity of its own offering or to force a consolidation of the two remains speculative. As for the fate of the auth0 product itself, I must admit I am not in possession of definitive information – though history offers little comfort when innovation is placed under the heel of corporate, IPO driven strategy.

[shakna]

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

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

[inkyoto]

What is the point that you are trying to make?

Okta has committed to and has had a consitent track record of delivering at least one full scale security breach and the consistent user expericence degradation to their customers every year – and completely free of charge.

[shakna]

Absolutely. And auth0 was also delivering that, before acquisition. It isn't a change of routine.

[hexbin010]

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

[inkyoto]

Indeed, although I am in no position to make comments on the quality of their own product specific documentation.

Surprisingly, I have found that many people struggle to wrap their heads around the relative simple concepts of RBAC, ABAC and, more recently, LBAC. auth0 did a great job at unfolding such less trivial concepts into a language that made them accessible to a wider audience, which, in my books, is a great feat and accomplishment.

[shakna]

> until they suffer a newsworthy breach, at any rate...

I suppose it has been a couple years since the last... [0]

[0] https://techcrunch.com/2023/11/29/okta-admits-hackers-access...

[SAI_Peregrinus]

Yep. They're an Enterprise™ company. That means they prioritize features purchasing departments want, not functionality.

[viraptor]

And when something doesn't work well like their super custom LDAP endpoint, talking to support is really painful.

[hi_hi]

We've recently moved to Auth0. I'm no security expert. Whats the recommended alternative that provides the same features and price, but without the risks suggested here?

[mooreds]

Heya, I work for FusionAuth. We have a comparable product for many use cases.

Happy to chat (email in profile), or you can visit our comparison page[0] or detailed technical migration guide[1].

0: https://fusionauth.io/compare/fusionauth-vs-auth0

1: https://fusionauth.io/docs/lifecycle/migrate-users/provider-...

[Exoristos]

It's not difficult to implement OAuth2. There are good libraries, and even the spec is not complicated. Or use AWS Cognito.

[inkyoto]

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...

[Exoristos]

None of this rings true, and I've implemented both OAuth2 and OpenID Connect multiple times, also reading the specs, which are quite direct. I'm sure you're right that vendors take liberties -- that is almost always the case, and delinquency of e.g. Okta is what started this thread.

[porker]

It's an AI bot. One for @dang

[inkyoto]

By the same token, if one can use the keyboard, it does not make them a human. Parrots (the non-stochastic kind) and monkeys spring to mind.

[SahAssar]

Why do you suspect that?

[inkyoto]

I have also designed and implemented enterprise grade OAuth2 / OIDC IdP's.

Beyond the aforementioned concerns, one encounters yet another quagmire – the semantics of OIDC claims, the obligations ostensibly imposed by the standard, and the rather imaginative ways in which various implementations choose to interpret or neglect those obligations.

Please allow me to illustrate with a common and persistently exasperating example: user group handling, particularly as implemented by Okta and Cognito. The OIDC spec, in its infinite wisdom, declines to define a dedicated claim for group membership. Instead, it offers a mere suggestion – that implementers utilise unique namespaces. A recommendation, not a mandate – and predictably, it has been treated as such.

In perfect accordance with the standard’s ambiguity, Okta provides no native «groups» claim. The burden, as always, is placed squarely upon the customer to define a custom claim with an arbitrary name and appropriate mapping. User group memberships (roles) are typically sourced from an identity management system – not infrequently, and regrettably, from an ageing Active Directory instance or, more recently, a new and shiny Entra instance.

Cognito, by contrast, does define a claim – «cognito:groups» – to represent group membership as understood by Cognito. It is rigid, internally coherent, and entirely incompatible with anything beyond its own boundaries.

Now, consider a federated identity scenario – Okta as the upstream identity provider, federated into Cognito. In this scenario, Cognito permits rudimentary claim mapping – simple KV rewrites. However, such mappings do not extend to the «cognito:groups» structure, nor do they support anything approaching a nuanced translation. The result is a predictable and preventable failure of interoperability.

Thus, despite both platforms ostensibly conforming to the same OIDC standard, they fail to interoperate in one of the most critical domains for medium to large-scale enterprises: user group (role) resolution. The standard has become a canvas – and each vendor paints what they will. The outcome, invariably, is less a federation and more a fragmentation – dressed in the language of protocol compliance.

> I've implemented both OAuth2 and OpenID Connect multiple times

Whilst I do not doubt that you have made multiple earnest attempts to implement the specification, I must express serious reservations as to whether the providers in question have ever delivered comprehensive, interoperable support for the standard in its entirety. It is far more plausible that they focused on a constrained subset of client requirements, tailoring their implementation to satisfy those expectations alone at the IdP level and nothing else. Or, they may have delivered only the bare minimum functionality required to align themselves, nominally, with OAuth2 and OIDC.

Please allow me to make it abundantly clear: this is neither an insult aimed at you nor an indictment of your professional capabilities. Rather, it is a sober acknowledgement of the reality – that the standard itself is both convoluted and maddeningly imprecise, making it extraordinarily difficult for even seasoned engineers to produce a high-quality, truly interoperable implementation.

> I'm sure you're right that vendors take liberties -- that is almost always the case, and delinquency of e.g. Okta is what started this thread.

This, quite precisely, underscores the fundamental purpose of a standard – to establish a clear, concise, and unambiguous definition of that which is being standardised. When a standard permits five divergent interpretations, one does not possess a standard at all – one has five competing standards masquerading under a single name.

Regrettably, this is the exact predicament we face with OAuth2 and OIDC. What should be a singular foundation for interoperability has devolved into a fragmented set of behaviours, each shaped more by vendor discretion than by protocol fidelity. In effect, we are navigating a battlefield of pluralities under the illusion of unity – and paying dearly for the inconsistency.

Needless to say, OAuth2 and OIDC are still the best that we have had, especially compared to their predecessors, and by a large margin.

[dizhn]

https://goauthentik.io/#comparison

They have an enterprise version now (mostly for support and bleeding edge features that later make it into the open source product.)

It's pretty easy to self host. I have been doing it for a small site for years and I couldn't even get any other open source solution to work. They are mostly huge with less features.

[gnaman]

No provider has been able to match Auth0 actions unfortunately. Auth0 allows you to execute custom code at any point in the auth lifecycle and allow/deny based on that or enrich user attributes. Super useful when you have a legacy system that is hard to migrate away from. If anyone has any recommendations I'm all ears

[mooreds]

I work for FusionAuth.

We have lambdas (basically JavaScript code that can make API calls[0] and be managed and tested[1]) that execute at fixed points in the auth lifecycle:

- before a login is allowed

- before a token is created

- after a user returns from a federated login (SAML, OIDC, etc)

- before a user registers

And more[2].

And we're currently working on one for "before an MFA challenge is issued"[3].

There are some limitations[4]. We don't allow, for instance, loading of arbitrary JavaScript libraries.

Not sure if that meets all your needs, but thought it was worth mentioning.

0: https://fusionauth.io/docs/extend/code/lambdas/lambda-remote...

1: https://fusionauth.io/docs/extend/code/lambdas/testing

2: full list here: https://fusionauth.io/docs/extend/code/lambdas/

3: https://github.com/FusionAuth/fusionauth-issues/issues/2309

4: https://fusionauth.io/docs/extend/code/lambdas/#limitations

[gnaman]

thank you I will check you guys out

[dizhn]

I am not qualified to say whether Authentik can do all of what you need but it does allow custom python code in a lot of places. Perhaps you can ask whether what you need is available directly. They are very active in Discord.

[risson]

(authentik maintainer here) It does! Also, not only in the authentication process, but also during individual authorization flows, and in a few other places as well, like when a user edits their settings, or whenever an event (basically whenever something happens in authentik) but that's more a reactive process than inline

[fheisler]

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...

[dizhn]

Cloudflare??? Damn. that is HUGE! Congratulations. You guys have a super solid product full of features and a decent founder. Maybe enterprises don't care about my favorite feature but it makes securing EVERYTHING a breeze. Embedded proxy! That is GOAT.

[grinich]

If you’re looking for b2b identity, I’m the founder of WorkOS and we power this for a bunch of apps. Feel free to email me, [e-mail]

[catlifeonmars]

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.

[CalRobert]

It's not the same as Auth0, but you might be interested in Zitadel, if only because it's open source and you can use it hosted or self-hosted.

(Disclaimer: I work for Zitadel).

[pm90]

okta is the worst. Their support is the worst (we always got someone overseas who only seemed to understand anything, probably they were trained on some corpus) and would take forever to loop in anyone that could actually help.

[tracker1]

Honestly, I'm expressly not a big fan of outsourcing authentication/authorization.. . and even then, my personal list of trust is VERY limited. For the most part, I'll use Azure Entra (formerly Azure AD) and Windows AD only because of their entrenchment with other systems, and generally don't have much need to build more on top of what they already provide in the box.

That said, a lot of these things are very well documented... there are self-host systems and options both open-source, paid and combinations not to mention self-hosted options for both.

I've worked on auth systems used in banking and govt applications as well as integration with a number of platforms including Okta/Auth0. And while I can understand some of the appeal, it's just such a critical point of potential failure, I don't have that much trust in me.

I wish I could have open-sourced the auth platform I wrote a few years ago, as it is pretty simple in terms of both what it can do and how to setup/configure/integrate into applications. Most such systems are just excessively complex for very little reason with no reasonable easy path.

[rozap]

Yea auth0 is an absolute clown show.