We're a SaaS company with about 150 people, and our tech stack is almost entirely on AWS. We're currently using IAM Identity Center (the successor to SSO) for our internal apps and AWS account access. It's simple and works.
But we're now evaluating Okta as we onboard more non-AWS SaaS tools (like Salesforce, GitHub) and our own customer-facing app might need SSO. The finance team likes that Identity Center is "free," but engineering has concerns. For those who've used both, what are the specific technical or operational drawbacks of sticking with Identity Center for a mid-size company? I'm especially curious about limitations in user lifecycle management, granular policies outside AWS, and audit logging compared to a dedicated IdP.
Good question. The "free" aspect is compelling, but you've hit on the right concerns. The biggest downside I've seen is the user lifecycle management outside AWS. With Identity Center, you're still managing users in something like AD or SCIM-provisioning from your HR system, but then you have to map those groups to permissions. It's doable, but it's clunky compared to the automated workflows and rich APIs a tool like Okta provides.
Also, audit logging for non-AWS applications is much less granular. You'll see the SAML assertion was used to log into Salesforce, but you won't get the detailed user behavior logs from within Salesforce itself. For compliance across your whole SaaS stack, that can become a real gap.
One more thing to consider is your customer-facing app SSO. Identity Center *can* do SAML, but building a smooth, branded, self-service portal for customers is not its strength. Okta is built for that exact use case.
— isabel
The lifecycle management gap is real, but I'd frame it as a scalability issue for your engineering team's time. At 150 people, manually mapping group memberships from your HR system to Identity Center permissions might be manageable. Once you add a dozen more SaaS apps, each with their own permission sets, that manual toil becomes a constant tax. You'll end up building and maintaining your own scripts to sync groups, which is essentially recreating a fraction of Okta's provisioning engine.
On the audit logging point, the lack of granularity extends beyond just user behavior. For compliance frameworks like SOC 2, you often need to demonstrate a clear chain of access reviews and permission changes across all integrated systems. Identity Center's logs are focused on AWS events. Correlating a permission change in Salesforce with an Identity Center group assignment change requires stitching logs from two separate systems, which is a manual, error-prone process.
For your customer-facing app SSO, using Identity Center would mean your customers are authenticating against your AWS SSO instance. This can raise questions about branding and perceived vendor lock-in during security reviews. Some enterprise clients' infosec teams get uneasy seeing an AWS-hosted IdP for a non-AWS service.
Extract, transform, trust
Yeah, the "free" part is a trap for your future self, honestly. I'm looking at this from the other side, where my last place tried to build on Identity Center to save cash.
The big shock for us was the custom app SSO. If your customer-facing app is on anything besides AWS (like a separate Vercel or Railway setup), getting Identity Center to work is a huge headache. You end up writing way more auth logic than you should. Okta just has SDKs for that.
And the permission mapping outside AWS feels like it's from 2010. Trying to manage fine-grained GitHub repo access or Salesforce roles through it? Good luck.
Still learning.
Totally agree on the audit logging gap. That bit us during a security review last year. You can see the login event in CloudTrail, but good luck proving who made that critical change inside your Jira instance. We ended up stitching together logs from a dozen different SaaS platforms, it was a mess.
One more nuance on the custom app SSO: even if your app is on AWS, like an ECS service, you still have to build the whole SAML SP logic. There's no lightweight SDK like Okta's. So you're trading a few hundred bucks a month for a ton of engineering time.
Pipeline Pilot
"Simple and works" until you add the second SaaS app that isn't AWS.
You're on AWS. You'll likely end up using Control Tower or something similar for multi-account. Identity Center is basically mandatory for that. So now you're paying for Okta and still running Identity Center for AWS account federation. Double the config, double the user store headaches.
The finance team's "free" argument misses that you'll burn a senior engineer's week every quarter hacking around provisioning scripts and custom SAML integrations. That's not free, it's just a different, more annoying cost center.
If it ain't broke, don't 'upgrade' it.
The "free" argument always misses the real math. At 150 people, you're looking at roughly one full sprint per year just to maintain the custom provisioning glue and handle audit log correlation for compliance. That's easily a $20k+ engineering tax, which probably exceeds Okta's entry tier.
And for >granular policies outside AWS<, it's worse than just clunky. Try enforcing something like "Salesforce read-only for interns, but edit for sales, with no AWS console access" through IAM Identity Center groups. You'll end up with a spaghetti of permission sets that's impossible to audit without another custom script.
Your customer-facing app is the real trap. The moment you need SCIM provisioning for customers or just a simple OIDC flow, you're building an entire identity microservice. That's not an evaluation, it's a six-month project.
pay for what you use, not what you reserve
You've framed the question correctly by focusing on the three specific gaps. Building on the audit logging point, I've observed that the lack of normalized, vendor-agnostic logs becomes a major issue during incident response. When a compromised account triggers an alert, you're forced to manually pivot between CloudTrail, your HR system logs, and each individual SaaS platform's admin console to piece together the user's access path. This triage delay, often measured in hours, is a tangible risk that doesn't appear on a cost spreadsheet.
Regarding granular policies for non-AWS apps, the limitation is architectural. IAM Identity Center's permission sets are built on AWS IAM semantics, which are fundamentally about attaching policies to roles/resources. This model maps poorly to the hierarchical, attribute-based access controls (ABAC) common in SaaS like Salesforce or GitHub. You'll be forced to use coarse-grained SAML assertions, then manage the fine-grained permissions within each application anyway, doubling the administrative burden.
The "free" argument collapses when you quantify the manual effort for user lifecycle management at your scale. With 150 people, you likely have 15-20 role changes per month. Each change requires a manual update to group memberships in Identity Center and potentially in each connected app. That's a predictable 2-3 hours per week of manual, error-prone operations work, which is a fixed and growing cost. A dedicated IdP automates this via SCIM, turning an operational task into a managed process.
Data never lies.
You're right to question the "free" part for a company your size. The three gaps you listed are exactly where it falls apart.
For user lifecycle, Identity Center just sits there waiting for SCIM feeds. You'll need a separate system (like Workday or a custom script) to actually manage users and groups, then pipe it in. That's an extra moving piece to break. Okta *is* that system.
On granular policies outside AWS, it's a fundamental mismatch. IAM permission sets are built for AWS resources. Trying to model something like "read-only Salesforce reports, plus write to specific GitHub repos" requires weird workarounds. You end up with permission sets that are basically just group tags, and the actual fine-grained control still lives in each SaaS app.
The audit logging gap is a silent time sink. When you get an alert, you're jumping between CloudTrail and a dozen different SaaS admin consoles instead of one place. That adds hours to any security incident.