Okta's NextJS-0auth troubles
Mood
controversial
Sentiment
negative
Category
tech_discussion
Key topics
Security
Oauth
Nextjs
Okta
Discussion Activity
Very active discussionFirst comment
3h
Peak period
101
Day 3
Avg / period
51.5
Based on 103 loaded comments
Key moments
- 01Story posted
Nov 18, 2025 at 5:17 AM EST
5d ago
Step 01 - 02First comment
Nov 18, 2025 at 8:22 AM EST
3h after posting
Step 02 - 03Peak activity
101 comments in Day 3
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 21, 2025 at 2:35 AM EST
3d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
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.
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.
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...
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-...
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.
Ill never understand this thinking.
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.
Why on earth did I spend time in creating a reproducible example?
Also some projects like the Linux kernel are just mirrors and would be better off with that functionality disabled.
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.
What is your understanding of what license and rights the author was providing them - understanding this I can figure out where you are confused.
Mistakes happen, I guess this hurts his 'commits in a public repo' cv score.
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.
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.
Auth0 really is super easy and comfortable to integrate and I don‘t want to run my own keycloak or whatever.
Aren't they cheeky!
Thanks, I will try.
OIDC is not scary, and advanced central authorization features (beyond group memberships) are a big ole YAGNI / complexity trap.
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.
Yes, creating a SAML integration is easy, but that's only one piece of the puzzle.
This isn't email.
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).
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.
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.
I'm sure lots won't, but if that is you as an employer you're worth nothing.
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?
Isn't that beneficial in this case?
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.
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.
"You're absolutely right!" is the Claude cliche (not a ChatGPT one) - "You are absolutely correct." is not that.
> Yeah, i had to manually stop it and delete the ai-generated comment.
He's not fictitious I think.
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
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.
Auth0 clearly has resource misallocation issues. I'd stay clear from them.
46 more comments available on Hacker News
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.