[HN Gopher] Okta's NextJS-0auth troubles
___________________________________________________________________
Okta's NextJS-0auth troubles
Author : ramimac
Score : 363 points
Date : 2025-11-18 10:17 UTC (3 days ago)
(HTM) web link (joshua.hu)
(TXT) w3m dump (joshua.hu)
| dovys wrote:
| You're either free OSS that gets flooded with AI slop PRs to
| overwhelm maintainers or you're a corporate OSS that uses AI slop
| to frustrate contributors. Are there any positive stories I've
| not seen?
| manithree wrote:
| https://news.ycombinator.com/item?id=45449348
| mmsc wrote:
| Same author, even!;)
| cedws wrote:
| That's funny. I spotted a similar issue in their Go SDK[1] a few
| years back. I was pretty appalled to see such a basic mistake
| from a security company, but then again it is Okta. [1]:
| https://github.com/okta/okta-sdk-golang/issues/306
| jonathaneunice wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| "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 wrote:
| 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 wrote:
| Okta is already public and has been for years. They had an
| exit already. For whatever reason, many large organizations
| trust them.
| SAI_Peregrinus wrote:
| Yep. They're an Enterprise(tm) company. That means they
| prioritize features purchasing departments want, not
| functionality.
| viraptor wrote:
| And when something doesn't work well like their super
| custom LDAP endpoint, talking to support is really painful.
| Y_Y wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Apart from auth0 getting hacked, before getting acquired
| by Okta. [0]
|
| [0] https://auth0.com/blog/auth0-code-repository-
| archives-from-2...
| inkyoto wrote:
| 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 wrote:
| Absolutely. And auth0 was also delivering that, before
| acquisition. It isn't a change of routine.
| shakna wrote:
| > 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...
| hi_hi wrote:
| 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 wrote:
| It's not difficult to implement OAuth2. There are good
| libraries, and even the spec is not complicated. Or use AWS
| Cognito.
| inkyoto wrote:
| 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 wrote:
| 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 wrote:
| It's an AI bot. One for @dang
| inkyoto wrote:
| 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.
| inkyoto wrote:
| 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.
| grinich wrote:
| 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, mg@workos.com
| catlifeonmars wrote:
| 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.
| mooreds wrote:
| 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-...
| CalRobert wrote:
| 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).
| dizhn wrote:
| 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.
| fheisler wrote:
| 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 wrote:
| 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.
| gnaman wrote:
| 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
| dizhn wrote:
| 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 wrote:
| (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
| mooreds wrote:
| 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/#limita
| tions
| gnaman wrote:
| thank you I will check you guys out
| pm90 wrote:
| 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 wrote:
| 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 wrote:
| Keycloak is a great authentication suite, not that hard to
| configure and rock solid.
|
| Ill never understand this thinking.
| mmsc wrote:
| Keycloak has various vulnerabilities they haven't even
| responded to after a month of reporting them.
| nh2 wrote:
| Disclose publicly then, if you haven't already?
|
| Definitely makes things safer than users not knowing
| about them.
| dspillett wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| rozap wrote:
| Yea auth0 is an absolute clown show.
| tracker1 wrote:
| 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.
| cookiengineer wrote:
| Kind of funny that stalebots are the new "won't fix"
| methodology to ignore security issues with plausible
| deniability.
| c-hendricks wrote:
| Yeah I got a kick out of that. "We might have fixed your
| issue, if we didn't, open a new one because we took so long
| acknowledging this one".
| OptionOfT wrote:
| Or 3 years later: can you verify this is still needed.
|
| Why on earth did I spend time in creating a reproducible
| example?
| op00to wrote:
| People move on from issues. You apply a workaround, and
| the fix is no longer needed. Not every issue opened needs
| a fix. We all have limited resources, and prioritize the
| most important stuff to fix.
| cookiengineer wrote:
| A stalebot marks it as inactive because you didn't take
| 2mins of your time to write a thank you, it's been fixed
| with commit xyz.
|
| That's what the critique is about, lack of communication
| and lack of acknowledgement. Ghosting people when they
| took the time to file an issue/bug report, with providing
| a PoC and test case is just rude behavior.
| eddd-ddde wrote:
| "someone will look at this issue soon"
|
| (3 years later...)
| DetroitThrow wrote:
| Security companies that prioritize bugs being sold rather than be
| reported will eventually blow up. Good luck Okta shareholders.
| acessoproibido wrote:
| Unfortunately security is wayyyy down on the list of priorities
| for most large companies
| hypeatei wrote:
| I think GitHub should allow disabling PRs. I don't believe most
| big corporations are interested in dealing with fly-by
| contributions because it might make them look bad or be riddled
| with quality issues.
|
| Also some projects like the Linux kernel are just mirrors and
| would be better off with that functionality disabled.
| jchw wrote:
| While that is true, I feel like it is irrelevant here since it
| seems like Okta definitely wants (and perhaps _needs_ ) the
| fixes. God only knows why GitHub still forces it on though.
| Early on it might've been some mechanism to encourage people to
| accept contributions to push the social coding aspect, but at
| this point I have no idea who this benefits, it mostly confuses
| people when a project doesn't accept PRs.
| hypeatei wrote:
| > Okta definitely wants (and perhaps needs) the fixes
|
| They definitely don't want them if their process requires
| signed commits and their solution is 1) open another PR with
| the authors info then sign it for them, and 2) add AI into
| the mix because git is too hard I guess?
|
| No matter how you slice it, it doesn't seem like there are
| Okta employees who _want_ to be taking changes from third
| parties.
| jchw wrote:
| I think that they absolutely still want the free labor. All
| of those signals just suggest that they're not willing to
| reciprocate any effort that you put in when you contribute.
| petre wrote:
| Social on today's Internet = bots and occasionally trolls
| mananaysiempre wrote:
| GitHub actually can natively mark a repo as a mirror (or could?
| I can't find an example now, but they have always been rare).
| The book-with-bookmark icon before "user / repo" in the page
| header is replaced by a mirror-and-reflection-ish-looking
| thing, and the badge after it changes from "Public" to "Public
| mirror". Unfortunately, forcing you into "social coding" (wait,
| is that no longer on the homepage?) takes priority, so that
| mark can only be given out by GitHub staff through manual
| intervention, and it doesn't often happen.
| terminalbraid wrote:
| Maybe the community should use less of github if github doesn't
| provide features the community finds useful.
| jchw wrote:
| IANAL but unfortunately, I think the fix itself shown here might
| be too simple to actually clear the bar for copyright
| eligibility. (And in fairness to copyright law, it is basically
| the only sane way to fix this.) That means that there's probably
| not much you can really do, but I will say this looks fucking
| pathetic, Okta.
| rikafurude21 wrote:
| I'm more confused by the fact that the OP freely submits a PR
| into an open source repo but then wants to use "copyright"
| because the code he submitted ended up being used under the
| wrong name, which was then corrected.
| detaro wrote:
| Why is it confusing to you to expect attribution?
| rikafurude21 wrote:
| thats not the confusing part, its rather confusing to
| threaten to sue for copyright because of mistaken
| attirbution
| cyberpunk wrote:
| He even asked them to force-push a new history because
| they got the name wrong!
|
| Mistakes happen, I guess this hurts his 'commits in a
| public repo' cv score.
| abigail95 wrote:
| Mistaken attribution, or taking something that doesn't
| belong to you and saying it belongs to someone else is a
| core function of copyright law and should not be
| confusing to anyone who has dealt with it before.
|
| What is your understanding of what license and rights the
| author was providing them - understanding this I can
| figure out where you are confused.
| bananadonkey wrote:
| I didn't see any threat to sue. What's your source?
| jchw wrote:
| Licensing your code under open source licenses does not
| nullify your rights under copyright law, and the license in
| this case does not waive any rights to attribution.
|
| It would indeed be copyright violation to improperly
| attribute code changes. In this case I would absolutely say a
| force push is warranted, especially since most projects are
| leaning (potentially improperly) on Git metadata in order to
| fulfill legal obligations. (This project is MIT-licensed, but
| this is _particularly_ true of Apache-licensed projects,
| which have some obligations that are surprising to people
| today.) A force push is not the end of the world. You can
| still generally disallow it, but an egregious copyright
| mistake in recent history is a pretty good justification.
| That or, literally, revert and re-add the commit with correct
| attribution. If you really feel this is asking too much, can
| you please explain why you think it 's such a big problem? If
| it's such a pain, a good rule of thumb would be to not fuck
| this up regularly enough that it is a major concern when you
| have to break the glass.
| Yasuraka wrote:
| Okta is, if you may excuse my French, straight garbage.
| altairprime wrote:
| And too bad for everyone who was using their former competitor
| Auth0.
| torton wrote:
| I had a fairly fun time using Auth0 a few years back. The
| ability to run arbitrary code hooks at various points allowed
| us to do pretty interesting stuff in a managed way without
| resorting to writing or self-hosting something that was
| entirely flexible.
| sbmthakur wrote:
| Why if I may ask?
| Hnrobert42 wrote:
| It's a fair question. I found them way better to implement
| SSO in my small startup than OneLogin.
|
| Using Auth0 in apps, I find their documentation bafflingly
| difficult to read. It's not like being thrown in the deep end
| unexpected to swim. It's like being injected at the bottom of
| the deep end.God help the poor non-native English speakers on
| my team who have to slog through it.
| Yasuraka wrote:
| Security and safety is all over their marketing but I have
| yet to hear anything about them that doesn't indicate either
| bumbling incompetence or gross negligence.
| stronglikedan wrote:
| The fact that they have a "stay signed in" checkbox that
| doesn't keep me signed in tells me all I need to know about
| these jokers. I love going through a bloated login process
| multiple times a day, apparently.
| thewebguyd wrote:
| Microsoft/EntraID does this too. The famous "Keep me signed
| in" and "Don't show this message again" buttons that don't do
| what they say they do, ever.
|
| Maybe if enterprise sales decisions weren't made based on
| checklist and which account exec took them out on the best
| golf trip, we'd have better products.
| jjtheblunt wrote:
| Microsoft's EntraID "unsubscribe" functionality also
| doesn't do anything, evidently. The spam from them just
| keeps rolling in.
| rcleveng wrote:
| Honestly when I saw Okta in the headline, I had assumed the
| article was going to say they were breached again.
|
| This one is amusing, and as another comment mentioned below,
| large companies are _awful_ at accepting patches on github. Most
| use one-way sync tools to push from their internal repositories
| to github.
| Aldipower wrote:
| WTF is Okta?
| mananaysiempre wrote:
| An auth integrator, a pretty notable one, mostly (originally?)
| OAuth I think. Multiple people calling it a trash fire here
| came as a surprise to me, but I defer to their experience.
| trollbridge wrote:
| Okta was state of the art a decade ago.
| claaams wrote:
| People calling it trash and then recommending microsoft was
| an even bigger shock to the point where I am not convinced
| that those aren't microsoft AI bots astroturfing this post.
| pluralmonad wrote:
| Yeah, wasn't essentially every Azure resource wide open for
| exploitation until august of this year?
|
| https://dirkjanm.io/obtaining-global-admin-in-every-entra-
| id...
| mrweasel wrote:
| Basically an enterprise single sign on solution. We use it to
| allow staff to sign into pretty much any external service using
| Gsuite credentials.
| Traubenfuchs wrote:
| Is there any non shite managed oAuth solution with a free tier
| available?
|
| Auth0 really is super easy and comfortable to integrate and I
| don't want to run my own keycloak or whatever.
| trollbridge wrote:
| Authentik?
| Traubenfuchs wrote:
| > Replace Okta
|
| Aren't they cheeky!
|
| Thanks, I will try.
| theoldgreybeard wrote:
| You couldn't pay me a billion dollars to use Okta.
| pphysch wrote:
| Sadly many people will spend a million dollars to use Okta for
| their 10,000 logins/day (read: <1 tps) instead of running their
| own Keycloak or Authentik or whatever.
|
| OIDC is not scary, and advanced central authorization features
| (beyond group memberships) are a big ole YAGNI / complexity
| trap.
| trollbridge wrote:
| The workload to run Authentik locally is about identical to
| the workload to set up and configure Okta. (Or you could just
| fine someone who will host Authentik for you, if deploying a
| container is too hard for you.)
| p_ing wrote:
| Running your own local AuthN/AuthZ is more than just 'install
| it on a box in the closet'. I don't blame anyone for letting
| one of the giants do this on their behalf -- they have the
| expertise, though I agree I wouldn't touch Okta.
| pphysch wrote:
| For your average enterprise it really is that simple.
| Register some IDPs. Connect a backend. Add some clients
| over time.
|
| Yes, you need someone to wear the IAM admin hat. But once
| you get it configured and running it requires 0.1 FTE or
| less (likely identical to whatever your Okta admin would
| be). Not worth 6+ figures a year and exposure to Okta
| breach risk.
| p_ing wrote:
| No, it isn't "simple". Protecting your IdP is critical
| and not easy.
|
| Yes, creating a SAML integration is easy, but that's only
| one piece of the puzzle.
| pphysch wrote:
| Paying Azure a little bit to run an AD instance for you,
| IF you need to run your own IDP (a big if), is not a bad
| play and does not prevent you from saving lots of money
| by not using a dubious product like Okta.
| kondro wrote:
| Running your own AuthN/AuthZ with an off-the-shelf OSS is
| very straight-forward (as a SaaS product at least) and
| isn't any more burdensome from a security perspective than
| what you're already doing for your core service.
|
| This isn't email.
| p_ing wrote:
| Running Active Directory is as easy as it gets.
| Protecting the Golden Ticket is not.
| mrcwinn wrote:
| You just literally saved me one billion dollars. The offer was
| incoming!
| twodave wrote:
| I LOVE LLMs as a learning tool. I HATE LLMs as a communication
| tool. I know, there are people with serious handicaps who benefit
| from LLMs in this area. If only I could talk to those people and
| not wade through all this other garbage.
|
| Especially when the AI is being represented as a person, this to
| me is dishonest. Not to mention annoying, almost more-so than the
| number of different apps that think they are important enough to
| send me push notifications to fill out a survey (don't even get
| me started).
| whichquestion wrote:
| LLMs have definitely helped me reduce my social anxiety when
| writing, especially in a technical work setting. I don't use it
| like the respondent in the article though, I would feel really
| embarassed to not edit an llm's output to be in my own voice.
| But I feel it helps provide me with some structure in whatever
| I'm trying to write when I don't have the mental energy or
| wherewithal to provide it myself.
| RagnarD wrote:
| I've been quite happy with FusionAuth so far. Free to run on your
| own server, easy to understand and set up, easy to program
| against, reliable.
| wingmanjd wrote:
| We're another happy FusionAuth customer. We started with self-
| hosted but just moved to their hosted option this year.
| filearts wrote:
| I think it is distasteful and disrespectful to call out an
| employee by name in this way, regardless of the merit of the rest
| of the OP's post.
| iloveplants wrote:
| well, it was distasteful of to them to close op's pr and apply
| the same patch with improper attribution, and then use ai to
| respond when they were asked about it
| atonse wrote:
| I agree with the parent post that it's distasteful.
|
| There's no value in naming the employee. Whatever that
| employee did, if the company needed to figure out who it was,
| they can from the commit hashes, etc. But there's no value in
| the public knowing the employee's name.
|
| Remember that if someone Googles this person for a newer job,
| it might show up. This is the sort of stuff that can
| disproportionately harm that person's ability to get a job in
| the future, even if they made a small mistake (they even
| apologized for it and was open about what caused it).
|
| So no, it's completely unnecessary and irrelevant to the
| post.
| Exoristos wrote:
| > This is the sort of stuff that can disproportionately
| harm that person's ability to get a job in the future.
|
| Isn't that beneficial in this case?
| Freak_NL wrote:
| > Remember that if someone Googles this person for a newer
| job, it might show up.
|
| Not to sound too harsh, but this is a person who rudely let
| AI perform a task badly which should have been handled by
| just... merging/rebasing the PR after confirming it does
| what it should do, _then_ couldn 't be bothered to reply
| and instead let the robot handle it, and _then_ refused to
| fix the mess they made (making the apology void).
|
| That's three strikes.
| abraae wrote:
| What if it's some junior given a job beyond their
| abilities, and struggling manfully using whatever tools
| they have to hand. Is it worth publicly trashing their
| name? What does their name really add to this article?
| jabwd wrote:
| A good lesson. If you as an employer look at this
| history, and handle it in the interview appropriately
| (what did you learn / do better now for example) you can
| figure out if they did.
|
| I'm sure lots won't, but if that is you as an employer
| you're worth nothing.
| WesolyKubeczek wrote:
| What, understand, review, and accept a two-line patch is
| now a job beyond a junior's ability? Beyond ability of
| anyone who can call themselves a "programmer," much less
| a "maintainer"?
|
| As a certified former newborn, I should tell that finding
| the tit as a newborn is way harder, and yet here we all
| are.
|
| "Struggling manfully," my arse, I don't know if the bar
| can go any lower...
| 63stack wrote:
| It discourages other from doing the same. It might not be
| much, but discussing various made up "what if ..."
| scenarios also doesn't add much. We can just stick to the
| facts.
| technion wrote:
| I agree what occurred is quite egregious. But "use ai to
| talk to customers" and "play games with signed commits"
| sound much more like corporate policy than one employees
| mistake.
| claaams wrote:
| There also might be some corpo dystopian policy that is
| forcing them to use AI to do this task.
| philipallstar wrote:
| > That's three strikes.
|
| No, it's one strike, and you don't get to decide how many
| strikes because who the hell are you?
| parliament32 wrote:
| > Remember that if someone Googles this person for a newer
| job, it might show up.
|
| That's the whole point; I sincerely hope it does. Why would
| anyone want to hire someone that delegates their core job
| to a slop generator?
| mmsc wrote:
| Why would the company need to figure it out from commit
| hashes? It's all public, in public GitHub repositories,
| with the person's personal GitHub account:
| https://github.com/auth0/nextjs-auth0/pull/2381
| DrammBA wrote:
| I don't think it is distasteful or disrespectful, he's just
| explaining what happened and why, and he's obviously unhappy
| with the whole ordeal.
| merrvk wrote:
| They maintain a public repo.
| nstart wrote:
| Yea. I can see what the parent is getting at. However the
| linked PR's contain the employee name. Their username is the
| same name mentioned in the article. So it would have been the
| same even if the author had just mentioned the username
| instead (which would be completely acceptable in all cases).
| I think junior employee or not, it's clear that they have the
| autonomy to check a PR for errors and fix it. So it's very
| much on them.
| mmsc wrote:
| (op here)
|
| On the one hand, you're right, it is distasteful, I completely
| agree. On the other hand, GitHub and Google and the public
| domain internet isn't everybody's CV that they can pick and
| choose which of their actions are publicised, tailored towards
| only their successes.
| abigail95 wrote:
| How can it ever be disrespectful to publish truthful
| information about someone.
|
| What does respect mean and how was it violated by this post?
|
| I think you are far outside the mainstream of journalism norms
| and ethics and as such should bear the burden of explaining
| yourself further.
|
| I think you're the one being disrespectful.
| claaams wrote:
| Absolutely agree with this. There could be many, many reasons
| out of the named person's control, and that the author is not
| aware of, as to why this happened. It comes off as petty and
| arrogant and honestly the same attitude I expect from most
| people on hackernews. Overall its disappointing. Respect each
| others privacy.
| avree wrote:
| FWIW, the employee reply (who the author is putting on blast)
| seems like it was written by a human, not an AI.
|
| "You're absolutely right!" is the Claude cliche (not a ChatGPT
| one) - "You are absolutely correct." is not that.
| DrammBA wrote:
| Directly from the employee (tusharpandey13) in the github PR:
|
| > Yeah, i had to manually stop it and delete the ai-generated
| comment.
| DrammBA wrote:
| I find it funny that this seemingly fictitious person Simen A. W.
| Olsen my@simen.io will forever be engraved as a co-author of a
| one-line change in the nextjs-auth0 repo.
| letmetweakit wrote:
| https://who.is/whois/simen.io
|
| He's not fictitious I think.
| syncsynchalt wrote:
| Simen Olsen is not fictitious, but the "my@" email/username
| seems to be. Zero hits on DDG, and only this article comes up
| in Google Search.
| verdverm wrote:
| Search has become so bad that zero hits is not the
| indicator it used to be, even DDG is struggling now.
|
| It's really evident in situations like this where you are
| looking for something specific. Seems like they all pushed
| too hard on the AI and the results are for averaged search
| queries. Using quotes and -term have become less helpful
|
| Conspiratorially, I wonder if this is intentional to drive
| more traffic to ai. I find myself using Google Deep Search
| more, which is honestly a better UX if it would stop
| writing damn reports and just give me a brief with links.
| Alas it ignores any instructions to change it's output
| format
| merrvk wrote:
| That maintainer seems clueless
| fudged71 wrote:
| I'm currently building on the Auth0 SaaStarter because it seemed
| to be the only option in the market for something with all the
| core features enterprises are looking for. Is there an
| alternative that doesn't require building from scratch?
| deepsun wrote:
| Okta requiring to create a video for a pretty obvious
| vulnerability shows that Okta does not take security seriously,
| contrary to what they say at their earnings calls. Sounds like
| deceiving their investors.
| burnt-resistor wrote:
| Don't outsource SSO to any IdMaaS. It's too critical. And
| especially not to Okta.
| glemmaPaul wrote:
| Anyone that uses Okta should be accepting the fact that they have
| outsourced a huge chunk of responsibility of their job onto an
| enterprise company.
|
| These github links are not open source projects, these are public
| readable software projects. You do not control any of it, you
| have to deal with internal company politics like "# PRs opened",
| "# Bugs solved" for the developers' next performance review.
| sintax wrote:
| What do you expect? This is the same company suggesting people to
| turn off DNS Rebind protection to work around their incompetence
| (https://support.okta.com/help/s/article/dns-rebind-protectio...)
| rckt wrote:
| AI enabled engineers.
|
| Dammit, things like this trigger a very strong rejection of
| actively adopting AI into my workflows. Not the AI tooling
| itself, but the absolutely irresponsible ways of using it. This
| is insane.
| donalhunt wrote:
| Seems the perfect opportunity to create a AI-generated "hackers"
| short with some prepared screenshots. /s
| ovo101 wrote:
| What's frustrating here is how predictable these issues are.
| Next.js isn't some niche framework, yet Okta's SDK still
| struggles with basic OAuth flows like redirect handling, cookie
| persistence, and SSR quirks. That's not just a bug -- it's a sign
| of weak integration testing.
|
| The bigger problem is trust. If an identity provider can't
| reliably support mainstream frameworks, it undermines confidence
| in their entire platform. Developers end up spending more time
| debugging the SDK than building features.
|
| This is why many of us lean toward smaller, well-maintained
| libraries (Auth.js, Supabase Auth, etc.). They don't try to
| abstract away everything, but they do the fundamentals well --
| and that's what matters most in security.
| phendrenad2 wrote:
| I'm shocked. Where are all the "SSO companies handle edge cases
| you can't even imagine" people? It's been 24 hours.
| acessoproibido wrote:
| If SSO were so easy to solve we wouldn't have a gazillion
| companies for it. It's probably easy enough if you are a really
| good engineer, but like 90% working in this industry aren't.
| Also you ever implemented OAuth2 or _shudder_ SAML? Not how I
| would like to spend the one life I have been given.
| roncesvalles wrote:
| I've been (trying) to use Auth0 over the last few weeks, just as
| a PoC / "base" app scaffold.
|
| My conclusion has been: for social and email login, you don't
| need things like Auth0. Just write it yourself.
|
| You need: session management, account management (you'd already
| have this), and some simple social login pathways (PKCE etc). If
| you're an experienced engineer and take the time to do it
| properly, it's totally fine to "roll your own auth". Things like
| Auth0 and Firebase Auth are built for nobody and make life more
| difficult.
|
| Any SaaS service that saves you like <40 hours of implementation
| work is not worth buying into. Just put in the hours and you're
| set for life. It'll probably take you that many hours to wrangle
| with integrating it anyway (and when things get serious, you'll
| need to figure it out down to the bone anyway; auth is not
| something you can just plop in like a blackbox and forget about
| it). And if in the process of rolling it yourself you realize "oh
| shit the service is actually lifting a lot for me", then the time
| you spent on learning that lesson was also worth it and made you
| a better engineer.
|
| Basically, don't cargo-cult things just because everyone says you
| should. You should feel the "aha" for why you need to introduce a
| 3rd party thing.
___________________________________________________________________
(page generated 2025-11-21 23:02 UTC)