Okta to Acquire Auth0 for $6.5B

If anyone's looking for an Auth0 alternative, definitely check out: https://magic.link/ - easy plug-n-play auth, friendly-pricing for startups

CEO here, ask me any questions!

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.

TL;DR: Everything is awful and it makes me mad.

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.

> 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.

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).