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
(3) the value of the securities or assets of the other party held by the acquirer after the transaction is $68.2 million or more (as of 2012: amount adjusts periodically).[4] The 2018 rules raise this amount to US$84.4 million [5]
-------------------------
* IANAL, but I worked somewhere that was charged with violating the act and it's any of the three, not all of them.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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 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:
* 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
And that doesn't get into specific features that you might need. An example: if you want to modify a user object in the middle of a login flow, Auth0 has rules, we have Lambdas, Keycloak has plugins. How are you going to know what features you need without building out at least a sample app?
Oh, and pricing! Lots of the smaller operations (us included) have transparent pricing, but Okta/Auth0 don't.
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.
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.
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!
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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 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
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.
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.
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.
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.
I talked to one of the founders several years ago.
An experienced programmer probably could but:
- writing an app doesn't mean it's a business
- Okta has thousands of partner integrations, with the development costs borne by the partners.
Fun fact: Okta, an auth database company, did not have a DBA until around 200 employees. Then they ran into technical issues and started interviewing for one, but nobody was qualified to do the interviews. (They do have a DBA team now.)
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.
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.
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.
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?
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 :)
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.
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...
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.
> 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
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.
> 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.
> Auth0 is the most prominent alternative that customers consider when evaluating Okta. The acquisition of Auth0 eliminates that threat and grants Okta pricing power as a result.
"Grants pricing power" is such a euphemistic phrase for "solidifying a monopoly will let them price gouge"
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.
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.
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.
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 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.
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.
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!
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.
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
156 comments
[ 26.8 ms ] story [ 868 ms ] threadhttps://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
(3) the value of the securities or assets of the other party held by the acquirer after the transaction is $68.2 million or more (as of 2012: amount adjusts periodically).[4] The 2018 rules raise this amount to US$84.4 million [5]-------------------------
* IANAL, but I worked somewhere that was charged with violating the act and it's any of the three, not all of them.
The screenshot immediately under this statement shows an Okta share price of $226. Am I misunderstanding something?
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
> 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.
It's a tortured argument to say that SoftBank's investments are creating more competition or innovation.
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...
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.
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.
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...
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.
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.
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...
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.
He said, expecting the answer, "no."
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:
And that doesn't get into specific features that you might need. An example: if you want to modify a user object in the middle of a login flow, Auth0 has rules, we have Lambdas, Keycloak has plugins. How are you going to know what features you need without building out at least a sample app?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...
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.
Everybody else (specifically people who actually execute actions, build stuff) loses.
>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 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.
So I think they both were aiming at the same customers, just for different use cases.
Your comment is an interesting contrast against https://news.ycombinator.com/item?id=26359752
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.
* 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.
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...
Keycloak is also quite nice, but configuration is rather annoying at times.
Should be workable.
If you want oauth2 + OpenID connect, use a damn library. Auth0 will make it more complicated not less.
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.
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.
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.
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!
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
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.
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.
- 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
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.
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!)
It’s the most simple self-hosted solution IMO
An experienced programmer probably could but:
- writing an app doesn't mean it's a business
- Okta has thousands of partner integrations, with the development costs borne by the partners.
Fun fact: Okta, an auth database company, did not have a DBA until around 200 employees. Then they ran into technical issues and started interviewing for one, but nobody was qualified to do the interviews. (They do have a DBA team now.)
The question is whether they're worth 13x more than a valuation of 500 million dollars.
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!)
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'm sorry; Okta has which playbook in its DNA?
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?
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 :)
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.
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...
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.
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. :) )
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.
Okta to Acquire Auth0 for $6.5B - https://news.ycombinator.com/item?id=26334516 - March 2021 (309 comments)
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
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)
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.
"Grants pricing power" is such a euphemistic phrase for "solidifying a monopoly will let them price gouge"
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.
This is a serious incentive for anyone to launch a new company in the field.
And, yet, everything is still a pain in the ass.
We were looking at Auth0 precisely because Okta was doing the enterprisy thing. Sigh.
Which presumably means that all authentication is done via hardware keys (like yubi or similar).
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.
It's like Stripe for enterprise features, including SSO/SAML, Directory/SCIM, and more.
https://workos.com/docs
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.