Okta to Acquire Auth0 for $6.5B
cnbc.com
cnbc.com
Okta's open source packages receive a pitiful amount of attention (for example: https://github.com/okta/okta-oidc-js/issues?q=is%3Aissue+is%...) with forks almost becoming a requirement. Auth0 by contrast has been "on the ball" for a long time with their offerings. Okta's interfaces have been disjointed and inconsistent, confusing to users on a scale only surpassed by Jira, while Auth0's have always been pleasant to use from a user and developer perspective.
From a personnel perspective, the two companies couldn't be more different, with Auth0 embracing a remote-first-class culture with creative interview processes, and Okta (pre-covid) being very much the opposite. I interviewed with both, and the process at Auth0 had me walk away with respect, while contrasted with Okta that left me reminded that tech hiring is broken.
I'll hold my breath for a short time that Auth0 is allowed to operate independently. Sadly I feel it'll be inevitable that they're eventually swallowed up by the mothership.
I've just completed an Okta integration, and there simply isn't much "there" there. It doesn't even really have much of a network effect. They will be one player among 5 in the space in a couple years.
I found Keycloak extremely easy to setup and work with.
You can check out my LI profile for now though ;)
I can't speak for robotdan, but am also an employee.
My opinion: we have been so busy heads down building things we haven't put together an about us page.
https://www.linkedin.com/company/fusionauth/ is pretty transparent about who works there, though.
HTH.
Part of that curiosity is because the answers so far talk about 'About'pages and similar.
What's the added benefit/trust you are looking for here?
Apologies if my question is naïve.
The answer was still just the same: I'm curious who is working on this.
So I guess pretty much just curiosity for me.
I have found out quite a few scams by looking at the about us page and researching the names on the page. Most everyone working in tech had some kind of digital trail that would take a lot of effort to fake.
If I get taken for a ride, I want to at least know who is going the driving.
https://fusionauth.io/blog/2021/03/04/congrats-auth0-okta-ac...
While I haven't interviewed with Auth0 it sounds like we both had the same experience and impression regarding Okta. You know something is off when your interview loop for an engineering role involves the President of Technology doing coding interviews and all your interviewers warn you about you about your upcoming interview with him. I thought it said a lot about the culture there.
It's like Stripe for enterprise features, including SSO/SAML, Directory/SCIM, and more.
Compared to Auth0 where you can't really control user sessions or access yourself, WorkOS makes way more sense in terms of not building all the hard auth extensions for SSO and retaining user accounts. It's great so far.
In the enterprise space, imo Microsoft is going to eat everyone’s lunch. Azure AD is pretty transformative, and their public facing stuff isn’t that far apart from what Okta does.
So it can only let people log in with Google etc, not log in with <your app> on other apps
Maybe I'm misunderstanding your use case, so correct me if I got something wrong.
It is about time for a new generation of identity systems in my opinion. This acquisition shows the risk of centralized, vendor locked-in services.
I love their startup pricing.
Compared to other choices, it's more mature and well-vetted because it forms the upstream for RedHat's SSO offering.
On the other hand, it's a big monolithic Java app, but they are making some moves to be more CNF-friendly: https://www.keycloak.org/2020/12/first-keycloak-x-release.ad...
This is a major weak point of many solution, in special how automate it.
We use Okta but to write some integration with their OIDC service, I found it much easier and secure to use the Auth0 libraries. I found Okta's support to be really lacking. And while features like Token Exchange has been in draft form for 5 years and finalized a year ago, Okta still hasn't implemented and their beta won't be ready until later this year.
Not a fan of Okta but their business model does have really good vendor lock-in.
Whereas Okta, Auth0, etc. cannot, since that is their product. So they have to charge.
Given network effects, a free auth system will always beat a paid one, except where the user is compelled to use it. (e.g. you want to use my SaaS product? You'll have to create an identity in my private auth system).
So I don't think these products (and I'll include KeyCloak which is fricking awesome) really compete as such with the FAANG offerings.
Having the auth system be your primary revenue stream means you pay very close attention to it, whether that be marketing or engineering. If it is just a freebie/side offereing you add to make your core better, well, it might lack resources or focus.
Disclosure, I work for FusionAuth.
However I don't see many web sites with a "sign in with FusionAuth" button, and I don't see any way to get such a button for my site.
Not without paying anyway - which is really my whole point. Free will always win.
You won't see a login with fusionauth button, you'll just see a login button on my website, which might give you Google, github,LinkedIn logins etc depending on what I choose.
I might say "a different approach" :) I appreciate SuperToken's SPA first stance, but FusionAuth is pretty darn customizable too: https://fusionauth.io/docs/v1/tech/themes/
Stay tuned for some major updates in the coming weeks! ;)
As a sibling comment mentioned, FusionAuth has a free offering if you self host. https://fusionauth.io/download/
My main complaint is that there is no ‘onLogin’ serverless functions hook, and how keeping additional user context through custom claims is not that straightforward.
And of course I’m pretty apprehensive about Google having the data, so best of luck to you all building OSS solutions.
As far as I could tell, Okta is a sales company. The salespeople got the fancy events, the high floors with nice views, all the budget. On my orientation day it was almost entirely sales people and only one other engineer. Also the pay was laughable compared to any of the other jobs I’ve had before or since. I didn’t even stay there 5 months, what a shit show.
Another fun story from there: I was literally the only Windows-experienced developer in the company at the time, I was sometimes approached by unrelated teams that had an issue getting something to work on Windows asking for help. I would happily help where I could, but then I got chewed out by my manager and director for doing so.
Enterprise customers are the only ones that mattered, and engineers were expected to keep our heads down and implement what was asked and nothing more.
It’s a sad day for Auth0. I got to know some people who came into Okta via acquisitions and let’s just say it’s not a fun ride.
Really? I'm shocked to hear this considering their successful IPO. Most engineers in SV get options and I would imagine those engineering options would be worth a lot 12-months post IPO.
Seems fairly par for the course?
Has title inflation followed the general trends of post-secondary grade inflation?
Tech started out as a meritocracy, and a lot of us still operate personally in a meritocratic bubble, but, generally, this hasn't applied for a long time. As a whole, tech is leading the way forward in a neo-fuedalistic form of government. These political marriages to increase one's kingdom are a common affair, and they NEVER work to end-users' advantage. They only serve to make the kings and princes of the realms involved a lot of money.
The best we tech-end-users can do is grit our teeth, and hope that the acquisition doesn't ruin a product that we love and depend on. The one I'm still waiting for the other shoe to drop on is GitHub. There's a LOT of people on this site (among many others) who crow about how Microsoft has changed, but time will tell. At the very least GitHub is going to get "FOR BUSINESS!" laced all through it. I note, for the record, that many of the high-profile Ruby people abandoned ship for Shopify after the sale. That's not usually a good sign.
Having been through a "merger of equals" of Fortune 150's -- and watching my very-good-company-to-work-for being broken up and sold for parts to float the bad company's survival -- I've learned this is all you have to do: watch who leaves and who stays. Ignore all the PR statements. They are literally worse than nothing. Watch what happens to the core tech people, and the distinct VP's. That will tell you what's really happening with the restructuring. In my company, the ring-1 exec's all cashed out their golden parachutes and left. You have to have some inside information to understand the players, so this is tough to do from an external observer's point of view.
definition: "Belief in the flawed idea that hard work and talent alone are all that’s needed to achieve success."
Thanks Todd!
That already happened, but with no negative impact on its public/free side. All we got from it are unlimited private repos, and limited github action minutes and repository storage in the free tier. I call that a win.
Also, the GitHub sale was 2.5y ago, if things would have gone wrong, we would have already seen the cracks.
Ruby devs abandoning GH is simply because they saw the writing on the wall that Ruby was not seen as long-term viable tech by MS. And from a sysadmin/SRE/devops pov, if there is one stack I hated supporting more than JVM-based deploys, it's Ruby, so I wouldn't blame them.
Let's see... it took them, what, ~7yrs to screw Bungie over and take Halo away from them? So, I guess it's still too early to tell WRT Github.
Not trying to be trite here, but it shouldn't surprise you when an organization with a lot of capital gets its way in a capitalist society - all other concerns are secondary. It's a feature, not a bug.
In the short term they could raise prices and fire developers and keep the MRR coming in to feed the main business. This was a while ago when competitors were knocking out impressive web based solutions and they still had a desktop app (this is in an area where a web based solution made a lot of sense)
[1] https://www.pingidentity.com/ [2] https://firebase.google.com/docs/auth
My thoughts are:
1) One login per day per person is the maximum number of times I would ever consider asking for authentication. This is where OAuth fails; you visit an app that wants you to authenticate, but you don't get automatically logged in. You have to click at least twice. Huge drag and I hate it to death. When I worked at Google, we had BeyondCorp and I was asked for a password and security key touch once a day and could then browse internal apps freely. I would not accept anything less. (Okta and Auth0 fail here.)
But, this requires infrastructure, like trusting client devices and their screen locks. Writing software to secure some random bring-your-own-laptop is a full-on company in and of itself, and if that fails, your whole authentication system fails. (Malware starts impersonating the human.) Google's corporate engineering got this right, but I don't have that knowledge/experience to do that myself.
2) I really like the "identity aware proxy" design. There is an internal network, your app servers run there, and the proxy bridges that to the Internet and handles all the authentication details. The proxy signs a token that says who accessed it, and the app doesn't need to care. The problem here is that no apps support this. Every open-source web application bundles 10,000 lines of code for their own IAM system, and everyone seems totally fine with this. There is no standard, really, for identity aware proxies, and therefore no way for an app to recognize a standard token. (And, apps also need to do IAM management beyond just knowing who the logged-in user is, so you need a protocol to talk to the identity provider.) Yes, OIDC tries to fix some of these things, but it really isn't ... good. It optimizes for the problem of letting you log in to StealMyEmail.com with your Google account, without compromising your entire Google account. Not what people need for their internal applications.
Anyway, I bring it up because people clearly don't like this idea. They can't run an "internal network" securely, because you see the same flaws with this architecture again and again -- chat service's link unfurler takes a malformed link and makes a GET request to an internal application and leaks data; someone's jumpbox gets compromised and their network gets completely owned; "SSL added and removed here :-)"; etc. Very few people have successfully set up internal mTLS, which you really need for the proxy model to work. So instead, they just treat each app as its own island with a set of users, and identity provider, and session tokens, etc. Okta and Auth0 handle this case really well (well, they charge you a lot of money to pretend to sync the users), and that's why they're successful. But the user experience sucks, and the application developer experience sucks, and the application operator experience sucks. Hey, everyone's happy! Give me 6.5 billion dollars!
3) Every identity provider needs some answer to the SSH problem. People have been trying to do this for more than 30 years and it continues to suck. I think it's unsolvable. But thinking it's unsolvable means you don't get any customers, so that's a problem for me ;)
4) People are very interested in add-ons that are required by standard compliance rules. To be in certain businesses, you have to have a "web application firewall", which is basically something that greps the incoming request for "DROP TABLE users" and returns an error if that's in there. Denylisting will never work, but maintaining that denylist is yet another full-time company. You'll never catch up with the established players here, at least not as a 2 person startup.
5) The product I wanted to make was a centrally-managed IDP, with little proxies you could place wherever you needed one. At my last job, this is something we tried to buy from Duo, but their product was terrible. Our software engineering team had one Kubernetes cluster, with one connection to the Internet that was easy to proxy. (We used Envoy, and I wrote an SSO auth plugin, and everything was great for us.) Our network engineering team just had VMs everywhere, with an nginx that reached out to Duo for auth. It checked the security box, but you had to log into every web app twice -- once to log into Duo, once to log into the app itself. Awful.
Anyway, I do like the model. It's easy enough to write a nginx plugin and Envoy sidecar and whatever else people want, and then have it connect over TLS to receive instructions from a central leader. The tough bit is keeping those proxies functional when the central server dies (maybe new users can't login when it's down, but people with session material should be able to keep using it). There are a few designs -- just push the session cookie to every proxy when someone logs in and have the proxy check sessions with a simple string comparison. Now you survive some types of downtime (good luck firing someone when the central server is down), but that lets a proxy administrator start impersonating other users by writing a malicious proxy, GDB-ing it, whatever. So that's no good. Another option is to use public key crypto so that the proxy operator can't mint valid tokens, but every time I think about it I feel like I have the design, then I write out the details and find that it doesn't work. (That happened just now, I thought I had it for sure, but I don't ;)
All of these details were the killer for me. The business looks tough, but the technology isn't easy either. I did get mad enough to write something for myself (https://github.com/jrockway/jsso2), but that is not something I would ever consider selling -- it's just a very simple IDP and authenticating proxy. Perfect for blocking HN users from visiting https://alertmanager.jrock.us/, but still lets me look at it from my phone. (With FaceID and not a password, of course!)
I don't know what the future here is. Companies like Tailscale have the right idea -- don't trust any endpoint, human or "server". But you have to bring your own IDP, and applications can't know which human they are talking to. (Or at least, there wasn't an API to map the Tailscale source IP address to the human username when I last looked.) And, the mesh doesn't work for people that are already happy with having an internal network. I run everything on Kubernetes, and I don't want to use some crazy CNI to make every Pod a member of the network... too much stuff can break for the 0.0001% of the time when I want to directly connect to a Pod.
I guess what happened is that nobody ever decided how things should be done, so everyone does their own thing. That makes it a difficult market for a startup to enter, because you have to hope that your opinion is shared by enough people to have a customerbase to support you.
TL;DR: Everything is awful and it makes me mad.
I have been fascinated about google's identity aware proxy design. We have adopted something similar at much smaller scale with kubernetes and sidecars, I can attest we're absolutely more productive.
12 hours is typically enough but, for the days it isn't (i.e. something breaks and I'm working over time), it becomes tiresome.
Yes. Pet peeve. I started a new web app, which was going to have to integrate with our internal SAML server. Managers in the meetings kept referring to it as our "single sign on" system. I finally heard the phrase one too many times, and stopped the discussion to clarify that a "single sign on" means you log into a system ONCE, and then it takes care of every other authentication. I pointed out that we ALL spend ALL day re-logging into everything, and that shut everyone up pretty fast.
And, yes, I'm fully aware that this sort of thing is why I'm not popular with our IT department.
Fun story. I started integrating my app with SAML, and took a couple of days to learn it. I asked for the key to their dev server for testing, and this led to a FOUR MONTH series of meetings and emails where they told me WILDLY inaccurate things, which I repeated back to make sure I understood what they were telling me, and they insisted these things were true. (Like, all I had to do was put something in my headers to "authenticate".) Around and around we went until some other manager on a call pointed out that what I repeated was WILDLY inaccurate, and I shouted, "I KNOW! THAT'S WHAT I'VE BEEN SAYING FOR FOUR MONTHS," which made my manager tell me to calm down, but which FINALLY got someone to point me to the right person, deep in the heart of India, who sent me exactly what I asked for at the start, and it worked the first time.
So, no, I don't care that I'm not popular with this group.
Ouch! That's some definition of "fun".
How crazy is using the HTTP REMOTE_USER header for this?
So you need some way for important-app to be able to recognize that the remote-user header is valid. You can use mTLS and make important-app reject connections from anything that doesn't present your proxy's client certificate. You can sign the header. The header signing is pretty popular; google's Identity Aware Proxy sends a JWT there.
I have written an auth system that's done this twice. For the first iteration I used JWT. For jsso2 I use a PASETO-signed protocol buffer. Neither of these implementations has any support in the wild, so whatever you choose, you will be modifying the code of every app you run.
There is some support in the open-source world for your suggestion; there are many pieces of OSS that support a raw username in a header. Grafana does, Dex does (allowing you to pretend this is all OIDC for apps that don't support headers). But... it's pretty insecure. It means that you trust anyone who can run apps in production or access the network to act as any human user. No serious company would accept that; you can't let random engineers pretend to be the CEO in the HR system.
(That's another argument against self-hosting auth; insider risk is higher.)
I have to re-log-in to everything, virtually every time I use it. Okta seems to have no ability to remember who I am, or even that I've used this browser 10000 times before and don't need to be Two-Factored for the 10th time today.
We ended up switching to Auth0, after we had a few calls with them. We shaved a decent amount off our costs with Auth0's Enterprise plan, and their webtask based rules worked. While the migration sucked for a bit, in the end we were much happier.
It's a flag in the web UI in Auth0.
This did not fill me with confidence.
sigh
Auth0 at least has much better docs and libraries. It feels like Auth0 at least cared more.
However, their 'Rules' system for hooking into the Auth request is abstracted at the Auth0 account level rather than the individual app level. That makes it too easy to accidentally screw up all of the apps on an account.
To make matters worse, they have 3 APIs. Two are internal with 1 html and 1 json-based. The external one is the least feature rich and is missing configuration items that make IaC a challenge (you get about 80% configured then have to make changes in the gui)
Okta as a business are a pain to deal with, and unless you meet their minimum spend requirements (which are not told to you up-front) you're screwed.
I've rolled out a ton of commercial products where we started with 1-2 users or a few units of compute, and on the basic little/no support options.
When those products succeed, and we can demonstrate that not only does it meet our needs on paper, but it actually works, and whatever flaws that exist are not big enough to stop us wanting to use it more.
AWS, Atlassian's Jira and Confluence, Sendgrid, Mailchip, Duo, and a bunch of others all started being used in orgs where this kind of thing is super low friction and easy to spin up, we plug in a credit card to get us off the ground.
Okta? Well they'll tell you the pricing up-front, that's great - what they don't tell you is that after the trial period, you can't just give them a credit card, no you need to go through the sales process. It's not until you're talking to their salesperson that you find out you can't just start with a few licenses, no, you need to meet their minimum spend figure per month.
Well, that idea was dead.
I'm reading too much into this sentence fragment and it fills me with fear.
I smell breaking domain changes in the future. They can't allow the .auth0.com tenants to operate as-is forever, which means existing tenants will get grandfathered in and eventually forced off the .auth0.com domain onto okta's domains.
I smell messy login sites in the future. I like Auth0's implementation of their Universal Login page, which didn't require JavaScript. In the quest for 'one single brand identity' someone will force a migration to Okta's login implementation instead.
That will come with changing client IDs, client secrets, M2Ms and everything else needed in their setup.
I might as well create a Jira ticket for this now.
I have limited exposure. We use them at my place of work for 2fa for our VPN. And an organization we work with uses it for authentication.
But I haven't had to use them in anything I've developed.
I'll make an exception for Office 365 / AAD when an organization has already got their userbase added, but after that I'd wager if an org is big enough to need their own federated authX, then they're big enough to deploy IdentityServer and be done with it.
Hardly surprising that it didn't stop with that, and today you can basically build an app on 100% rented hardware/software via services. So if we're already outsourcing everything else, why not identity?
A good business case is a where a company (or public department) outsources their identity system to a company that doesn't have a 24/7 emergency phone line and people can't login and it's a business emergency - but I recognize this scenario is the same as "outsourcing is cheaper than in-sourcing, but outsourcing with the same level of quality and service as in-sourcing costs more than in-sourcing". YMMV.
Lol!
Why not?
1) Company A acquires company B, promises nothing will change
2) Company A hints that company B will slowly be integrated into Company A
3) Everything Company B did becomes deprecated and migration plans are made for 70% of features to get integrated into Company A
4) Users who need the rest of 30% need to find a different service when things start to get turned off
I see no reason why this Okta/Auth0 acquisition would be different. Especially anything that is branded as Auth0 will disappear or get renamed to Okta. So at least the domain will change, which will require both infrastructure, backend and frontend changes most likely. Sucks, as the change is not needed and doesn't improve anything, it's just needed for Okta to rebrand Auth0.
To assume any product/brand is going to exist indefinitely is unrealistic unless you as a customer have that in your contract (and even then mergers break this routinely).
[EDIT:] Of course, this merger may just be a ploy to drive up the price of a future merger with one of the larger firms...
Maybe I'm biased by the large bank I currently work at, but in general, it seems like IAM is the last thing we really want outsourced/closed source and monocultured. If they lose the motivation to stay ahead of the competition, and stop responding to vulnerabilities as quickly as they ought to, it's not just their company that loses.
https://github.com/keycloak/keycloak-community/blob/master/d...
I assume you mean they'll be able to get monopolistic rents now?
The other alternative is that Auth0 customers will be forced into Okta plans and migrate to other platforms. It's happened before with other mergers.
Disclosure: I work for a competitor.
Okta, 2020 Revenue: $586M
Sailpoint, 2020 Revenue: $355M
Ping: 2020 Revenue: $224M
Auth0, 2020 Revenue: $200M
There's also Oracle ID Manager, some IBM thing etc - a bunch of other large vendors.
> Okta revenue for the twelve months ending October 31, 2020 was $768M, a 43.77% increase year-over-year. Okta annual revenue for 2020 was $586M, a 46.79% increase from 2019.
For FY2021 (that just ended: Feb 2020-Jan 2021), revenue was $835 million, an increase of 43% year-over-year.
Something I've been thinking about recently is that a full web browser is a hard dependency of OAuth2-based systems. That's 20-30 million lines of code even for the simplest systems, even though you're basically just using the browser as a form renderer and a central space to store tokens.
I feel like there's room for a simpler protocol designed to operate on HTTP plus a minimal UI language (maybe JSON-based) used to describe forms for granting access. This would make it much easier to develop for devices that don't have browsers. You could even make CLI interfaces for authorization flows.
They are aware of the issues of the browser centricity of OAuth.
It's definitely not the simpler protocol you describe, but it's one way to look at the future.
When AWS Cognito had it's outage in November, I was quite happy we went with Okta.
What do you think of the break-up of Bell Systems? https://en.wikipedia.org/wiki/Breakup_of_the_Bell_System
There are also active anti-trust investigations into Google and Facebook.
https://www.cnn.com/2020/12/17/tech/google-antitrust-lawsuit... https://www.forbes.com/advisor/investing/facebook-antitrust-...
Every major cloud also has an auth/identity product and collectively probably have more total customers at this point.
Am I the only person left on earth that hasn't lost his mind?
If you aren't a big-ish corp then yeah, there are tons of OSS ways of doing IdP that fit your specific tastes etc.
Edit: Ping Identity might be a good place to invest, they look a bit low right now, and they support cloud and on-prem.
Idaptive, another IdP (I don't know how it compares in terms of features or client base) was bought by Cyberark for a mere $70M.
If it was easy to amass this many paying customers, surely other competitors would have rushed in to compete, right?
Best to Auth0! I really hope you can maintain your company culture and excellence, but I can't risk my business on that now.
It's like Stripe for enterprise features, including SSO/SAML, Directory/SCIM, and more.
(I'm the founder.)
Edit: Here’s our launch last year: https://news.ycombinator.com/item?id=22607402
I might reach out to you with some questions about our use cases - we're in early conversations with an enterprise client who uses Auth0 for their user management, and ideally we'd be able to use their Auth0 as an IDP for SSO into our existing Django application. Would also love to pick your brain on potential solutions for B2B2C use cases - your Admin Portal concept reminds me very much of a page I've written far too often in the past :) Feel free to reach me as well at btown.hn@gmail.com.
Feel free to send me a note. (Or anyone reading this too!) I'm mg@workos.com
* Here's the SP metadata URL - upload it into Azure dashboard here ...
* Grab the "App Federation metadata URL" from the Azure dashboard and paste it into WorkOS here ... (where your app can parse the XML and grab certs, URLs etc)
And you're done.
This will get added to our Admin Portal, which is a pre-built experience for IT admins to configure SSO connections: https://workos.com/docs/admin-portal/guide/introduction
Unfortunately the metadata URL configuration path isn't universally supported. I'm hoping FastFed solves this, but all that is still in working group / pre-RFC. https://openid.net/wg/fastfed/
Somewhere in the mountains of data stored in an AWS account and all it's associated EC2 instances and backups on S3 will be credentials or information to thoroughly breach all other systems.
IMO, the answer is simple: I would rather security be done by a company where security is THE feature. In other words, I trust 1Password's security team over, say, Hulu's or something.
Password managers are still the best option for most cases, but having to put such an incredible amount of trust in a single company certainly makes me nervous.
I felt a lot safer using something like KeePass, and synchronizing the encrypted database using something like Dropbox.
There's not a central target that would get caught up in large scale attacks aside from Dropbox itself - and even if they get access to that somehow, they'd then have to care about me specifically enough to run expensive offline attacks on the encrypted database. Anyone targeting me directly with those kinds of resources already has better avenues of attack.
I don't trust password managers for sensitive data but they're fine for most web account with limited capabilities.
I made my own secret manager based on gpg/age (literally a 5 lines bash script) and I don't run it from any proprietary OS, like Mac OS X or Android. I trust my Arch Linux installation a bit more as I know which packages are installed or updated and I know what's running on it. Also I think an attack is less likely. I also have a separate system to share secrets across devices which allow me to setup a public/private keypair (+password) on every device and then share links on unsafe channels (like consumer chat applications or email).
When it comes to security, it's often a pretty good idea to put all of your eggs in one basket, and then make sure it's a really, really good basket. Unless you're certain you can make a better basket yourself -- and when it comes to auth, there are a lot of ways to make bad baskets -- it's better to use somebody else's basket.
It's not perfect, but I know I'm not an expert in auth. I use Auth0 and then get on with the rest of my work.
Sure, for a single customer it's good to have a widely used product with a big ops and security response team.
But if so many companies use a single provider, the fallout of a compromise also becomes much larger. This makes attacking the system more appealing and attracts more sophisticated adversaries, including state actors.
Also, size doesn't necessarily lead to a better, more secure product. It often does for well-run, modern IT companies.
But any familiarity with the enterprise software space is quite sobering in this regard.
To add something useful to the conversation & giving the benefit of the doubt: maybe the parent was describing a situation where an org didn't have a cohesive security plan. If half your people are using one service, and the other half are using another, you've got a problem. I suppose this can blow out in complexity, and maybe risk(?), once you're stacking services (IdP, MFA, ...).
It is written in Go and built around event sourcing for a great audit trail. We already support OIDC, Passwordless, RBAC and working on more features each day.
For those who want to run it on-prem we have a kubernetes operator ready in the next few weeks who also manages the database (cockroach).
We run our own service here https://zitadel.ch with a free tier as well
Feel free to engage with us on GitHub discussions.
[1] https://investor.okta.com/static-files/83f1811e-2f92-4c08-a1...
Auth0
200M ARR
50% Growth
120%+ Net Retention Rate
https://investor.okta.com/static-files/83f1811e-2f92-4c08-a1...
What a great acquisition. Congrats to both teams!
Great acquisition for those two, what about customers who always seem to lose when companies get acquired? The market now has less competition, people who were using Auth0 is eventually gonna have to modify their infrastructure because of this and things will become more unstable.
Sometimes they happen so a company can buy out someone so they won't have the chance to become better than them and a serious competitor.
Sometimes they happen so a company can create synergies and improve the scope of their product offerings
If this merger increases future profitability of new Okta, then you can argue there is a newer genuine market opportunity in authentication.
The VC-backed industry is all about creating new opportunities (and by definition disrupting someone else's business), and recirculating investment money, improving our economy
As in any publicly traded company - there are 2 markets at play - capital markets, and the market for the actual products
> The VC-backed industry is all about creating new opportunities (and by definition disrupting someone else's business), and recirculating investment money, improving our economy
2 words I don't see in this sentence are 'product' and 'customer'
But yeah... it does feel a little bit like that moment where you go over the top of a roller coaster...
Huh? Generally speaking, companies acquire other companies to become more valuable, not for their shares to go down. And even more so when the acquired company is a competitor.
Why do investors think this is such a backwards idea, and why did the board approve an acquisition that investors appear to be rejecting?
This is extremely unusual and the article provides zero explanation whatsoever.
But apparently Okta is also going to issue 21% new shares, diluting existing shareholders, so going down only 12% means they're actually kinda-sorta up 9%.
More explanation here:
One simplified reason for why this occurs is that the management of a company is who decides whether to make an acquisition. That management might think it's in their interest (prestige, compensation, etc.) to lead a larger, more important company. One way they can do that is by acquiring a competitor, and they might even be willing to overpay to accomplish that goal. The board of the company, often appointed by management, doesn't provide true oversight of the management's decisions.
In other words, the incentives of management are misaligned with the incentives of investors.
Management's response to this theory might be that the market (investors) doesn't understand their business, and isn't properly valuing the acquisition.
I'm more sympathetic to the first view, but I believe there's research supporting both views.
If investors really like the acquisition, they will probably buy more shares in the days/weeks ahead.
Eh? You’re either doing Oauth or you’re not? What have they decoupled?
Google Cloud (Firebase Auth), AWS (Cognito), and Azure (Active Directory) are as rock-solid as they come.
FusionAuth.io, userbase.com, and clerk.dev come to mind as well.
If it was not a MS product it would struggle to attract a market.
The only other hosted solution (other than Okta and AAD) I have ever seen at my clients is Ping. In comparison, all the other players are nowhere as nearly established.
I don't know what this means regarding costs but for my place of business we saved money versus hiring people to operate/maintain the system.
Can you shoot me a DM? I’ll “buy you lunch” aka send you a Doordash gift certificate as thanks :)
Wonder who buys them next. This will be the third time I've updated my deployments.
Cisco or Salesforce
It took me a couple of hours to get a Spring Boot application to use Auth0 as an IDP and for ID federation to AzureAD, Google, Apple, and a few other IDPs. The documentation and examples are very comprehensive, and I like how they really get the day to day problems faced by developers.
Getting anything working with Okta on the other hand took ages longer, to the point that we gave up on them to move to Auth0.
In all, this acquisition is bittersweet for me.
It's easy enough to use even for internal applications, but we're using it to integrate customer directories with our product.
We're also using it to do SSO for our product. It's much easier than trying to integrate with each of these systems.
Feather: https://feather.id
Magic: https://magic.link
Cotter: https://www.cotter.app
Where I work we are migrating to Okta, and it blows my mind that anyone thinks it is a good idea.
What do you see to be horrible about it exactly?
(Disclosure, the post that sparked the discussion is on my company's blog.)
Any small start-up is not likely to have the expertise to implement auth in a 100% spec compliant, HIPAA certified, SSO compatible manner.
It's not a de-facto BAD-THING to outsource skills outside of the niche of a business, and is likely more secure and thought-out than what would be created otherwise.
Off-the-shelf auth cost comparison • Okta: $20,000 / month • Auth0: $1,500+ / month • These are barebones services - any customization would cost extra • There is still a large implementation code when using these services
Auth0 was worth using for midsize companies sometimes. Okta is not.
I seem to recall something about raising a ticket for an export including the hashes?
Edit: Merge completed. Please resume reading!
CEO here, ask me any questions!
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
(Cases like this are an exception to the 'original source' rule in https://news.ycombinator.com/newsguidelines.html.)
(Item IDs are the definitive way to check that btw.)
got it
It's been built from the ground up for developer experience with a distinct lack of jargon, amazing customizability, an API first approach and great docs. Plus, enterprise features too, including SSO/SAML, OIDC, and more.
(I work at FusionAuth.)