Okta's NextJS-0auth troubles
322 points
3 days ago
| 21 comments
| joshua.hu
| HN
cedws
2 days ago
[-]
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
reply
cookiengineer
13 hours ago
[-]
Kind of funny that stalebots are the new "won't fix" methodology to ignore security issues with plausible deniability.
reply
c-hendricks
12 hours ago
[-]
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".
reply
OptionOfT
9 hours ago
[-]
Or 3 years later: can you verify this is still needed.

Why on earth did I spend time in creating a reproducible example?

reply
jonathaneunice
17 hours ago
[-]
> 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.

reply
parliament32
17 hours 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.
reply
kenhwang
17 hours 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.
reply
ecshafer
9 hours 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.
reply
CalRobert
1 hour 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.
reply
lq9AJ8yrfs
13 hours 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.

reply
ecshafer
9 hours ago
[-]
Keycloak is a great authentication suite, not that hard to configure and rock solid.

Ill never understand this thinking.

reply
solatic
5 hours 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.

reply
mmsc
8 hours ago
[-]
Keycloak has various vulnerabilities they haven't even responded to after a month of reporting them.
reply
dspillett
1 hour 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.
reply
nh2
7 hours ago
[-]
Disclose publicly then, if you haven't already?

Definitely makes things safer than users not knowing about them.

reply
Y_Y
16 hours 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.
reply
swiftcoder
15 hours 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...)
reply
shakna
3 hours ago
[-]
> 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...

reply
inkyoto
9 hours 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.

reply
shakna
3 hours ago
[-]
Apart from auth0 getting hacked, before getting acquired by Okta. [0]

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

reply
inkyoto
3 hours ago
[-]
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.

reply
hexbin010
5 hours 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
reply
inkyoto
2 hours 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.

reply
SAI_Peregrinus
16 hours ago
[-]
Yep. They're an Enterprise™ company. That means they prioritize features purchasing departments want, not functionality.
reply
viraptor
52 minutes ago
[-]
And when something doesn't work well like their super custom LDAP endpoint, talking to support is really painful.
reply
hi_hi
15 hours 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?
reply
dizhn
1 hour ago
[-]
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.

reply
CalRobert
1 hour ago
[-]
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).

reply
mooreds
13 hours ago
[-]
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-...

reply
Exoristos
15 hours ago
[-]
It's not difficult to implement OAuth2. There are good libraries, and even the spec is not complicated. Or use AWS Cognito.
reply
inkyoto
7 hours 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-e...

reply
Exoristos
5 hours ago
[-]
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.
reply
porker
5 hours ago
[-]
It's an AI bot. One for @dang
reply
inkyoto
4 hours ago
[-]
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.
reply
inkyoto
3 hours ago
[-]
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.

reply
grinich
13 hours ago
[-]
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
reply
catlifeonmars
10 hours ago
[-]
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.
reply
pm90
13 hours 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.
reply
rozap
7 hours ago
[-]
Yea auth0 is an absolute clown show.
reply
Yasuraka
17 hours ago
[-]
Okta is, if you may excuse my French, straight garbage.
reply
altairprime
17 hours ago
[-]
And too bad for everyone who was using their former competitor Auth0.
reply
torton
9 hours ago
[-]
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.
reply
sbmthakur
17 hours ago
[-]
Why if I may ask?
reply
Yasuraka
6 hours ago
[-]
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.
reply
Hnrobert42
11 hours ago
[-]
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.

reply
glemmaPaul
4 hours ago
[-]
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.

reply
sintax
2 hours ago
[-]
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...)
reply
hypeatei
17 hours ago
[-]
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.

reply
jchw
17 hours ago
[-]
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.
reply
hypeatei
17 hours ago
[-]
> 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.

reply
jchw
12 hours ago
[-]
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.
reply
petre
17 hours ago
[-]
Social on today's Internet = bots and occasionally trolls
reply
mananaysiempre
17 hours ago
[-]
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.
reply
terminalbraid
15 hours ago
[-]
Maybe the community should use less of github if github doesn't provide features the community finds useful.
reply
theoldgreybeard
17 hours ago
[-]
You couldn't pay me a billion dollars to use Okta.
reply
pphysch
17 hours ago
[-]
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.

reply
p_ing
16 hours ago
[-]
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.
reply
kondro
11 hours ago
[-]
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.

