6 ms·

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

> 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 11mo ago
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 11mo ago
  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 11mo ago
    "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 11mo ago
  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 11mo ago
  Okta is already public and has been for years. They had an exit already. For whatever reason, many large organizations trust them.
SAI_Peregrinus 11mo ago
Yep. They're an Enterprise™ company. That means they prioritize features purchasing departments want, not functionality.
- viraptor 11mo ago
  And when something doesn't work well like their super custom LDAP endpoint, talking to support is really painful.
Y_Y 11mo ago
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.
swiftcoder 11mo ago
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 11mo ago
  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.
  - hexbin010 11mo ago
    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
    - YouAreWRONGtoo 11mo ago
      [dead]
    - inkyoto 11mo ago
      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.
hi_hi 11mo ago
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?
- Exoristos 11mo ago
  It's not difficult to implement OAuth2. There are good libraries, and even the spec is not complicated. Or use AWS Cognito.
  - inkyoto 11mo ago
    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-every-idp-to-oidc https://www.pomerium.com/blog/5-lessons-learned-connecting-e...
pm90 11mo ago
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.
lq9AJ8yrfs 11mo ago
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 11mo ago
  Keycloak is a great authentication suite, not that hard to configure and rock solid. Ill never understand this thinking.
  - mmsc 11mo ago
    Keycloak has various vulnerabilities they haven't even responded to after a month of reporting them.
    - nh2 11mo ago
      Disclose publicly then, if you haven't already? Definitely makes things safer than users not knowing about them.
    - dspillett 11mo ago
      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.
  - solatic 11mo ago
    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.
rozap 11mo ago
Yea auth0 is an absolute clown show.
tracker1 11mo ago
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.

parliament32 11mo ago

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 11mo ago
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 11mo ago
  "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 11mo ago
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 11mo ago
Okta is already public and has been for years. They had an exit already. For whatever reason, many large organizations trust them.

SAI_Peregrinus 11mo ago

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

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

Y_Y 11mo ago

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.

swiftcoder 11mo ago

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 11mo ago
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.
- hexbin010 11mo ago
  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
  - YouAreWRONGtoo 11mo ago
    [dead]
  - inkyoto 11mo ago
    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.

hi_hi 11mo ago

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?

Exoristos 11mo ago
It's not difficult to implement OAuth2. There are good libraries, and even the spec is not complicated. Or use AWS Cognito.
- inkyoto 11mo ago
  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-every-idp-to-oidc https://www.pomerium.com/blog/5-lessons-learned-connecting-e...

pm90 11mo ago

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.

lq9AJ8yrfs 11mo ago

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 11mo ago
Keycloak is a great authentication suite, not that hard to configure and rock solid. Ill never understand this thinking.
- mmsc 11mo ago
  Keycloak has various vulnerabilities they haven't even responded to after a month of reporting them.
  - nh2 11mo ago
    Disclose publicly then, if you haven't already? Definitely makes things safer than users not knowing about them.
  - dspillett 11mo ago
    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.
- solatic 11mo ago
  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.

rozap 11mo ago

Yea auth0 is an absolute clown show.

tracker1 11mo ago

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.