IAM with Okta — Practical Overview
Practical notes from deploying Okta as the central IdP in 6 APAC enterprise engagements over the past 4 years.
When Okta is the right choice
Okta is the default recommendation for APAC enterprises that meet two criteria:
- Heterogeneous SaaS estate — multiple non-Microsoft SaaS apps that need SAML/SCIM integration
- Identity is critical enough to pay vendor pricing — typically regulated industries (finance, insurance, healthcare)
For Microsoft-heavy shops with E3/E5 already deployed, Azure AD (Entra ID) is usually a better fit — it's effectively free at that point and the integrations with M365 are tighter.
Deployment phasing
A standard Okta deployment has six phases. Skipping any of them creates technical debt.
Phase 1: HRIS source-of-truth integration The HR system (Workday, BambooHR, SAP SuccessFactors) drives identity creation and lifecycle. This is the foundation. If you start with manual provisioning, you'll never migrate off it.
Phase 2: AD sync (if applicable) For organisations with on-prem AD, the AD agent provides two-way sync. Decide early: is AD or Okta the authoritative source? In modern deployments, Okta wins; AD becomes a downstream consumer.
Phase 3: Tier-1 SaaS SSO The top 10–15 SaaS apps connected via SAML and SCIM. M365, Slack, AWS Identity Center, GitHub, Salesforce. These are well-supported and demonstrate quick wins.
Phase 4: Conditional access policies Now that users are flowing through Okta for the high-value apps, layer on conditional access: device-trust posture (CrowdStrike, JAMF), geo-fencing, risk-score thresholds, MFA requirements per app.
Phase 5: Long-tail apps The remaining SaaS apps and internal apps. SAML where supported, OIDC for modern apps, header-based auth via Cloudflare Access for legacy apps that can't speak modern protocols.
Phase 6: Privileged access integration Connect Okta to your PAM solution (BeyondTrust, CyberArk). Privileged sessions should require Okta auth + just-in-time elevation, not standing admin rights.
Common implementation traps
SCIM ≠ SAML. SAML gives you SSO. SCIM gives you provisioning. You usually want both. Many vendors charge separately for SCIM connectors, and some only support SCIM at the enterprise tier — budget accordingly.
Group structure matters. Okta groups drive everything: app access, conditional policies, privileged access. Designing the group hierarchy badly in Phase 1 will cost you a multi-week rework in Phase 4.
Device-trust is not plug-and-play. Even with vendor-supported integrations (Okta + CrowdStrike, Okta + JAMF), expect to spend 1–2 weeks on token-passing logic and edge cases. Always prototype before committing to a rollout date.
Universal Directory vs. AD-only attributes. Decide which attributes live in Okta vs. AD. Once you commit, attribute changes flow one direction only — reversing this mid-project is painful.
What Okta won't do for you
Okta is an IdP. It is not:
- A privileged access manager (use BeyondTrust or CyberArk)
- A network access broker (use Cloudflare Access or Zscaler)
- An endpoint security tool (use CrowdStrike or Defender)
- An audit/compliance reporting tool (use Splunk or your SIEM)
Treat Okta as one well-defined component in a larger architecture. It's a great IdP. It's only an IdP.