reply
p_ing
11 hours ago
[-]
Running Active Directory is as easy as it gets. Protecting the Golden Ticket is not.
reply
pphysch
15 hours ago
[-]
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.

reply
p_ing
12 hours ago
[-]
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.

reply
pphysch
11 hours ago
[-]
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.
reply
trollbridge
16 hours ago
[-]
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.)
reply
mrcwinn
17 hours ago
[-]
You just literally saved me one billion dollars. The offer was incoming!
reply
DrammBA
15 hours ago
[-]
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.
reply
letmetweakit
14 hours ago
[-]
https://who.is/whois/simen.io

He's not fictitious I think.

reply
syncsynchalt
11 hours ago
[-]
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.
reply
verdverm
5 hours ago
[-]
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

reply
deepsun
12 hours ago
[-]
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.
reply
filearts
16 hours ago
[-]
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.
reply
iloveplants
16 hours ago
[-]
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
reply
atonse
15 hours ago
[-]
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.

reply
Freak_NL
14 hours ago
[-]
> 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.

reply
abraae
14 hours ago
[-]
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?
reply
63stack
1 hour ago
[-]
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.
reply
jabwd
9 hours ago
[-]
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.

reply
WesolyKubeczek
3 hours ago
[-]
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...

reply
technion
14 hours ago
[-]
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.
reply
claaams
4 hours ago
[-]
There also might be some corpo dystopian policy that is forcing them to use AI to do this task.
reply
mmsc
10 hours ago
[-]
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
reply
Exoristos
15 hours ago
[-]
> 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?

reply
parliament32
14 hours ago
[-]
> 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?

reply
mmsc
10 hours ago
[-]
(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.

reply
abigail95
8 hours ago
[-]
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.

reply
DrammBA
15 hours ago
[-]
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.
reply
merrvk
14 hours ago
[-]
They maintain a public repo.
reply
nstart
11 hours ago
[-]
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.
reply
rcleveng
17 hours ago
[-]
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.

reply
RagnarD
17 hours ago
[-]
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.
reply
wingmanjd
15 hours ago
[-]
We're another happy FusionAuth customer. We started with self-hosted but just moved to their hosted option this year.
reply
fudged71
14 hours ago
[-]
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?
reply
dovys
2 days ago
[-]
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?
reply
manithree
14 hours ago
[-]
reply
mmsc
10 hours ago
[-]
Same author, even!;)
reply
jchw
17 hours ago
[-]
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.
reply
rikafurude21
17 hours ago
[-]
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.
reply
jchw
12 hours ago
[-]
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.

reply
detaro
17 hours ago
[-]
Why is it confusing to you to expect attribution?
reply
rikafurude21
17 hours ago
[-]
thats not the confusing part, its rather confusing to threaten to sue for copyright because of mistaken attirbution
reply
abigail95
8 hours ago
[-]
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.

reply
cyberpunk
15 hours ago
[-]
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.

reply
bananadonkey
7 hours ago
[-]
I didn't see any threat to sue. What's your source?
reply
merrvk
14 hours ago
[-]
That maintainer seems clueless
reply
burnt-resistor
9 hours ago
[-]
Don't outsource SSO to any IdMaaS. It's too critical. And especially not to Okta.
reply
twodave
17 hours ago
[-]
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).

reply
whichquestion
16 hours ago
[-]
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.
reply
Traubenfuchs
17 hours ago
[-]
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.

reply
trollbridge
16 hours ago
[-]
Authentik?
reply
Traubenfuchs
16 hours ago
[-]
> Replace Okta

Aren't they cheeky!

Thanks, I will try.

reply
DetroitThrow
18 hours ago
[-]
Security companies that prioritize bugs being sold rather than be reported will eventually blow up. Good luck Okta shareholders.
reply
Aldipower
17 hours ago
[-]
WTF is Okta?
reply
mrweasel
15 hours ago
[-]
Basically an enterprise single sign on solution. We use it to allow staff to sign into pretty much any external service using Gsuite credentials.
reply
mananaysiempre
17 hours ago
[-]
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.
reply
claaams
4 hours ago
[-]
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.
reply
trollbridge
16 hours ago
[-]
Okta was state of the art a decade ago.
reply
avree
15 hours ago
[-]
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.

reply
DrammBA
15 hours ago
[-]
Directly from the employee (tusharpandey13) in the github PR:

> Yeah, i had to manually stop it and delete the ai-generated comment.

reply