Okta: comprehensive scim allowing your IT instead of random application admins throughout your company to manage user provisioning / deprovisioning. Start pages that don't require users to remember urls but instead show them a list of applications they can use. Adaptive MFA with IT-administered settings (though Google's super-enterprisey solutions may have sth here.)
There's also OneLogin, Jumpcloud, or you can use Google Workspace and I think Azure AD too.
Not sure that "security" should be the top reason for switching from Okta to AzureAD.
Also, as a "user" (in IT), AAD is a royal PITA to use, with stupid limitations, such as not supporting group hierarchies. And don't even get me started on the horrid UX of the Azure portal. I've never used Okta in any capacity, though, so I don't know if it's any better.
Also - never having worked for a company that hosted their own - what's the experience like - with Okta, you can essentially SSO onto hundreds (thousands?) of different cloud service providers. Similiar if you self-host?
Not saying you can do better, just saying that you can get the same level of quality for free without paying for an incompetent & expensive snake-oil vendor.
But if you want a non-exhaustive list, there are a few lessons we can learn at Okta's expense:
Not outsource support to low-wage boiler rooms could be a good start - that's what got them their previous breach some time ago, and the current breach isn't that far off although it seems more down to the support infrastructure than the people themselves.
If you can, restrict access per IP address. Even better, if everyone works out of the office or VPNs into it, don't expose the service publicly in the first place. Defense in depth, something we seem to have forgot in the process of putting everything on the public internet.
If you see an existing session token suddenly show up with a different user-agent and IP address (not matching previous usage patterns or expected wifi-to-mobile handover), invalidate the session and ask the user to reauth again.
If possible, high-value accounts need to be IP restricted in the first place to known IPs or at least subnets (if the employee is on a dynamic IP).
If you use Okta, every single Okta support person is a super-admin in your environment with access to every role in every app. It is trivial to do better than that.
It would be nearly impossible to achieve this level of compliance certification if it were this simple and this broken.
to the list of Okta certifications in your bookmarks? You absolutely did not do a search for it just now because that is a stale link so there is no way you even clicked through that link before pasting it and you already knew what was supposed to be on that page.
This is the current link: https://trust.okta.com/compliance/
And anyways, yeah, those certifications are useless box checking garbage that a totally broken system can get.
Solarwinds has most of those same certifications: https://www.solarwinds.com/trust-center
and they are a total clown show. In fact, basically all of the clown shows have those because all most of those standards amount to is verifying your paperwork is consistent.
returns a 404, page not found. There is nothing on that page.
I replied to you at most a few hours after you posted that link. Are you going to claim that Okta updated the url in that few hour long window? For that matter, you did not even double check the link after I said it was stale or you would have used that argument in your post since it is the only credible reason to claim a dead link had contents.
I’m honestly not sure why you’re so caremad about this either, your tone is extremely accusatory over something incredibly minor.
Saying “just self-host anything” makes a massive assumption that your company can afford to compete against Okta/Google for the same talent. Some companies can, but the vast majority of Okta’s user base can’t. You would be fighting against specialization and comparative advantage.
It might be possible that there are significantly better options than Okta, but I have yet to find them.
Okta has a major insider threat problem though (either their employees/subcontractors get pwned like last time, or their infra gets pwned like now). I would expect much better from a "security" vendor, and since they consistently fail at it, I wonder what else they fail at that we don't (yet) know.
> has behavior analysis features to detect login/session anomalies
This is what baffles me. Given the description of the attack some attacker reused a stolen session token from a different IP address (not sure if they bothered to spoof the UA) - how was this not immediately challenged, especially for a high-value account? I indeed expected this to get flagged immediately.
> that your company can afford to compete against Okta/Google for the same talent
Not sure about Google, but given the (repeated!) breaches, Okta can't compete for talent either, or that talent isn't actually everything.
A big advantage of self-hosting is that you reduce your exposure to opportunistic and "for the lulz" attacks - if someone breaches Okta, it's trivial for them to automatically pwn everyone. If you self-host, they'd have to know you exist and target you specifically - that doesn't scale. Plus you can layer extra security on top such as VPN and then your IdP is invisible from the outside and a potential attacker would first need a VPN exploit before they can even do the initial recon to find out what's your IdP and its vulnerabilities. Can't do that with Okta.
The consistent pattern of breaches and their nature makes me believe they are not a serious vendor worthy of the price or the trust people put in them, and missing a better option I'd rather self-host - all else being equal, at least it would save on the fees.
I have always found this argument so interesting. I host tens of services myself on a Raspberry Pi, with better uptime than many of your favorite cloud services. If a company cannot find even one person, earning a software salary, to host an open source IDP for tens or hundreds of employees, either something is deeply wrong with the company, the sysadmin talent pool, or both.
Companies learn the same lessons painfully when it comes to build-vs-buy. There is no such thing as "buy". There is "build", and there is "buy-and-build". Purchasing and deploying (or in executive speak, "implementing") a particular solution is at best 30% of the work - and less than that of the cost. The remainder goes into integrations, maintenance, customisations, ongoing configuration, adapting to ongoing user behaviour changes, adapting to ongoing development needs, etc.
Running an IdP is one of the very few ventures where four nines of reliability is still inadequate. Once you have a centralised auth, it CAN NOT break.