I hope this gives rise to another, smaller viable party outside of Amazon, Google, and Microsoft. Perhaps I'm jaded, perhaps hopelessly biased - but I can only see this as a net negative.<p>Okta's open source packages receive a pitiful amount of attention (for example: <a href="https://github.com/okta/okta-oidc-js/issues?q=is%3Aissue+is%3Aopen+typescript" rel="nofollow">https://github.com/okta/okta-oidc-js/issues?q=is%3Aissue+is%...</a>) with forks almost becoming a requirement. Auth0 by contrast has been "on the ball" for a long time with their offerings. Okta's interfaces have been disjointed and inconsistent, confusing to users on a scale only surpassed by Jira, while Auth0's have always been pleasant to use from a user and developer perspective.<p>From a personnel perspective, the two companies couldn't be more different, with Auth0 embracing a remote-first-class culture with creative interview processes, and Okta (pre-covid) being very much the opposite. I interviewed with both, and the process at Auth0 had me walk away with respect, while contrasted with Okta that left me reminded that tech hiring is broken.<p>I'll hold my breath for a short time that Auth0 is allowed to operate independently. Sadly I feel it'll be inevitable that they're eventually swallowed up by the mothership.
I hate this. We moved from Okta a few years ago after we were basically received almost no actual real support for a bunch of issues, even though we were paying a premium cost. Nobody cares about issues on their Github, the kicker was a when we received a support response as suddenly something was no longer working after an update, we got help in the form of "We have no plans to address this anytime soon." when asking for an ETA.<p>We ended up switching to Auth0, after we had a few calls with them. We shaved a decent amount off our costs with Auth0's Enterprise plan, and their webtask based rules worked. While the migration sucked for a bit, in the end we were much happier.
Really not a fan of this.<p>Okta as a business are a pain to deal with, and unless you meet their minimum spend requirements (which are not told to you up-front) you're screwed.<p>I've rolled out a ton of commercial products where we started with 1-2 users or a few units of compute, and on the basic little/no support options.<p>When those products succeed, and we can demonstrate that not only does it meet our needs on paper, but it actually works, and whatever flaws that exist are not big enough to stop us wanting to use it more.<p>AWS, Atlassian's Jira and Confluence, Sendgrid, Mailchip, Duo, and a bunch of others all started being used in orgs where this kind of thing is super low friction and easy to spin up, we plug in a credit card to get us off the ground.<p>Okta? Well they'll tell you the pricing up-front, that's great - what they don't tell you is that after the trial period, you can't just give them a credit card, no you need to go through the sales process. It's not until you're talking to their salesperson that you find out you can't just start with a few licenses, no, you need to meet their minimum spend figure per month.<p>Well, that idea was dead.
> and integrated over time<p>I'm reading too much into this sentence fragment and it fills me with fear.<p>I smell breaking domain changes in the future. They can't allow the .auth0.com tenants to operate as-is forever, which means existing tenants will get grandfathered in and eventually forced off the .auth0.com domain onto okta's domains.<p>I smell messy login sites in the future. I like Auth0's implementation of their Universal Login page, which didn't require JavaScript. In the quest for 'one single brand identity' someone will force a migration to Okta's login implementation instead.<p>That will come with changing client IDs, client secrets, M2Ms and everything else needed in their setup.<p>I might as well create a Jira ticket for this now.
Wow. These guys were basically 1 and 2 when it comes to enterprise auth/CIAM. It's great news for the businesses, but will likely only decrease competition in the marketplace. There's a ton of second tier competitors out there with plausible offerings who are probably going to start consolidating to stay alive.
Centralized services gonna centralize.<p>Something I've been thinking about recently is that a full web browser is a hard dependency of OAuth2-based systems. That's 20-30 million lines of code even for the simplest systems, even though you're basically just using the browser as a form renderer and a central space to store tokens.<p>I feel like there's room for a simpler protocol designed to operate on HTTP plus a minimal UI language (maybe JSON-based) used to describe forms for granting access. This would make it much easier to develop for devices that don't have browsers. You could even make CLI interfaces for authorization flows.
Oof, I really like Auth0 and was thinking of adopting them soon. Now it just seems like a huge risk. Why would I willfully walk into what will obviously be a migration nightmare and unknown pricing change for one of the central and critical pieces of my application (which should be boring to maintain)?<p>Best to Auth0! I really hope you can maintain your company culture and excellence, but I can't risk my business on that now.
If anyone's looking for an Auth0 alternative, come check out WorkOS!<p>It's like Stripe for enterprise features, including SSO/SAML, Directory/SCIM, and more.<p><a href="https://workos.com/docs" rel="nofollow">https://workos.com/docs</a><p>(I'm the founder.)<p>Edit: Here’s our launch last year: <a href="https://news.ycombinator.com/item?id=22607402" rel="nofollow">https://news.ycombinator.com/item?id=22607402</a>
There's something about Okta that just scares me. If Okta is ever compromised, so are the thousands of companies that rely on it for IdP. How do companies mitigate this risk? Or do they?
We are building a cloud-native IAM over here <a href="https://github.com/caos/zitadel" rel="nofollow">https://github.com/caos/zitadel</a><p>It is written in Go and built around event sourcing for a great audit trail. We already support OIDC, Passwordless, RBAC and working on more features each day.<p>For those who want to run it on-prem we have a kubernetes operator ready in the next few weeks who also manages the database (cockroach).<p>We run our own service here <a href="https://zitadel.ch" rel="nofollow">https://zitadel.ch</a> with a free tier as well<p>Feel free to engage with us on GitHub discussions.
Full details are in the investor release [1]<p>[1] <a href="https://investor.okta.com/static-files/83f1811e-2f92-4c08-a16d-76cae00f1255" rel="nofollow">https://investor.okta.com/static-files/83f1811e-2f92-4c08-a1...</a>
More information on the ppt<p>Auth0<p>200M ARR<p>50% Growth<p>120%+ Net Retention Rate<p><a href="https://investor.okta.com/static-files/83f1811e-2f92-4c08-a16d-76cae00f1255" rel="nofollow">https://investor.okta.com/static-files/83f1811e-2f92-4c08-a1...</a><p>What a great acquisition. Congrats to both teams!
> <i>Okta, whose cloud software allows office workers to access all of their apps through a secure online service, said on Wednesday that it’s spending $6.5 billion to acquire rival Auth0. Okta’s shares plunged about 13% in extended trading after the announcement.</i><p>Huh? Generally speaking, companies acquire other companies to become <i>more</i> valuable, not for their shares to go <i>down</i>. And even more so when the acquired company is a <i>competitor</i>.<p>Why do investors think this is such a backwards idea, and why did the board approve an acquisition that investors appear to be rejecting?<p>This is extremely unusual and the article provides zero explanation whatsoever.
We use Okta for a bunch of stuff and I do really love their product. My company did two rounds of evaluation and really loved Auth0 but their product was unfortunately too opinionated about some things which made it difficult to adopt.<p>I don't know what this means regarding costs but for my place of business we saved money versus hiring people to operate/maintain the system.
I only hope and pray that Auth0 doesn't give up on their attention to documentation, examples, and just making it easy to get going with their ecosystem.<p>It took me a couple of hours to get a Spring Boot application to use Auth0 as an IDP and for ID federation to AzureAD, Google, Apple, and a few other IDPs. The documentation and examples are very comprehensive, and I like how they really get the day to day problems faced by developers.<p>Getting anything working with Okta on the other hand took ages longer, to the point that we gave up on them to move to Auth0.<p>In all, this acquisition is bittersweet for me.
Oh man. Was planning on using Auth0. Never heard of Okta, but reading the comments in here has confirmed my suspicion of the company's core value. Now I'm having doubts.
We're using WorkOS to build Directory/SCIM and are very happy with it. They have a really good API for syncing enterprise directories (G Suite, Okta, SCIM, Azuer, etc.) and webhooks to get changes.<p>It's easy enough to use even for internal applications, but we're using it to integrate customer directories with our product.<p>We're also using it to do SSO for our product. It's much easier than trying to integrate with each of these systems.
I might be mad but auth0 really for $6.5bn, seems like a pretty simple problem solved in a quite mediocre way. I mean the common use case of an app+api+website login seems excruciatingly difficult to setup, surely something that did this by default and didn’t need configuration unless breaking out of this model would be preferable to the weirdness I’ve had on the 3/4 occasions I’ve set it up now.
Good for Okta and, potentially, for Auth0. But, most likely, not so good for current Auth0 users and future IdM users. I believe that decreased competition due to industry consolidation is not a good thing. I would rather see Auth0 choosing the IPO (or direct listing) route for an "exit" ...
Urghh.. and to think I got rejected the season before Auth0 got accepted for exactly the same idea. Anyone have any tips on actually getting noticed at YC? Didnt even get past video pitch :/
If anyone is looking for an alternative on the opposite end of the scale from enterprise, to add login to an MVP in a few days, I have been collecting newer services that go beyond passwords and Sign in with Google:<p>Feather: <a href="https://feather.id" rel="nofollow">https://feather.id</a><p>Magic: <a href="https://magic.link" rel="nofollow">https://magic.link</a><p>Cotter: <a href="https://www.cotter.app" rel="nofollow">https://www.cotter.app</a>
Does anyone else think its a horrible idea to outsource your companies authentication?<p>Where I work we are migrating to Okta, and it blows my mind that anyone thinks it is a good idea.
Tragic. All Auth options are horrible and overpriced. From a presentation I did for a client a year ago for only 10,000 users:<p>Off-the-shelf auth cost comparison
• Okta: $20,000 / month
• Auth0: $1,500+ / month
• These are barebones services - any customization would cost extra
• There is still a large implementation code when using these services<p>Auth0 was worth using for midsize companies sometimes. Okta is not.
As just another average Joe/Jane, what can I do to influence anti-trust department that this merger is a bad idea for competition? It really does surprise me how many mergers are done purely for market capture reasons. The US Tech industry has a few bully behemoths who keep on getting bigger and a ton of smaller players.
Oh my, I hope the Auth0 free tier doesn't change because I just built out an integration with them for a project. Oh well, the end game was always to build my own auth, just... later, because it's such an annoying mountain of work.
I am honestly not aware of either companies. From the outside looking in, the business model appears to be selling X as a service covered in buzz words. I mean enterprises check the box on these requirements. Now Hashicorp, they excite me.
What are the most popular services that companies are paying for from these providers? I've built a lot of authentication and authorization technology, open sourcing very little so far.
How does one migrate your users away from Auth0 seamlessly as possible (when you’re using their Database connection)?<p>I seem to recall something about raising a ticket for an export including the hashes?
I wonder why the stock tanker after this is announced. From what I see they are the top 2 players in this space and so an acquisition should be good for business.
If anyone's looking for an Auth0 alternative, definitely check out: <a href="https://magic.link/" rel="nofollow">https://magic.link/</a> - easy plug-n-play auth, friendly-pricing for startups<p>CEO here, ask me any questions!
We changed the URL from <a href="https://www.okta.com/press-room/press-releases/okta-signs-agreement-to-acquire-auth0/" rel="nofollow">https://www.okta.com/press-room/press-releases/okta-signs-ag...</a> to a third-party article. Usually though not always, corporate press releases are tepid devices whose purpose is as much <i>not</i> to say things as to say them, or at least not say them outright. So generally we prefer the best third-party article on a topic.<p><a href="https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=corporate%20press%20release%20by:dang" rel="nofollow">https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...</a><p>(Cases like this are an exception to the 'original source' rule in <a href="https://news.ycombinator.com/newsguidelines.html" rel="nofollow">https://news.ycombinator.com/newsguidelines.html</a>.)
Congratulations to the entire Auth0 team. I admire their strategy on selling comprehensive auth/CIAM solution to the developer teams from all around the world!
If anyone's looking for an Auth0 alternative, come check out FusionAuth!<p>It's been built from the ground up for developer experience with a distinct lack of jargon, amazing customizability, an API first approach and great docs. Plus, enterprise features too, including SSO/SAML, OIDC, and more.<p><a href="https://fusionauth.io/docs/" rel="nofollow">https://fusionauth.io/docs/</a><p>(I work at FusionAuth.)