The reason Okta spent $6.5B on Auth0(supertokens.io)
supertokens.io
The reason Okta spent $6.5B on Auth0
https://supertokens.io/blog/the-real-reason-okta-spent-on-auth0
156 comments
Or "monopolistic price gouging" is a dysphemism for having a stable business in a tough market. They need to make enough profit to avoid capital outflow.
Buying a competitor is always a dubious move towards monopoly. If the ideal free market is supposed to have all sorts of advantages, then anything which reduces the ideal-ness of the actual market must be viewed as negative.
Seems like I should have better explained why the logic doesn't hold. Even if we grant that an ideal market is a good thing (which is debatable), it's still not certain that all motion towards an ideal market is positive good. The space through which one moves may not be monotonically increasing in the goodness direction.
No, that logic doesn't hold. Further, I think you're conflating two meanings of the word ideal. In the context of an ideal free market, the meaning is closer to hypothetical and is pretty far away from the sense of ethical or practical goodness. Also, it's not clear that an "ideal" free market is a stable equilibrium. And lastly, if an ideal free market permits the existence of corporations (I'm not sure that it does) then it must allow one to purchase another.
Except now they have to make an extra half billion a year just to justify spending the money instead of putting it into a more liquid investment. Or themselves.
Luckily, we have alternatives, so their pricing shenanigans can only push people so far. For example, Keycloak is some self-hosted open source software which is a drop-in replacement for any Oauth2/OpenID Connect service. It doesn't get you a nice applications panel like Okta does, but it's a workable alternative. Given what I spend on Okta, prices doubling would put me on the fence, and tripling would move me to an alternative.
I do use both - Okta for internal users, and Auth0 for customer accounts, and I'm bummed that the quick and easy (Auth0) is being subsumed by the stuffy enterprise company.
I do use both - Okta for internal users, and Auth0 for customer accounts, and I'm bummed that the quick and easy (Auth0) is being subsumed by the stuffy enterprise company.
The Economist response is that Okta just rewarded their competition with $6.5B.
This is a serious incentive for anyone to launch a new company in the field.
This is a serious incentive for anyone to launch a new company in the field.
I have been beating the drum for a straightforward hardware key-based identity system for 5-50 users here for years.
And, yet, everything is still a pain in the ass.
We were looking at Auth0 precisely because Okta was doing the enterprisy thing. Sigh.
And, yet, everything is still a pain in the ass.
We were looking at Auth0 precisely because Okta was doing the enterprisy thing. Sigh.
What's wrong with Yubikey?
The keys are fine.
The system the keys are a part of, not so much.
I want to hand anybody in my company 3 keys each (normal, backup, and emergency) and I want them to log into everything with those keys.
This is so mind-bendingly difficult to implement that I simply give up every time I try.
After you kill yourself putting it all together, you can generally make logging in with the keys sorta work. And then you have to cancel and replace a key that somebody lost.
And then you realize all the corner edge cases that don't work.
Or, somebody leaves your company and they're the administrator for something on GitHub and now you can't transfer it without their help. And, if you've destroyed the keys, you're shit out of luck.
Anything to do with keys is second-class relative to the password flow because that's what everybody uses.
The system the keys are a part of, not so much.
I want to hand anybody in my company 3 keys each (normal, backup, and emergency) and I want them to log into everything with those keys.
This is so mind-bendingly difficult to implement that I simply give up every time I try.
After you kill yourself putting it all together, you can generally make logging in with the keys sorta work. And then you have to cancel and replace a key that somebody lost.
And then you realize all the corner edge cases that don't work.
Or, somebody leaves your company and they're the administrator for something on GitHub and now you can't transfer it without their help. And, if you've destroyed the keys, you're shit out of luck.
Anything to do with keys is second-class relative to the password flow because that's what everybody uses.
Like WebAuthn?
Shameless plug - We are doing this at WorkOS. :)
It's like Stripe for enterprise features, including SSO/SAML, Directory/SCIM, and more.
https://workos.com/docs
It's like Stripe for enterprise features, including SSO/SAML, Directory/SCIM, and more.
https://workos.com/docs
Wow this looks really useful. Thanks for posting!
Have you looked at adding 2FA that isn't email eg Google Authenticator etc. We're seeing lately that enterprise customers aren't interested in email 2FA.
Yes, it's coming. Both SMS and authenticator apps (including TOTP via scanning QR-codes).
Here's an overview of our approach and technical demo for how the integration will work: https://www.youtube.com/watch?v=YQzzlqNAc-I&t=2139s
Planning to launch this to everyone sometime in Q2. Email me if you'd like preview access.
Here's an overview of our approach and technical demo for how the integration will work: https://www.youtube.com/watch?v=YQzzlqNAc-I&t=2139s
Planning to launch this to everyone sometime in Q2. Email me if you'd like preview access.
[deleted]
Ya, I see very little moat for services like authentication. There are tons of other similar services and rolling your own (and by that I mean implementing one of the many open source options is really not a big deal).
I mean auth0 can be eaten that does the default thing (login for web/app/is/tokens etc) without config. For some reason auth0 makes all of this extremely configurable and it’s 99% confusing and unnecessary!
I can't find this article you are talking about. I just looked up Okta on their website and nothing shows up.
Why is this legal?
Reverse that: How could one prove that Okta now has, but did not previously have monopoly power?
Why does it have to be a monopoly to be illegal? They have the largest market share, bought their #1 competitor, and now have very few competitors capable of competing.
Isn't this how disruptive little startups get their foot in the door?
> Okta is built as a top down sales organisation whereas Auth0 is built with a developer first bottoms up acquisition strategy. This allows Okta to get the best of both worlds.
Good luck with that. The CEO of Okta will have to be very very very smart to keep this atmosphere around Auth0. So easier to say that's it's not going to happen. When you are an enterprise company you don't buy a customer centric company to become them, you do the opposite. You make them become like you
Good luck with that. The CEO of Okta will have to be very very very smart to keep this atmosphere around Auth0. So easier to say that's it's not going to happen. When you are an enterprise company you don't buy a customer centric company to become them, you do the opposite. You make them become like you
[deleted]
Most importantly Auth0 was beating Okta on execution. Auth0 was leaner and would soon get to feature parity for both use cases. Without this deal they would slowly have lost ground to Auth0.
This seems to be so transparently the case, how is this behavior not considered anti competitive?
Almost any behavior by a company to outdo its competitors can be described as anti competitive, but not all forms are illegal. Straight from the wikipedia page:
> Anti-competitive practices are commonly only deemed illegal when the practice results in a substantial dampening in competition, hence why for a firm to be punished for any form of anti-competitive behaviour they generally need to be a monopoly or a dominant firm in a duopoly or oligopoly who has significant influence over the market.
Since there are many auth providers (ie https://en.wikipedia.org/wiki/List_of_OAuth_providers) in the market, the takeover of auth0 by okta is not a problem for "the market". It is therefore up to the shareholders of auth0 to sell their shares or not and clearly they chose to cash out instead of gambling that they could continue to out-execute okta and their other competitors.
> Anti-competitive practices are commonly only deemed illegal when the practice results in a substantial dampening in competition, hence why for a firm to be punished for any form of anti-competitive behaviour they generally need to be a monopoly or a dominant firm in a duopoly or oligopoly who has significant influence over the market.
Since there are many auth providers (ie https://en.wikipedia.org/wiki/List_of_OAuth_providers) in the market, the takeover of auth0 by okta is not a problem for "the market". It is therefore up to the shareholders of auth0 to sell their shares or not and clearly they chose to cash out instead of gambling that they could continue to out-execute okta and their other competitors.
I imagine the parent is questioning why the definition for "a substantial dampening in competition" is so strict. To me it seems that they are claiming that this clearly constitutes a substantial dampening in competition, and are thus questioning why it is not illegal.
FTC's Anti-Trust guide is a useful source[1].
Specifically, the "Mergers"[2] section outlines the cases in which government interference might be efficiency promoting.
[1]: https://www.ftc.gov/tips-advice/competition-guidance/guide-a...
[2]: https://www.ftc.gov/tips-advice/competition-guidance/guide-a...
Specifically, the "Mergers"[2] section outlines the cases in which government interference might be efficiency promoting.
[1]: https://www.ftc.gov/tips-advice/competition-guidance/guide-a...
[2]: https://www.ftc.gov/tips-advice/competition-guidance/guide-a...
Do you think that the Okta acquisition of Auth0 promotes or reduces the competiveness of the market?
Clearly, I do not know. Having used both, I do realize their target markets are somewhat separated as is pointed out in the linked article as well. I am dubious on the expansion of Okta's pricing power as a result of this acquisition, but I do not really have the kind of data I would need to be able accurately gauge that.
By that metric, wouldn't profitless growth-over-capitalizing also dampen competition?
It's a tortured argument to say that SoftBank's investments are creating more competition or innovation.
It's a tortured argument to say that SoftBank's investments are creating more competition or innovation.
Yes, indeed it would. I guess the difference is it's harder to be objective about whether something is over capitalized.
> Almost any behavior by a company to outdo its competitors can be described as anti competitive
What? What definition are you using for anti-competitive. What you're describing is competition.
Here's the wiki article listing examples of anti-competitive action: https://en.wikipedia.org/wiki/Anti-competitive_practices#Typ...
What? What definition are you using for anti-competitive. What you're describing is competition.
Here's the wiki article listing examples of anti-competitive action: https://en.wikipedia.org/wiki/Anti-competitive_practices#Typ...
The list of companies that offer OAuth is not a list of competitors to the service AuthO provides. It's a confusion that the latter has encouraged to draft on the former's coattails.
Buying a successful competitor is not "outdoing" the competitor, it's almost admitting defeat.
While you could say there are other offerings, are they as mature? A big shark swimming in a sea of minnows is not a balanced/competitive market.
While you could say there are other offerings, are they as mature? A big shark swimming in a sea of minnows is not a balanced/competitive market.
Did you see the list of competing auth providers? It's a stretch to call Facebook, Google, Amazon and Microsoft minnows.
The assumption you're making is that they have mature offerings because they are big names. Facebook, Google, Amazon and Microsoft have excellent full-featured offerings in every sector they've ever dabbled in? They've never made a bad or neglected product?
This is exactly the problem, the assumption that huge conglomerate juggernauts hoovering up or invading every sector is adequate or healthy competition.
Also that list seems to be very iffy at listing actual competitors to the Auth0 product offering. Much of it looks like services that use OAuth integration for access to their proprietary platform, not necessarily a dev-focused blank canvas for SSO/CIAM integration within your own app. Many specificly list OIDC as No. The list doesn't even have Auth0 on it.
This is exactly the problem, the assumption that huge conglomerate juggernauts hoovering up or invading every sector is adequate or healthy competition.
Also that list seems to be very iffy at listing actual competitors to the Auth0 product offering. Much of it looks like services that use OAuth integration for access to their proprietary platform, not necessarily a dev-focused blank canvas for SSO/CIAM integration within your own app. Many specificly list OIDC as No. The list doesn't even have Auth0 on it.
Makes me wonder why Auth0's board of directors agreed to the sale.
"Cha-ching!"
Business hasn't been about the long term for a while, especially if you're a startup. The goal is to gain recognition and sell at the first good chance you get... rinse, repeat.
You only need to look at what happened to Sears and K-Mart to know that what people look for in value of a company is what you can sell off, not how well you can compete.
Business hasn't been about the long term for a while, especially if you're a startup. The goal is to gain recognition and sell at the first good chance you get... rinse, repeat.
You only need to look at what happened to Sears and K-Mart to know that what people look for in value of a company is what you can sell off, not how well you can compete.
Giving options to your executives is....historically really risky.
because unlikely to be a bigger buyer later, so sell now or chase ipo. likely vc-controlled, so less risky to get the (winning) liquidity now.
once you hit a certain level, you run out of buyers, and thus lose much of your ability to sell at multiples over value... so effective price ceiling.
once you hit a certain level, you run out of buyers, and thus lose much of your ability to sell at multiples over value... so effective price ceiling.
> once you hit a certain level, you run out of buyers,
There's always salesforce :).
No, thank you for a cogent analysis; interesting to me how the incentives shift as you grow and how an IPO can be riskier than a sale.
There's always salesforce :).
No, thank you for a cogent analysis; interesting to me how the incentives shift as you grow and how an IPO can be riskier than a sale.
yep, good comparison! crm bought tableau for $15B+ and google was fine w/ Looker @ $2B, and data is a clear high-ceiling market.
not a lot of buyers at that level, so as soon as > $1B, and bought for way more than 10X on revenue, so unclear if/when they'd see $6B again. capital is cheap right now too, and while interest rates are expected to stay low for 3+ yr, in reality no one knows as the current situation is confusing economists...
not a lot of buyers at that level, so as soon as > $1B, and bought for way more than 10X on revenue, so unclear if/when they'd see $6B again. capital is cheap right now too, and while interest rates are expected to stay low for 3+ yr, in reality no one knows as the current situation is confusing economists...
I would guess the 3.5x valuation from last year.
Stacks and stacks of guaranteed money?
Let's hope it was a reverse merger.
He said, expecting the answer, "no."
He said, expecting the answer, "no."
SoftBank stupid money is gone.
The government has been pitiful at antitrust enforcement since 1981. This needs to change. This merger should be illegal and blocked by the the FTC. Mergers like this make the financiers billions and make the rest of us worse off.
I'm not sure I agree. The one killer feature that Auth0 has the Okta doesn't is their built in lambdas and they've had it forever.
If this was true and was indeed very little risk in getting there, they wouldn't have sold. Think about it.
I work with a LOT of large enterprises, and I see Okta everywhere. Where I don't see Okta, I see Microsoft and Ping. I've never run across an enterprise using Auth0, so I was surprised to see this statement:
>Auth0 is the most prominent alternative that customers consider when evaluating Okta.
Is there a feature/vertical where Auth0 and Okta compete that isn't enterprise IDMS? Or was Auth0's market outside of the Fortune 500 space?
* edit - OK, it seems clear from the responses that what I see Okta used for (employee/internal identity management) is not what Auth0 was focused on. That makes sense - thanks for all the answers!
>Auth0 is the most prominent alternative that customers consider when evaluating Okta.
Is there a feature/vertical where Auth0 and Okta compete that isn't enterprise IDMS? Or was Auth0's market outside of the Fortune 500 space?
* edit - OK, it seems clear from the responses that what I see Okta used for (employee/internal identity management) is not what Auth0 was focused on. That makes sense - thanks for all the answers!
Okta and Auth0 have mostly been serving the opposite ends of enterprise login, with Okta starting to take on Auth0 (and not so much the other way around).
Okta mostly handles being the "enterprise database of users + gateway to your enterprise apps", i.e. it's an identity provider (IdP). ActiveDirectory and PingIdentity are competitors here.
Auth0 mostly handles the other end of the line: they help companies be "a thing you can log into using an IdP", i.e. they help companies be a service provider (SP). Custom SAML/OIDC implementations are the biggest competitors here. Okta has increasingly been competing with Auth0 in the space of SaaS SP solutions.
So it's in the latter half -- service providers -- where the two compete. You may have been looking in the wrong place. Plus, not all companies are service providers, and many companies that are service providers roll their own implementation of the relevant protocols.
Okta mostly handles being the "enterprise database of users + gateway to your enterprise apps", i.e. it's an identity provider (IdP). ActiveDirectory and PingIdentity are competitors here.
Auth0 mostly handles the other end of the line: they help companies be "a thing you can log into using an IdP", i.e. they help companies be a service provider (SP). Custom SAML/OIDC implementations are the biggest competitors here. Okta has increasingly been competing with Auth0 in the space of SaaS SP solutions.
So it's in the latter half -- service providers -- where the two compete. You may have been looking in the wrong place. Plus, not all companies are service providers, and many companies that are service providers roll their own implementation of the relevant protocols.
Startup here who went with Auth0 for our SaaS. It seemed very developer friendly and something we could (and did) on-board ourselves. It gave us a custom, federated identity system that could brand and integrate with our backend without getting into a big enterprise sales cycle. We're a small team.
I would say that Okta was primarily IAM (identity and access management for your employees) and Auth0 was primarily CIAM (customer identity and access management).
So I think they both were aiming at the same customers, just for different use cases.
So I think they both were aiming at the same customers, just for different use cases.
Primarily startups. We've used Auth0 for the last 4 years and we've only ever had one outage.
We were/are (Fortune 500) in the process of migrating from Ping to Auth0... Glad I’m not on the group that’s been working on that for the past 1-2 years
Interesting sentiment. What were the pain points? What was better about Ping?
Your comment is an interesting contrast against https://news.ycombinator.com/item?id=26359752
Your comment is an interesting contrast against https://news.ycombinator.com/item?id=26359752
The company I work for went with Auth0 for a new SAAS offering, partly because Auth0 kept beating Okta on price (at least for our use case).
With this acquisition, that won't be the case much longer.
A lot of enterprises pick the cheapest option. Especially if it's just one business unit making the choice.
My take on this is a little different. (Disc: I'm a cofounder of Clerk which is also in the space)
I think Okta will try to build "Okta for Customer ID"
When people think of Okta, they think of it as a tool to help employees securely access third-party SaaS vendors.
That same problem exists for Customer Identity, but it looks a little different. Instead of setting up SSO for SaaS, developers are writing code to pass their customer data into tools like Stripe, Intercom, Salesforce, Segment, Mailchimp, etc, etc.
This is redundant work that a centralized Customer identity provider has the potential to alleviate.
I don't really think Auth0 is well-positioned to pull this off, and that's part of why we started Clerk. But considering Okta has that playbook in it's DNA, I wouldn't be surprised if that's what they're attempting.
I think Okta will try to build "Okta for Customer ID"
When people think of Okta, they think of it as a tool to help employees securely access third-party SaaS vendors.
That same problem exists for Customer Identity, but it looks a little different. Instead of setting up SSO for SaaS, developers are writing code to pass their customer data into tools like Stripe, Intercom, Salesforce, Segment, Mailchimp, etc, etc.
This is redundant work that a centralized Customer identity provider has the potential to alleviate.
I don't really think Auth0 is well-positioned to pull this off, and that's part of why we started Clerk. But considering Okta has that playbook in it's DNA, I wouldn't be surprised if that's what they're attempting.
> When people think of Okta, they think of it as a tool to help employees securely access third-party SaaS vendors.
That’s how I think of Auth0+Duo.
I think of Okta as the more expensive, less flexible, slower moving, harder to deal with competitor to them.
That’s how I think of Auth0+Duo.
I think of Okta as the more expensive, less flexible, slower moving, harder to deal with competitor to them.
> But considering Okta has that playbook in it's DNA, I wouldn't be surprised if that's what they're attempting.
I'm sorry; Okta has which playbook in its DNA?
I'm sorry; Okta has which playbook in its DNA?
Third party integrations
Why aren't all the existing products in ETL-for-marketers space already the answer to the question you pose?
Most companies have a users table, and there are a ton of products that can, without code, ETL a users table into all sorts of tools. There's no redundant work -- in fact, for developers there may not be any work to do at all?
Most companies have a users table, and there are a ton of products that can, without code, ETL a users table into all sorts of tools. There's no redundant work -- in fact, for developers there may not be any work to do at all?
Because they don't know confidently which user is logged in. A lot of the marketing tools rely on insecure signals, like a userID passed directly from javascript.
If you want to trigger actions rather than observe them, you need a secure way of authenticating those actions. That's why Clerk does session management :)
If you want to trigger actions rather than observe them, you need a secure way of authenticating those actions. That's why Clerk does session management :)
Let me make sure I understand you: I think you're talking about accurate attribution of clickstream analytics to particular users, in the face of spoofed data from clients?
And then, connecting the dots a bit, spoofed clickstream events could trigger some sort of marketing campaign event or other "action" that can become a vector for security issues, such as Eve figuring out what Adam has in his shopping cart by manipulating a cart-abandoned campaign to go to Eve's email instead of Adam's?
If so, this is usually addressed by server-side analytics events. I fail to see any mechanism by which this could be solved client-side, nor any useful way for any vendor to make this process meaningfully easier. Analytics events are basically as easy as console.log with most vendors.
And then, connecting the dots a bit, spoofed clickstream events could trigger some sort of marketing campaign event or other "action" that can become a vector for security issues, such as Eve figuring out what Adam has in his shopping cart by manipulating a cart-abandoned campaign to go to Eve's email instead of Adam's?
If so, this is usually addressed by server-side analytics events. I fail to see any mechanism by which this could be solved client-side, nor any useful way for any vendor to make this process meaningfully easier. Analytics events are basically as easy as console.log with most vendors.
Sorry about that, I think I cluttered my response by talking about the client-side use case.
Does anybody use ETL-for-marketers tools to extract User data from one source, then load it into Stripe as Customer objects?
I don't think it's common. We mostly see developers creating Stripe Customer objects themselves in their backend.
If I understood your original question correctly, you were asking why ETL tools don't do this? I think it's because these tools are deliberately capable of working with fuzzy data streams, so it at least feels weird to start using them for secure actions. Their security model may also make it dangerous to try.
---
Somewhat aside: Authenticating actions from the client is most-easily solved by signing JWTs. Tools like Hasura are doing this in the wild, though it isn't too common among third-party APIs yet. Another close example is Intercom, which asks you to use a non-JWT signature to pass in user data: https://developers.intercom.com/installing-intercom/docs/ios...
Does anybody use ETL-for-marketers tools to extract User data from one source, then load it into Stripe as Customer objects?
I don't think it's common. We mostly see developers creating Stripe Customer objects themselves in their backend.
If I understood your original question correctly, you were asking why ETL tools don't do this? I think it's because these tools are deliberately capable of working with fuzzy data streams, so it at least feels weird to start using them for secure actions. Their security model may also make it dangerous to try.
---
Somewhat aside: Authenticating actions from the client is most-easily solved by signing JWTs. Tools like Hasura are doing this in the wild, though it isn't too common among third-party APIs yet. Another close example is Intercom, which asks you to use a non-JWT signature to pass in user data: https://developers.intercom.com/installing-intercom/docs/ios...
If anyone's looking for an Auth0 alternative, I recommend checking out WorkOS.
It's like Stripe for enterprise features, including SSO/SAML, Directory/SCIM, and more.
https://workos.com/docs
(I'm the founder. Hope it's still ok to shamelessly plug your startup on HN. :) )
It's like Stripe for enterprise features, including SSO/SAML, Directory/SCIM, and more.
https://workos.com/docs
(I'm the founder. Hope it's still ok to shamelessly plug your startup on HN. :) )
Please plug away. I was so pleasantly surprised to view documentation that did not suck, and was a pleasure to read.
After going through the Sisyphean ordeal of trying to read and understand okta's api docs for so long, this was a breath of fresh air. While my current org is locked on to okta, will definitely consider/recommend this for future efforts.
After going through the Sisyphean ordeal of trying to read and understand okta's api docs for so long, this was a breath of fresh air. While my current org is locked on to okta, will definitely consider/recommend this for future efforts.
Not long ago I worked at Okta, and I know their engineering process pretty well. If I were to speculate on the purchase on Auth0, it would be to get more engineers improving the Okta platform. There are some really hard scaling problems and some really hard security problems, and absorbing Auth0's talent is a way to acquire specialty talent in a narrow space.
Finding the right engineer who can program securely, scale, and make the developer empathy painless is a key challenge. This is what Okta did with Stormpath before the IPO.
(Disclosure: long OKTA)
Finding the right engineer who can program securely, scale, and make the developer empathy painless is a key challenge. This is what Okta did with Stormpath before the IPO.
(Disclosure: long OKTA)
Does the ~S~E~C~ (edit: FTC) have to approve? If so, have they?
https://en.wikipedia.org/wiki/Hart%E2%80%93Scott%E2%80%93Rod...
-------------------------
The general rule is that a filing is required if three tests are met: *
(1) the transaction affects U.S. commerce;
(2) either
-------------------------
* IANAL, but I worked somewhere that was charged with violating the act and it's any of the three, not all of them.
https://en.wikipedia.org/wiki/Hart%E2%80%93Scott%E2%80%93Rod...
-------------------------
The general rule is that a filing is required if three tests are met: *
(1) the transaction affects U.S. commerce;
(2) either
(a) one of the parties has annual sales or total assets of $151.7 million[3] or more (as of 2014: in 2012 this threshold amount began increasing periodically under the law), and the other party has sales or assets of $15.2 million[3] or more (as of 2014: this amount adjusts periodically) (where an acquired person is not engaged in manufacturing, only its total assets, not its sales, are counted, unless its sales are over $151.7 million[3]); or
(b) the amount of stock the acquirer has is valued at $272.8 million or more (as of 2012: amount adjusts periodically) at any time; and
-------------------------
* IANAL, but I worked somewhere that was charged with violating the act and it's any of the three, not all of them.
FYI, it is not the SEC that approves mergers with respect to antitrust concerns, but rather the FTC or DOJ. See https://www.ftc.gov/news-events/media-resources/mergers-and-...
They will need to for a transaction of this size, and the approval process is most likely ongoing (and will continue for the next few months).
I'd like to see the FTC get involved. Seems like this is going to reduce competition.
Any merger or acquisition by definition reduces competition, but these two are far from the only players in the IDMS market.
I think that's often true, but it's not true by definition. For example, if a large company in industry X buys a small company in industry Y as a way of entering a market, competition can go up in industry Y as the small company now has increased capacity to compete with the bigger players.
Waiting for "I can build this over a weekend" comment on Hacker News :)
If somebody would write an Auth0 replacement over the weekend, that would be great.
Coincidentally I was looking for a self-hosted auth solution today and I can say there isn't anything that's close to as easy to use as just paying for Auth0.
Some decent one's I found where keyclock, glewlwyd and ory, but they where too heavy or complex. I ended up going for caddy-auth-portal, which doesn't even do user management yet.
Coincidentally I was looking for a self-hosted auth solution today and I can say there isn't anything that's close to as easy to use as just paying for Auth0.
Some decent one's I found where keyclock, glewlwyd and ory, but they where too heavy or complex. I ended up going for caddy-auth-portal, which doesn't even do user management yet.
We're using Ory Hydra and a modified version of Ory Oathkeeper in production, but our usecase might be a bit different (we already had a user database and auth system). Compared to implementing them from scratch, setup was simple and the end product is fantastic.
We're looking at migrating to Ory Kratos eventually. It seems to offer the things we would've wanted from Auth0, but selfhosted. Granted, you're right - I'm sure it's much more complex to selfhost Kratos than to pay for Auth0.
We're looking at migrating to Ory Kratos eventually. It seems to offer the things we would've wanted from Auth0, but selfhosted. Granted, you're right - I'm sure it's much more complex to selfhost Kratos than to pay for Auth0.
Not that hard, when you run their quickstart (one docker-compose command) you get a self service node.js based app which uses Kratos client to offer authentication, registration, email reset, user data management, authentication with third parties. All of this backed up on a postgres / mysql / sqlite db and running on a (go) binary.
MFA is in progress, other than that, I think it's a solid offering (and I'm using it for a product).
Integrating with oathkeeper (tokens) or keto (permission control) is quite simple as well.
MFA is in progress, other than that, I think it's a solid offering (and I'm using it for a product).
Integrating with oathkeeper (tokens) or keto (permission control) is quite simple as well.
That's good to hear. I was skeptical to go that route since I would have needed to install 3 services instead of just a caddy plugin and I wasn't sure where I would find a UI. But maybe in the future it'll be a good option.
How mature do you feel the Ory ecosystem is? Any major speedbumps?
Would love to know as well. Considering a switch from Cognito here.
We are using Ory Hydra now (but not any of the other components like Kratos, Oathkeeper, etc) and no real complaints so far. It is important to understand though the Hydra is just a component and not an out-of-the-box solution. You still have to implement your own user interface is you plan on doing OIDC login (and not just client_credentials for service authentication). Basically Hydra just takes a self-hosted login/registration/etc UI which you build yourself and wraps it in an OIDC provider. Which is great if you need to build an OIDC provider and want tight control over the user experience and user management (our use case) but don't want to implement all the fussy details of the OAuth2 protocol.
Hydra feels mature. I think it's their longest-developed product so far. Besides breaking changes during big upgrades(v0 -> v1beta -> v1), everything has been painless:
- It runs anywhere with or without containers
- API makes sense, good SDKs are available in all my used languages
- RAM usage is surprisingly low compared to usage and has been great for resource-constrained environments
- Stateless means horizontal scaling is as easy as `replicas++`
- Sub-millisecond response times for some calls, much faster than our previous setup
With Hydra, I know it's the client's fault when OAuth calls fail and not just a buggy server implementation. This is reinforced in dev mode with great errors like:
- The authorization code has already been used
- The request is missing the response_type parameter
- Parameter "nonce" must be set when using the implicit flow
- Redirect URL "https://example.com/callback" does not match
On the flipside, Oathkeeper is not a mature product and has not yet reached v1. There are breaking changes planned [1]. It lacks support for at least one popular usecase (mine) out of the box [2]. Rules can be hard to create and debug. I wouldn't recommend Oathkeeper in its current state unless you're ready to dive in and fix things yourself. Once configured it sticks with the Ory trend: fast, lean, and stable.
Depending on your usecase, Oathkeeper could be swapped out with any IAP like Pomerium or just with your reverse proxy's auth request support + some small custom shim.
I haven't tried Keto (access control) or Kratos (user management) yet. Kratos is on my todo list.
[1] https://github.com/ory/oathkeeper/issues/441
[2] https://github.com/ory/oathkeeper/issues/521
- It runs anywhere with or without containers
- API makes sense, good SDKs are available in all my used languages
- RAM usage is surprisingly low compared to usage and has been great for resource-constrained environments
- Stateless means horizontal scaling is as easy as `replicas++`
- Sub-millisecond response times for some calls, much faster than our previous setup
With Hydra, I know it's the client's fault when OAuth calls fail and not just a buggy server implementation. This is reinforced in dev mode with great errors like:
- The authorization code has already been used
- The request is missing the response_type parameter
- Parameter "nonce" must be set when using the implicit flow
- Redirect URL "https://example.com/callback" does not match
On the flipside, Oathkeeper is not a mature product and has not yet reached v1. There are breaking changes planned [1]. It lacks support for at least one popular usecase (mine) out of the box [2]. Rules can be hard to create and debug. I wouldn't recommend Oathkeeper in its current state unless you're ready to dive in and fix things yourself. Once configured it sticks with the Ory trend: fast, lean, and stable.
Depending on your usecase, Oathkeeper could be swapped out with any IAP like Pomerium or just with your reverse proxy's auth request support + some small custom shim.
I haven't tried Keto (access control) or Kratos (user management) yet. Kratos is on my todo list.
[1] https://github.com/ory/oathkeeper/issues/441
[2] https://github.com/ory/oathkeeper/issues/521
I'm extremely excited by ory. We're using some Auth0 and some AD B2C, but I'd love to move to ory and just run our own thing.
Would love your feedback on FusionAuth (full disclosure, I work there).
Free to download and run (but not open source, if that matters to you): https://fusionauth.io/download/
I don't know your exact use case but would be happy to chat.
Free to download and run (but not open source, if that matters to you): https://fusionauth.io/download/
I don't know your exact use case but would be happy to chat.
As indicated by another commenter I found the product messaging/pricing really confusing. There's "Cloud", "Editions", "Reactor" with little way to see how the relate and it's not immediately obvious there is a self hosted version. This turned me off as I just saw $75/month for a development/test version (which isn't really the case).
After diving in deeper the pricing calculator really cleared things up, but I think the menu structure and front page messaging could be vastly improved to help guide the user.
After diving in deeper the pricing calculator really cleared things up, but I think the menu structure and front page messaging could be vastly improved to help guide the user.
Thanks everyone for the feedback about the muddy message. I'll see what I can do to clear it up, now and later on the website.
If you want the basic community edition (you can see the features here: https://fusionauth.io/pricing/editions/ by expanding the 'Full Feature Breakdown' table) and want to self host, you can download this free as in beer standalone executable: https://fusionauth.io/download/
If you want us to host the basic community edition for you, you can purchase a single tenant instance managed by us: https://fusionauth.io/pricing/cloud/
If you want premium features (LDAP connectivity, breached password detection, and others), you can buy a paid edition; some of these include support: https://fusionauth.io/pricing/editions/
If you want us to host for you and you need the premium edition, you can buy both a license.
Additionally, for some uses (if you resell FusionAuth to your customers, for instance) you will need to talk to us: https://fusionauth.io/license-faq/
Wow, writing that makes it clear to me how unclear that is. I'll see if we can't simplify or make this clearer.
Thanks again for your feedback!
If you want the basic community edition (you can see the features here: https://fusionauth.io/pricing/editions/ by expanding the 'Full Feature Breakdown' table) and want to self host, you can download this free as in beer standalone executable: https://fusionauth.io/download/
If you want us to host the basic community edition for you, you can purchase a single tenant instance managed by us: https://fusionauth.io/pricing/cloud/
If you want premium features (LDAP connectivity, breached password detection, and others), you can buy a paid edition; some of these include support: https://fusionauth.io/pricing/editions/
If you want us to host for you and you need the premium edition, you can buy both a license.
Additionally, for some uses (if you resell FusionAuth to your customers, for instance) you will need to talk to us: https://fusionauth.io/license-faq/
Wow, writing that makes it clear to me how unclear that is. I'll see if we can't simplify or make this clearer.
Thanks again for your feedback!
That does clarify things. To be honest I thought "Editions" was a product alongside "Cloud".
So Fusionauth looks pretty good - it does a lot more than I need. Though the lack of a "public path" setting is the first roadblock: https://github.com/FusionAuth/fusionauth-issues/issues/88
So Fusionauth looks pretty good - it does a lot more than I need. Though the lack of a "public path" setting is the first roadblock: https://github.com/FusionAuth/fusionauth-issues/issues/88
There are some workarounds in that thread, but please do comment with your use case and/or vote for the issue with a thumbs up.
However, if FusionAuth does a lot more than you need, it may not be the right solution for you. :) Right tool for the job and all that.
However, if FusionAuth does a lot more than you need, it may not be the right solution for you. :) Right tool for the job and all that.
I might consider something closed source but I find your offering quite confusing. Is the download a standalone auth server? I notice it isn't mentioned on the pricing page so I don't really get it. It would also depend what the minimum RAM requirements are.
Not OP but I wouldn't consider using this because it doesn't say what you said "Free to download and run." The language on the site makes it look like a free trial of some sort.
What do you think about Supertokens.io?
Granted its not as mature but its open source, easy to implement (decouples features based on your use case), really customizable frontend UI and great support (ping me anytime!)
Granted its not as mature but its open source, easy to implement (decouples features based on your use case), really customizable frontend UI and great support (ping me anytime!)
Keycloak has been solid for us. The last major version upgrade wasn't super smooth, but I'm glad it exists so I don't have to think about auth any more.
Check out Netlify’s GoTrue server. It’s what we use at Supabase, after trying out almost all the others listed in this thread.
It’s the most simple self-hosted solution IMO
It’s the most simple self-hosted solution IMO
Honestly, if you're doing AD, SAML, etc - sure go with Auth0.
If you want oauth2 + OpenID connect, use a damn library. Auth0 will make it more complicated not less.
If you want oauth2 + OpenID connect, use a damn library. Auth0 will make it more complicated not less.
I would do but I'm not even sure I understand what any of this does.
The question isn't whether there's value here. They've got revenue and you can't dispute that.
The question is whether they're worth 13x more than a valuation of 500 million dollars.
The question is whether they're worth 13x more than a valuation of 500 million dollars.
since you asked for it : https://developers.redhat.com/blog/2017/01/05/spring-boot-an...
Honestly, properly configuring, maintaining and scaling Keycloak is an absolute pain in my experience. Keyclaok does not come close to the ease of use of Okta and Auth0 imho
Can you please elaborate on the issues you are seeing?
I just got started, but so far my experience setting Keycloak up has been the best I've experienced for an open source project in a while. I was up and running within a few hours-
Got a simple JS app working, and was able to secure all my existing services by integrating with my ingress controller.
I just got started, but so far my experience setting Keycloak up has been the best I've experienced for an open source project in a while. I was up and running within a few hours-
Got a simple JS app working, and was able to secure all my existing services by integrating with my ingress controller.
Recently moved away from Keycloak (which I think overall is a great piece of software but was just a PITA for our use case) and my observations:
* Zero-downtime deployments don't really work. They kinda-sorta do but it was too clunky for us to do it effectively during periods when we had significant traffic. Not generally an issue if you are just using out-of-the-box components but if you are deploying custom components (Storage providers, authenticators, etc) then it doesn't work that well.
* It uses an in-memory distributed cache for authentication sessions so if your instance goes down (or you need to shut it down for a major version upgrade) then everyone is logged out. It also seems to have a lot of trouble scaling out to more than ~8 nodes. At the minimum you have to do a lot of tuning of infinispan parameters to get it to work at scale.
* Configuration is kind of a pain because it has to be done through the UI. There is a REST API but it is really hard to work with if you want to do something like deploy a change to an authentication flow configuration. So forget about managing your configs in source control (and prepare for the inevitable issues that happen when configs aren't properly updated with deployment because someone fat-fingers something in the configuration UI).
* There is a LOT of stuff that is hard-coded in the core Keycloak engine that makes customization impossible short of modifying the actual Keycloak source itself and running your own build (not recommended!).
* One small thing that nonetheless drove me crazy is the Keycloak injects a JS snippet into rendered templates to munge the browser history and has no way for you to insert a nonce in the script tag, so setting up CSP headers was way harder than it should have been.
All that said, it was more that Keycloak was not the right tool for our use case (an always-on user-facing identity provider) but if you just need a basic login/registration screen and are fine using Keycloak's built-in components (with maybe just some thumbing) then it works great.
* Zero-downtime deployments don't really work. They kinda-sorta do but it was too clunky for us to do it effectively during periods when we had significant traffic. Not generally an issue if you are just using out-of-the-box components but if you are deploying custom components (Storage providers, authenticators, etc) then it doesn't work that well.
* It uses an in-memory distributed cache for authentication sessions so if your instance goes down (or you need to shut it down for a major version upgrade) then everyone is logged out. It also seems to have a lot of trouble scaling out to more than ~8 nodes. At the minimum you have to do a lot of tuning of infinispan parameters to get it to work at scale.
* Configuration is kind of a pain because it has to be done through the UI. There is a REST API but it is really hard to work with if you want to do something like deploy a change to an authentication flow configuration. So forget about managing your configs in source control (and prepare for the inevitable issues that happen when configs aren't properly updated with deployment because someone fat-fingers something in the configuration UI).
* There is a LOT of stuff that is hard-coded in the core Keycloak engine that makes customization impossible short of modifying the actual Keycloak source itself and running your own build (not recommended!).
* One small thing that nonetheless drove me crazy is the Keycloak injects a JS snippet into rendered templates to munge the browser history and has no way for you to insert a nonce in the script tag, so setting up CSP headers was way harder than it should have been.
All that said, it was more that Keycloak was not the right tool for our use case (an always-on user-facing identity provider) but if you just need a basic login/registration screen and are fine using Keycloak's built-in components (with maybe just some thumbing) then it works great.
> Configuration is kind of a pain
The REST API is pretty sufficient in my experience. Beyond that for realm management, we use ansible modules [1].
[1] https://docs.ansible.com/ansible/latest/collections/communit...
The REST API is pretty sufficient in my experience. Beyond that for realm management, we use ansible modules [1].
[1] https://docs.ansible.com/ansible/latest/collections/communit...
Spring Security is really pleasant to work with.
Keycloak is also quite nice, but configuration is rather annoying at times.
Should be workable.
Keycloak is also quite nice, but configuration is rather annoying at times.
Should be workable.
> Okta will issue shares to Auth0 shareholders at share price of $276.21, close to 20% less than the current share price (at the time of writing).
The screenshot immediately under this statement shows an Okta share price of $226. Am I misunderstanding something?
The screenshot immediately under this statement shows an Okta share price of $226. Am I misunderstanding something?
The deal had to be done at a certain time, which froze the value of the shares at the price. The shares were probably reserved for this purpose at that time.
The screenshot did not properly show the price "at the time of writing". sloppy, that's all.
The chart didnt cover after hour pricing unfortunately (which is what was being referenced). Note taken though, will keep it in mind!
[deleted]
[deleted]
$276.21 - 20% = $220.968
So not far off from $226
$226 / $276.21 = 81.8%
So its 18.2% to be exact
Edit: Realized the quote/article says 20% LOWER. Which is backwards, and is likely what my parent comment is pointing out
So not far off from $226
$226 / $276.21 = 81.8%
So its 18.2% to be exact
Edit: Realized the quote/article says 20% LOWER. Which is backwards, and is likely what my parent comment is pointing out
Looks like this is only good for people whose chief activity is "owning stuff".
Everybody else (specifically people who actually execute actions, build stuff) loses.
Everybody else (specifically people who actually execute actions, build stuff) loses.
> it can also refactor Auth0’s (and it’s own) pricing to increase revenue even further.
Yeah, about that. Auth0 is already struggling to compete with Firebase Auth, AWS Cognito, and even Azure AD B2C (at least on price, for that last one). Increasing the price further is a bad idea.
Also, ory.sh is coming. If I were Salesforce, I'd be funding that to just commoditise auth.
Yeah, about that. Auth0 is already struggling to compete with Firebase Auth, AWS Cognito, and even Azure AD B2C (at least on price, for that last one). Increasing the price further is a bad idea.
Also, ory.sh is coming. If I were Salesforce, I'd be funding that to just commoditise auth.
> Auth0 is built with a developer first bottoms up acquisition strategy
I really wish people would stop saying “bottoms up.” This is what you say when you’re clinking glasses together. The phrase people are looking for here is “bottom up,” as in “up from the bottom of the organization.” So unless they mean they’re starting from a developer’s ass, or preparing to ram their product up a bunch of developers’ exposed bottoms, it would be nice if people learned this expression.
I really wish people would stop saying “bottoms up.” This is what you say when you’re clinking glasses together. The phrase people are looking for here is “bottom up,” as in “up from the bottom of the organization.” So unless they mean they’re starting from a developer’s ass, or preparing to ram their product up a bunch of developers’ exposed bottoms, it would be nice if people learned this expression.
Self-Sovereign Identity might replace major parts of the federated identity market within 5 years i expect. even Okta CEO admitted that self-sovereign identity will be the future. the major problem is that the decentralized nature of SSI, will remove the most part and profit of 3rd party tools, as it is easier and cheaper to have direct relations between services and users
Company realises that they have become kind of slow and that their culture is not conductive to moving fast, innovation and making more money
"We could just buy a culture that is" and then either they keep it alive or the original culture destroyed the acquired one and the process starts again?
Isn't that like half of acquisitions or maybe I'm being too simplistic, I dunno
"We could just buy a culture that is" and then either they keep it alive or the original culture destroyed the acquired one and the process starts again?
Isn't that like half of acquisitions or maybe I'm being too simplistic, I dunno
Recent and related:
Okta to Acquire Auth0 for $6.5B - https://news.ycombinator.com/item?id=26334516 - March 2021 (309 comments)
Okta to Acquire Auth0 for $6.5B - https://news.ycombinator.com/item?id=26334516 - March 2021 (309 comments)
[deleted]
Having integrated both... Okta is an awful product and Auth0 is an excellent product. Night and day difference in quality.
Auth0 was actually no alternative given its pricing. I actually saw a lot of people moving to Firebase from Auth0.
Author of the article here. Feel free to AMA about the acquisition (or about SuperTokens)
[deleted]
Did any employees get screwed when it came to stock options?
Auth is easy, right ?
The pain point to me is authorization. Doing authorization correctly is really hard.
But most of frameworks i see (open source or closed source) failed at that job.
The pain point to me is authorization. Doing authorization correctly is really hard.
But most of frameworks i see (open source or closed source) failed at that job.
When people say oh it has a $30 Billion addressable market... how do they come up with these numbers? Startup CEO types love to throw around these numbers but some time they seem wildly optimistic, and their methodology is rarely explained.
Could be as simple as "number of companies that need auth x number of employees of that company x average cost per seat for Okta/Auth0".
Now, figuring out some of those numbers is harder. Okta simplest pricing is $2 per person per month, but to really us it you are looking at paying more like $15 a month. So, per user it's $180 a year. 30 billion / 180 = 166 million users. If average company size is 500, that's 330k companies, which is a lot.
Anyway, those are just very quick back of the napkin numbers. I would guess they've done a little more work to come up with the number.
(pls forgive any math errors/rounding!)
Now, figuring out some of those numbers is harder. Okta simplest pricing is $2 per person per month, but to really us it you are looking at paying more like $15 a month. So, per user it's $180 a year. 30 billion / 180 = 166 million users. If average company size is 500, that's 330k companies, which is a lot.
Anyway, those are just very quick back of the napkin numbers. I would guess they've done a little more work to come up with the number.
(pls forgive any math errors/rounding!)
Yeah these figures really are less to differentiate between the $33 billion and $34 billion markets, and more to differentiate between the $33 billion and $33 million markets. Just a way to get a rough idea of approximate size, as compared to other rough ideas of approximate size.
They OH auth0 was using mongo to store customers’ data and wanted to fix that.
What are some open source self hosted alternatives to Okta and Auth0?
Keycloak, Ory Hydra, and supertokens.io
Okta’s core strength is in her predominately salespeople; programmers, not so much.
Anyone want to start a competing SSO service?
WorkOS, FusionAuth, Keycloak, the ecosystem is flush. Vote with your dollars and your implementation.
What are the interesting contrasts & differentiators in the ecosystem in your opinion?
I work for FusionAuth and we have some comparisons on our website, but I haven't built an application with each of these.
I'd say that dimensions that matter vary so widely for each person and use case, it'd be hard to do a great comparison.
Dimensions that matter:
Oh, and pricing! Lots of the smaller operations (us included) have transparent pricing, but Okta/Auth0 don't.
I wrote out a list of 13 different use cases for FusionAuth ( https://github.com/fusionauth/fusionauth-issues/issues/1002 ) and I am still discovering new ways this coiuld be used. I'm sure that is the case with all these competitors.
It's the old elephant story: https://www.peacecorps.gov/educators/resources/story-blind-m...
I'd say that dimensions that matter vary so widely for each person and use case, it'd be hard to do a great comparison.
Dimensions that matter:
* open source or not
* standalone application or library/framework you integrate
* self hosted or SaaS
* authentication, authorization, user management or all three?
* standards implementation
* integrations with other auth tech (LDAP)
* which OAuth grants they support
* documentation and developer experience
Oh, and pricing! Lots of the smaller operations (us included) have transparent pricing, but Okta/Auth0 don't.
I wrote out a list of 13 different use cases for FusionAuth ( https://github.com/fusionauth/fusionauth-issues/issues/1002 ) and I am still discovering new ways this coiuld be used. I'm sure that is the case with all these competitors.
It's the old elephant story: https://www.peacecorps.gov/educators/resources/story-blind-m...
Clerk, who top paged recently https://news.ycombinator.com/item?id=26069621, could compete on that front.
I'm not sure folks considering Okta are also considering 18-month old competitors charge $0.05/user. Other comments here place Okta at $2-15/user/month depending on feature-set so it's hard to imagine there's anything close to feature parity with that pricing spread.
Thanks for the mention :)
Come join us! We're building similar react components for creating and managing organizations, including a self-serve way for IT admins to setup SSO for their org.
Come join us! We're building similar react components for creating and managing organizations, including a self-serve way for IT admins to setup SSO for their org.
Take a look at the site this blog is posted on ;)
You could probably make money on Shibboleth consulting.
"Grants pricing power" is such a euphemistic phrase for "solidifying a monopoly will let them price gouge"