I hope this gives rise to another, smaller viable party outside of Amazon, Google, and Microsoft. Perhaps I'm jaded, perhaps hopelessly biased - but I can only see this as a net negative.
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 used to work on the Okta team that made those libraries. We were a tiny team with not nearly enough people.
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.
What's sadder for our society as a whole is that, despite this comment and the GP comment, this is happening, and will be allowed to happen by regulators who won't give this a second glance. And this sort of multi-billion-dollar absorption of a "better" company by a "worse" company is almost a weekly story.
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.
> At the very least GitHub is going to get "FOR BUSINESS!" laced all through it.
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.
Been through this on a tiny scale. I won’t mention the company but basically I believe it was acquired as a short term cash cow to finance the mother company that needed cash, with the acquisition being financed by going public.
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)
> What's sadder for our society as a whole is that, despite this comment and the GP comment, this is happening, and will be allowed to happen by regulators who won't give this a second glance.
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.
> Also the pay was laughable compared to any of the other jobs I’ve had before or since.
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.
Don't know about the comp levels but the title / experience / pay seems totally whacky - a staff-level engineer with a total of 5-7 years of experience? IME this role is for very experienced ICs who don't move into management but are still key leaders.
Has title inflation followed the general trends of post-secondary grade inflation?
I have a couple friends who previously worked for Okta and they similarly lamented that the comp was shit and they treated folks poorly in the IPO process. For them, it wasn't worth it.
If you are going to use keycloak it's worth making sure their mental model matches your own. Specifically we had issues with our model of multi-tennacy, each in their own realm vs. the keycloak idea of multiple tennants in a single realm. It caused some large performance and management issues.
Ory is really interesting but not, IMO, quite there yet. There are a bunch of Kratos features that aren't there but, once they are, I think it's a really compelling option.
We used ORY fosite to write our auth service, and I have so far really enjoyed working with the lib. Feels like they aren't as focused on external users of the fosite lib though so much as their hydra solution which consumes it. The overall ORY ecosystem seems nice though, though I have not delved into it in detail past fosite.
If you're looking for next generation of identity solutions? https://magic.link is what everyone would need, provides decentralised identity, fair pricing and no vendor lock-in.
I hate this magic link flow. Its a major pain in my ass when I already have a password manager that knows how to login. Now I have to leave my browser and go to my e-mail client that will open a new tab even though I already have one open.
Have you heard of https://fusionauth.io/ ? I'm not a user of the product, but I know some of the folks behind it. Might be time for them to shine here.
Thanks for the mention. We already do see quite a few Auth0 converts. I expect to gain a lot of new customers as a result of this merger in the coming months. No complaints here.
FusionAuth looks quite interesting. I'd like to see a comparison with AzureActiveDirectoy as well as in my last company we ended up sticking with it instead of migrating to auth0/octa/servicenow. Especially because Developer self-service works very well there. I couldn't find any details about this on your website.
To me, the about us page is one of the more difficult things to fake and can at least tell you whether the company is brand new or maybe owned by a big company or just a recent startup.
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.
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.
We used WorkOS to build SSO into our app. It took about one engineer two weeks to build and test.
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.
We wanted to roll out SSO for our web app and used WorkOS.. we looked at Okta, Auth0 and others, but found the out-of-the-box nature of WorkOS really compelling. Aligned with flexibility and support for a wide-range of services, it made our life pretty easy. Recommend
Going to have to check this out tomorrow. Currently we offer SSO via Auth0; it works, but it feels messy and there’s errors I can’t seem to track down.
>"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."
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.
Was this long ago? Or is the engineering team really small compared to the company as a whole? Google says they’re ~2400 people, seems really weird for the most senior technical person in an organization of that size to be conducting coding tests with rank and file candidates.
No this was not long ago and the engineering team was large. The company was well over 2K people when I interviewed. And yes it is very weird to have the President of Technology giving coding tests during an interview loop. I met with 6 other senior engineers 4 of which had already gone over coding. Apparently this is his thing though. The purpose of this seemed to be for him to demonstrate how smart and hands-on he was. Their in house recruiter actually called me the day before the interview and said he had to "prep" me for my interview with this person.
Keycloak is fantastic. You want 2FA? Password expiry? SSO? Keycloak does it all. I can't imagine starting any product now without considering Keycloak.
Also have huge extensive experience with keycloak and highly recommend it. It’s best when used as a custom docker container (so you can add your certs) but I’ve used it to build enterprise-wide auth, department level permissions and authorization, product level auth, and even SSO to AWS console.
Okta is one of the more disappointing companies for me.
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.
I also interviewed at Okta and one of the first interviewers started the session by insulting me. Like full stop, insulted me. I threw the rest of the interview and enjoyed the free lunch.
The problem is that Google, FB, Microsoft and all the other "auth providers" are able to deliver a good and free auth service because it's subsidised by their other products.
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.
I am not sure about that. Thee same strengths that FAANG brings means that they don't have the intense focus that companies like Auth0/Okta/others bring. See how many people are complaining about Firebase and Cognito in other threads.
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.
I'm just starting a new side project, and have looked at Keycloak and fusionauth. Fusionauth has a free offering (ie, self hosted), and takes a minute to install and run. I like it a lot and am going forward with it for testing.
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.
Depending on what set of features you need, it may make sense to also have a look at SuperTokens.io. Probably not as mature but we're open source and stronger with customization of the end user experience (frontend stuff), support and ease of implemenetation.
> stronger with customization of the end user experience
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/
I’ve complained extensively about Firebase in other posts, but not about their Auth module which I think is by far the best offering in the portfolio of services. I’ve integrated it for a large enterprise customer through SAML and have had an extremely positive experience where everything just worked with about a morning of work, and I’ve not had to maintain it ever since. The client SDK is great in how it syncs auth states with the server.
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.
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.
I asked for a trial login for Okta a few years ago. They sent it to me, but it didn't work. Not great for an authentication company. Made a point to avoid them based on that experience.
What? You can use Cognito User Pools to sign-up and manage user accounts in-house. That's the core of any identity solution. You can hook up Google, Facebook, etc. as identity providers if you want to give your users a third-party sign-in option.
Maybe I'm misunderstanding your use case, so correct me if I got something wrong.
Yes, but you can't use it to allow users of your app to sign into another app or service that you don't own, using yourself as the OAuth provider. No "Sign in with MyApp" on another service/app.
I was thinking very seriously about starting this company. There were some details I could never work out, and then Covid hit, so I didn't pursue it.
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.
> One login per day per person is the maximum number of times I would ever consider asking for authentication.
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.
I thought I was the only one to get offended every time I have to relogin lol. AWS is the absolute worst, logs me out every 5 minutes.
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.
It's fine, but you need network layer authentication and authorization. You don't want someone with network access to be able to act as any user -- i.e `kubectl port-forward important-app 80; curl -H "Remote-User: the-ceo@you.io" -X DELETE localhost/fire-all-employees`
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.)
Nah. There's so little moat around the SAML/OAuth thing that there are already a half dozen startups working in the space, not to mention the offerings from the big cloud providers.
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.
If you have enterprise level needs for a full customer identity solution, especially if your company activates in Europe, let me suggest you https://www.iwelcome.com/ (disclosure: I work here as an engineer): long history (founded in 2011), very reputable companies and institutions as long term clients, superb customer support, 0 security breaches, and the delegated user management solution we have is among the best in the industry, if not the best - I personally haven't seen anything like this, even though I tried Cognito and Auth0.
I hate this. We moved from Okta a few years ago after we were basically received almost no actual real support for a bunch of issues, even though we were paying a premium cost. Nobody cares about issues on their Github, the kicker was a when we received a support response as suddenly something was no longer working after an update, we got help in the form of "We have no plans to address this anytime soon." when asking for an ETA.
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.
Can second this, Okta requires you to "contact support" to turn on basic features like email customization, and even though I'm a paying customer, I was given a multi-week estimate (after waiting a week or two) for how long it would take to enable this feature.
Yeah current Okta customer and same experience as you. I was thinking of maybe going to Auth0 but well at least this news came out before we put any serious work into planning.
sigh
Auth0 at least has much better docs and libraries. It feels like Auth0 at least cared more.
I've never dealt with Okta support but my support issue with Auth0 was top notch.
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.
I like the product but the extension points confuse me. Rules, Hooks and Actions are all more or less the same thing? I never know which one I want. What's difference between a flow and a pipeline? You definitely can't guess from the terms.
Sounds right. We use Okta for multiple AWS accounts and they "ran a bad migration" that deleted half our permissions and took a month to resolve. On top of that, nothing appeared in the audit logs.
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.
I've seen the "we cant take credit cards and just start charging" fight play out on the other end. The reason was that the sales teams objected to their commissions being bypassed, so everything had to funnel through the sales pipeline.
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.
The idea of outsourced identity is just so contradictory it makes my blood pressure shoot up when people sincerely suggest it.
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.
Welcome to the future of the internet and web! Originally everyone was supposed to run their own servers and websites, but instead we have... The cloud?
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?
That's a bad wager to make. In B2B it's not unusual for small, under-resourced companies to have big customers that all require an integration with their own identity solutions.
That’s my point: IdentityServer (for example) is what enables any org capable of running a website themselves to integrate with other OIDC-conformant identity solutions via federation without having to cede any control over their identity system.
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.
Because Okta just acquired Auth0. If we look at previous acquisitions, the usual flow is something like this:
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.
There are companies that keep purchased brands for years and years. Costs may go up as it becomes "legacy", but corporations do what makes sense.
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).
Wow. These guys were basically 1 and 2 when it comes to enterprise auth/CIAM. It's great news for the businesses, but will likely only decrease competition in the marketplace. There's a ton of second tier competitors out there with plausible offerings who are probably going to start consolidating to stay alive.
I know it doesn't cover everything Auth0 and Okta presumably provide, but Keycloak is OSS and has RedHat support, and is honestly one of the best IDPs I've ever used in terms of capabilities and friendliness. I know there's also the ory suite in the more cloud-native/recent space, though I can't personally speak to its maturity.
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.
I’ve started using KeyCloak by default for my personal projects. Once you know how to integrate it and configure it, you never have to worry about users or roles again. I haven’t used the groups feature yet but I’m optimistic considering how easy Keycloak is to configure. Overall it’s a great tool to have in your tool belt.
There's just so much value in the fact that I can run it locally, deploy it wherever, play with it and learn it for free and even feel safe enough to expose it publicly due to its maturity and backing. As long as I stick with the standards (remind yourself and your users "you build OpenID Connect clients, not 'keycloak' clients," I can even (easily) move somewhere else if I want, and now I understand Oauth2/OIDC better and probably have a much more scalable authn/z system in place thanks to the way federated authn asks you to design your (fine-grained) authz.
Huh, I'm pretty sure it's present by default (not behind a flag) in current versions of Keycloak - would have liked to use it but our setup is so heavily firewalled tokens wouldn't make it over ;)
Please make a write up about using it - my current use of keycloak doesn't fit webauthn (clients access it from virtual workstations that don't have usb access) but I'd like to incorporate it further in my toolbox for future projects
It might be better for these two to merge than for either (or both!) to be subsumed into those much larger firms. This is why FTC allowed Sirius and XM to merge: to keep them both out of the clutches of larger firms who would have seriously considered killing satellite radio altogether.
[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...
Cognito and Firebase are bush league by comparison. They can do the basics well enough if you have the right integration engineers. Okta and Auth0 are light years ahead.
The difference is that Okta/Auth0 is never going to be the only piece of a solution. With AWS it's more than just Cognito, you have to consider IAM and SSO as part of the equation as well. And if you're a pure AWS shop the AWSness of Cognito (or its direct support in API Gateway, etc.) might make you prefer it to Okta or Auth0 regardless of feature parity. For Google the key asset is really Gmail/GSuite/Workspace, which is the primary identity provider for many, many organizations (and the sole identity provider for most of those). However kludgy Google's built in SAML stuff is there is a huge value in only needing to deal with one entity.
They're not really doing the same thing but you're probably correct that most customers are just relying on AD. I can easily imagine MS beefing up their identity offering to be more on par with Okta.
We replaced Okta with Azure AD. AAD had better OIDC and SCIM support along with being _significantly_ less expensive -- plus we had to use it anyways due to M365/Azure, so Okta offered no value.
I think you quoted the wrong number for Okta's revenue. The first hit on Google said:
> 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.
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.
Azure AD B2C for customer IAM is lagging way behind Okta/Auth0 etc. Sure AAD is great enterprise users or B2B but millions of customer login, branding, app experience B2C sucks.
If Cognito is the AWS offering you're talking about then it doesn't even begin to compete. It's really a terrible product and AWS has misled us about the roadmap multiple times specifically in relation to multi-region support.
When AWS Cognito had it's outage in November, I was quite happy we went with Okta.
I think tpmx means antitrust isn't currently much of a thing in the US, and I agree. Today's antitrust environment is a far cry from even the days of Bell.
Identity is a very sensitive area with strict cryptography and compliance requirement regarding password hashing, token signing etc. Then they have to keep updated with ever changing OAUTH/SAML standards and integration with providers like Facebook/Google etc. They have to get audited and certified like ISO 27001, HiTRUST etc. These are very expensive to manage and high risk for non-tech companies (think banks, insurance, utilities etc.) and hence are outsourced.
Whilst there certainly are great OSS solutions most big-ish corps already have Active Directory. You can setup ADFS to do SAML for SSO or you can use Azure AD which already has all that out of the box.
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.
Not more expensive than Looker at ~$6000pcm.
Also Looker is category leader whereas Auth0 is struggling to compete against cloud-provider supplied solutions (Cognito/Google Auth).
Oof, I really like Auth0 and was thinking of adopting them soon. Now it just seems like a huge risk. Why would I willfully walk into what will obviously be a migration nightmare and unknown pricing change for one of the central and critical pieces of my application (which should be boring to maintain)?
Best to Auth0! I really hope you can maintain your company culture and excellence, but I can't risk my business on that now.
This really looks amazing! I saw your post describing your product in relation to Auth0/Okta at https://news.ycombinator.com/item?id=26070302 and it makes a ton of sense. Many (most?) enterprise-facing startups don't start out that way, and it's painful in practice (and in principle!) to be power-sold to "lift" your existing users into a solution like Auth0, just to accept SAML logins for new users. And pricing per connection is infinitely more justifiable than pricing per user, especially in that context, especially with today's acquisition removing any downwards price pressure on that per-user pricing!!!
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.
Had a quick look at your docs for integrating with Azure AD SAML https://workos.com/docs/integrations/azure-ad-saml and wondered why you don't make use of SAML metadata URLs that contain all this configuration? For example the signing certificates, ACS, Reply/ACS URL, EntityIDs are all in the metadata xml docs, so you could boil it down to:
* 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)
We're planning to push all configuration to metadata endpoints for providers who support it. There are additional benefits for refreshing SAML certificates (usually every 5 years) and dynamically adapting to other attributes changing.
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/
We are happy WorkOS customers at hopin.com :) their SDKs make integration dead easy and their team is super responsive. Thanks @grinich and all the WorkOS team!
There's something about Okta that just scares me. If Okta is ever compromised, so are the thousands of companies that rely on it for IdP. How do companies mitigate this risk? Or do they?
If Okta is ever compromised, they have a team of people working 24 hours a day to deal with it as quickly as possible. And, of course, to prevent it from happening.
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.
You are arguing from the perspective of a single company, while the parent is arguing from an ecosystem perspective.
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, ...).
I suspect that a breach of most companies AWS accounts would lead to a complete breach of that company.
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.
That's the same fear some people have about password managers...
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.
Sure, but it's not a 1-1 comparison. If Hulu gets compromised you only lose your (hopefully unique) Hulu credentials. If your password manager gets compromised a single attacker gets access to _all_ of your accounts. The security standard for a password manager is much, much higher than pretty much any other service.
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.
The problem is a password manager becomes such a valuable target. Sure, they have more security resources given the nature of their business, but it's that password management company's security staff versus a world's-sized quantity of potential bad actors, and one of those two groups has more resources than the other.
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.
Not only password managers, popular OS as well. We may extend it to hardware as well but that's even harder to tell.
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).
I have okta accounts with a few companies and they all require 2FA. I hope Okta is configured so that if Okta itself were compromised, the 2FA would still be required to leverage the authentication vectors in okta.
Office365 is larger and it was compromised. Onelogin was compromised and I had my secret keys stored in their vault. I spent all weekend rolling new keys.
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).
> 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.
Bezos apparently said one that "Your margin is my opportunity".
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'
Honestly as auth0 users we were mulling moving over to okta anyway. Auth0s offering has always been slightly rough around the edges and we end up slightly suboptimal implementations because of that.
And for those in the back that don't know, using that as a reason for an acquisition is illegal and considered anti-competitive practice, hence you'll never hear a company publicly state that reason.
Taking over a competitor is always a good idea, simply to reduce the amount of players you compete with. This is why Facebook gobbled up Instagram and Whatsapp.
I'm with you that 32x feels insane, but these are crazy times and Okta presumably had to pay a premium to take Auth0 off the market. With those stats and a compelling story (developer tools) they were probably expecting a great IPO in this market. Assuming a 20% premium to take them off the market, 32x doesn't seem that crazy with many public companies trading at 25x or more.
But yeah... it does feel a little bit like that moment where you go over the top of a roller coaster...
> Okta, whose cloud software allows office workers to access all of their apps through a secure online service, said on Wednesday that it’s spending $6.5 billion to acquire rival Auth0. Okta’s shares plunged about 13% in extended trading after the announcement.
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.
The default explanation for the share price going down is that the market thinks they're paying too much. And let's face it, $6.5B is pretty toothy. (Remember when FB paid $1B for Instagram and everybody lost their minds?)
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%.
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.
The stock literally dropped a few seconds after the press release was out. This wasn't investors reading the details and thinking "Oh, this acquisition is a disaster, let's sell our shares". It was algo funds that saw something they didn't like, and decided to trigger a bunch of selling.
If investors really like the acquisition, they will probably buy more shares in the days/weeks ahead.
For Enterprise SSO, the market that Okta focuses on, Azure AD is by far the biggest player. They get their foot in the door at companies with Office365, which then makes it a really easy move for companies to consolidate all SSO there. Other responses are commenting on features, but AAD is everywhere.
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.
> All other providers require an OAuth implementation even if you do not need SSO because of the way they’ve architected their solution. With SuperTokens, we’ve decoupled the functionality for different use cases, making it possible to only worry about the features you need.
Eh? You’re either doing Oauth or you’re not? What have they decoupled?
For example, if you require email / password auth without SSO, then we do not use open ID connect or any of the oauth flows - because those are not needed in a simple setup.
There are lots of competitors, all at varying levels of sophistication and targeting a wide variety of markets. Lots of them mentioned in sibling threads, but I work at another one that is really dev focused:
Cognito is a joke. It’s full of bugs, the hosted UI doesn’t support half the features and -- based on the change velocity I’ve seen over the last three years —- it is desperately under-resourced by AWS. The new releases always seem to be small changes (like adding a new OAuth provider) but never fixes for the major bugs.
AAD implements SAML, OIDC, SCIM, LDAP, Kerberos, FIDO2 and more. Even if it was not a Microsoft product, it would have better non-proprietary interoperability than most other SSO platforms.
We use Okta for a bunch of stuff and I do really love their product. My company did two rounds of evaluation and really loved Auth0 but their product was unfortunately too opinionated about some things which made it difficult to adopt.
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.
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.