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.
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.
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)
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.
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?
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.
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.
I love their startup pricing.
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.
You can check out my LI profile for now though ;)
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.
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.
The answer was still just the same: I'm curious who is working on this.
So I guess pretty much just curiosity for me.
https://fusionauth.io/blog/2021/03/04/congrats-auth0-okta-ac...
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.
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.
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.
I found Keycloak extremely easy to setup and work with.
[1] https://www.pingidentity.com/ [2] https://firebase.google.com/docs/auth
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.
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.
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.
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.
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.
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".
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.
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'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.
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.