17 ms·
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
by andrew_ 6y ago
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%3Aopen+typescript 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.
- adamcstephens 6y agoRegulators should block this merger. Consolation is strangling capitalism in this country.
- jnwatson 6y agoNah. 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.
- turtlebits 6y agoAgreed, I found it hard to write integrations with Okta and ended up using Keycloak and integrating it as an OIDC client. I found Keycloak extremely easy to setup and work with.
- gabereiser 6y agoAlso 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.
- abraae 6y agoKeycloak is fantastic. You want 2FA? Password expiry? SSO? Keycloak does it all. I can't imagine starting any product now without considering Keycloak.
- neurostimulant 6y agoI wish keycloak has smaller memory footprint so I can cram it in a small vps together with other small webapps. Other than that it's excellent.
- Conan_Kudo 6y agoThere's a Quarkus-based build of Keycloak called Keycloak.X that seems to significantly improve this: https://www.keycloak.org/2020/12/first-keycloak-x-release.adoc.html https://www.keycloak.org/2020/12/first-keycloak-x-release.ad...
- neurostimulant 6y agoOh wow, I should try this version. Thanks!
- ClumsyPilot 6y agoYeah, first time I tried to start it i set 128mb limit and got nothing at all, was a little surprised
- kenm47 6y agoHave you heard of https://fusionauth.io/ 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.
- robotdan 6y agoThanks 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.
- neom 6y agoHey Dan, curious: why it's so difficult to figure out who is behind the company from the website?
- brokenwren 6y agoWe are working on that. Our new website will include a ton of information about the company, our executive team, and our culture. Stay tuned! You can check out my LI profile for now though ;) https://www.linkedin.com/in/voidmain/ https://www.linkedin.com/in/voidmain/
- mooreds 6y agoHiya, 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/ https://www.linkedin.com/company/fusionauth/ is pretty transparent about who works there, though. HTH.
- NomDePlum 6y agoI'm curious why that matters? 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.
- 6y ago
- watertom 6y agoHow will market consolidation lead to a smaller viable alternative?
- edoceo 6y agoNature abhors a vacuum
- bogomipz 6y ago>"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.
- Cederfjard 6y agoWas 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.
- bogomipz 6y agoNo 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.
- grinich 6y agoWe are doing this at WorkOS. :) It's like Stripe for enterprise features, including SSO/SAML, Directory/SCIM, and more. https://workos.com/docs https://workos.com/docs
- rogerkirkness 6y agoWe 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.
- modulus7 6y agoWe've been integrating WorkOS with our product. The directory syncing is awesome, and the docs are well sorted.
- stanmancan 6y agoGoing 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.
- pulkitpulkit 6y agoWe 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
- Spooky23 6y agoOkta 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.
- aussieguy1234 6y agoI did an integration with AWS Cognitio. It can only act as an oauth client, not a server. So it can only let people log in with Google etc, not log in with <your app> on other apps
- Riptide34 6y agoWhat? 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.
- aussieguy1234 6y agoYes, 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.
- vwpolo3 6y agoThere are already true open source alternatives on the horizon such as https://github.com/ory https://github.com/ory 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.
- eropple 6y agoOry 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.
- manigandham 6y agoAlso https://identityserver.io/ https://identityserver.io/
- tor291674 6y agoThey just went private and you need to pay $12,000/year for unlimited clients.
- msaidentity 6y agoIf you're looking for next generation of identity solutions? https://magic.link https://magic.link is what everyone would need, provides decentralised identity, fair pricing and no vendor lock-in. I love their startup pricing.
- atlgator 6y agoI wish I knew python. I would kill for the backend developer job they have open. I love IAM.
- sontek 6y agoI 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.
- hangonhn 6y ago100%. 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.
- abraae 6y agoThe 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.
- mooreds 6y agoI 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. Disclosure, I work for FusionAuth.
- abraae 6y agoFair comment. 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.
- chrisbuc 6y agoI'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.
- 6y ago
- Tsarbomb 6y agoI 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.
- OkGoDoIt 6y agoI 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.
- vecinu 6y ago> 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.
- deleted 6y ago[deleted]
- suddenstutter 6y agoAlso worked at Okta. Can confirm, pay is surprisingly shit.
- dwoot 6y agoAre the figures on Levels accurate? https://www.levels.fyi/company/Okta/salaries/Software-Engineer/ https://www.levels.fyi/company/Okta/salaries/Software-Engine... Seems fairly par for the course?
- ernsheong 6y agoThere's Ping Identity [1] and Firebase Auth [2], though Firebase is probably not as feature rich as Auth0 [1] https://www.pingidentity.com/ https://www.pingidentity.com/ [2] https://firebase.google.com/docs/auth https://firebase.google.com/docs/auth
- jrockway 6y agoI 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 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/ 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.
- rizpanjwani 6y agoAuth0 is such a joy to work with due to their simple processes and amazing documentation! I hope auth0 continues to do well.
- tudorconstantin 6y agoIf 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/ 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.
- advaitruia 6y agoHave you seen SuperTokens.io? Its open source authentication. Maybe not as mature as Amazon, Google and Okta but we'll get there!
- jonplackett 6y agoWe use Okta at work. 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.
- faichai 6y agoI 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.
- oftenwrong 6y agoAuth0's GitHub account and documentation basically sold me when I was comparing auth services.