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.
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.
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.
(3 years later...)
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.
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.
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.
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.
OIDC is not scary, and advanced central authorization features (beyond group memberships) are a big ole YAGNI / complexity trap.
He's not fictitious I think.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
"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.
