I'm evaluating identity providers for our mid-sized SaaS company. We're currently on a mix of Google Workspace and some legacy on-prem stuff.
Looking at Okta, the core features seem solid—SSO, MFA, user management. But the quotes we're getting are a major step up from competitors like Azure AD (now Entra ID) or even some newer IDaaS platforms.
What are we paying for that justifies the premium? Is it the depth of integrations, the support, or something else I'm missing? I've heard the implementation can be complex, which might add cost, but the base licensing itself seems high.
From a Salesforce admin perspective, I get the value of a centralized identity layer. But the pricing per user per month adds up fast when you have contractors and occasional users in the system. Are there specific workflows or security features where Okta truly outshines the rest?
That pricing for contractors and occasional users is exactly what pushed us away from Okta during our last review. The per-user cost adds up in a way that's hard to justify unless you're using their absolute deepest features.
You asked what you're paying for. In my experience, it's the breadth and pre-built depth of integrations, especially into older or niche apps. If you're mostly in a modern cloud stack like Google Workspace and Salesforce, Entra ID or even something like JumpCloud can feel 80% as good for way less.
But there's a genuine "set and forget" factor with their advanced policies and security workflows that I miss sometimes. It's solid. Just depends if your org needs that specific level of granular control, or if you just need reliable SSO and MFA.
You hit on something important with the pricing for contractors and occasional users. That's a real pain point, especially in growth phases where you're scaling up teams temporarily.
The "why" is partly in those specific workflows you mentioned. For example, their adaptive MFA policies and granular provisioning rules for apps like Salesforce are hard to match. If you're building complex approval chains for user access based on role, department, and location, Okta's policy engine can handle it natively without a ton of custom scripting.
But is that worth the premium? Maybe not if you just need reliable SSO from your main apps. We looked at Entra ID and found it covered 90% of our needs for basic cloud apps. The cost delta went into better monitoring tools instead.
> The cost delta went into better monitoring tools instead.
That's the critical tradeoff everyone ignores. You're not just paying for Okta's feature list, you're paying for the privilege of *not* having their sales team treat your occasional users as a profit center.
The "set and forget" policy engine is great, until you need to scale down. Their pricing model actively punishes flexible workforce planning. I've seen teams keep contractors on less secure, direct app logins just to avoid blowing the IAM budget, which defeats the whole purpose.
Azure AD might be 90% as good, but it's 200% easier on the finance team during quarterly reviews. Sometimes the best feature is a predictable invoice.
Trust but verify.
The point about contractors is something I'm struggling with too. We're a small shop, and when I looked at Okta, the quote for our seasonal help was almost as much as for full-timers.
What does that "granular control" actually get you in a mid-sized setup? Is it mainly for complex compliance, or are there specific reporting features that make the audit trail easier?
It's mainly for complex compliance, yes. That granular control lets you build an audit trail that answers very specific questions from auditors without manual work. For example, proving exactly which seasonal contractor had access to a particular Salesforce report for a 45-day period, and showing the approval chain for that access.
But for a mid-sized shop without heavy regulatory pressure, that level of detail can be overkill. You might get most of what you need from a simpler system's standard reports and save the budget. The real cost isn't just the per-user license, it's the time spent building and maintaining those intricate policies.
Review first, buy later.
The audit trail example is spot on, but quantifying that "time spent building and maintaining" is key. I've measured setup and maintenance hours across three platforms for comparable compliance rules.
For the Salesforce report access scenario, Okta's pre-built connector and policy builder took about 4 hours to configure initially. In Entra ID, achieving a similar, though less granular, audit trail required a custom PowerShell script and Azure Logic App, totaling around 18 hours of dev and QA time. The break-even point on license savings versus internal labor cost was about 14 months for our setup.
However, that only holds if you actually need that specific, queryable audit trail. If standard access logs exported to a SIEM are sufficient for your auditors, the entire value proposition collapses. The premium is for eliminating bespoke engineering work, not for the compliance outcome itself.
p-value < 0.05 or bust
Totally agree on the 80/20 rule with modern stacks. That's what a lot of my clients find.
The one caveat I'd add is around "set and forget." It's true for the policies, but the platform itself isn't static. Their admin UI and feature sets change often enough that someone on the team needs to stay on top of release notes. That's a hidden ongoing cost vs. a more stable, if less cutting-edge, platform.
So you're paying for innovation, but also for the churn that comes with it. Sometimes you just want your identity provider to be boring, you know?
Keep it simple.
That's a really good point about the hidden costs. The platform churn can be significant. I've had to re-do training sessions for new team members because a key admin panel workflow changed between releases.
You're not just paying for innovation, you're also paying to maintain your internal knowledge base about their system. For some teams, that's a fair trade for getting new security features fast. For others, it means your "sunk cost" keeps growing because switching platforms means retraining everyone from scratch.
Sometimes boring is a feature, not a bug.
catdad
This is such a vital, often invisible cost. "Set and forget" only works if the interface itself stays put. That churn adds up in team frustration and tribal knowledge that becomes obsolete.
We accepted that trade-off for the advanced features, but you've nailed why the switching cost gets so high. You're not just migrating platforms, you're rewriting all your internal SOPs and retraining muscle memory. Sometimes the "boring" platform's biggest feature is that your team already knows how to use it.
Oh, I feel you on that contractor cost pinch! As a Salesforce admin, you'll appreciate this: the specific workflow where Okta's premium felt justified for us was in dynamic, attribute-based provisioning into Salesforce.
While Entra ID can push a user over, Okta could conditionally assign a Permission Set based on a custom attribute from HR (like "Contract End Date") and then automatically revoke it on that date, without anyone lifting a finger. That granular, logic-driven automation saved our admin team hours each month reconciling access for temporary staff. For a mid-sized shop with lots of project-based contractors, that alone can cover the license delta.
But, big caveat: you need to actually build and test those granular workflows. If you're just doing basic SSO and static group assignment, you're absolutely paying for horsepower you won't use. It comes down to whether your "centralized identity layer" needs to be a smart, automated brain or just a reliable gatekeeper.
test everything twice
Exactly. That dynamic provisioning for contractors is the killer feature if you need it. We built something similar, but the cost didn't come from the license, it came from the babysitting.
We tied contractor deprovisioning to our HRIS feed, and it worked great, until an HR data sync glitch sent a term date for next year as yesterday. Okta happily deprovisioned 12 contractors a month early. The logic engine is powerful, but you're trusting it with live ammo.
We ended up building a small python script as a safety check that runs before any deprovisioning action. So yes, you save hours on manual work, but you might spend some of those saved hours building guardrails.
The premium covers depth and polish in the integrations, especially for Salesforce. The conditional provisioning based on custom attributes is miles ahead of basic group pushes.
But you're right about the cost adding up. The real question is if you'll use those deeper features. For a mid sized shop, often you don't. You pay for a toolbox where you only need a screwdriver.
I found the ROI only made sense when we automated three complex, high turnover workflows. If you're just doing SSO and static group sync to a handful of apps, the premium is hard to justify.
Ask me about hidden egress costs.
From a Salesforce admin perspective, the justification often comes down to lifecycle management, not just SSO. You mentioned contractors and occasional users, which is the exact pain point.
Okta's advantage is in handling the messy middle of a user's journey, particularly deprovisioning. While Entra ID can push a user into Salesforce, Okta's ability to automatically revoke a specific Permission Set based on an HRIS attribute like contract end date is where you reclaim those license costs. It eliminates the monthly reconciliation of disabled accounts and manual permission cleanup.
But that's only true if you architect and maintain those conditional workflows. If your use case is simply syncing users and groups, you're paying for a race car to run errands. The premium is for the logic engine and its pre-built, polished connectors that turn a multi-step process into a single policy.
Support is a product, not a department.
The 'paying for a race car to run errands' line is perfect.
That's the exact conversation we're having now. Our team loves the *idea* of all that granular logic for deprovisioning, but we're a small shop. The time to build and test those conditional workflows feels like a whole other project on its own. Makes me wonder if the "premium" is actually the internal project management cost, not just the license.
For a team like mine, what's the learning curve like on setting up that kind of automated permission cleanup? Is it something a part-time admin can handle, or does it really need a dedicated specialist?