Okta SSO Setup with Salesforce | SAML 2.0 Complete Lab

Cloud KNowledge — Sun, 05 Jul 2026 12:36:16 +0000

Okta SSO Setup with Salesforce is one of the most common—and most critical—identity projects for any organization using Salesforce CRM. This complete lab walks you through every step of configuring SAML 2.0–based Single Sign‑On between Okta (Identity Provider) and Salesforce (Service Provider). Whether you are an IAM architect, a Salesforce admin, or a DevOps engineer, this guide gives you a production‑ready Okta SSO Setup with Salesforce that you can deploy with confidence.

We cover prerequisites, My Domain enablement, Okta app creation, SAML metadata exchange, certificate handling, user mapping via Federation ID, SP‑initiated and IdP‑initiated flows, Single Logout, testing, and a full troubleshooting section. By the end of this lab, you will have a robust Okta SSO Setup with Salesforce that reduces password fatigue, strengthens security, and simplifies user access.

Prerequisites for Okta SSO Setup with Salesforce Before you start your Okta SSO Setup with Salesforce, ensure you have the following:

Okta admin access – a paid or trial business account with permissions to create applications and manage authentication policies[reference:0].
Salesforce org – any edition that supports My Domain (required).
My Domain enabled in Salesforce – this provides a unique Assertion Consumer Service (ACS) endpoint.
Admin access to both systems to create apps, upload certificates, and map users.
Federation ID field populated in Salesforce user records (or a plan to map users via email/username).
Many admins rush into the Okta SSO Setup with Salesforce without enabling My Domain first—and then wonder why the ACS URL is missing. Do not skip this step.

Enable My Domain in Salesforce Salesforce requires a custom My Domain to expose a unique SAML endpoint. Without it, your Okta SSO Setup with Salesforce will fail because Okta cannot determine where to send the SAML assertion.

Log in to Salesforce as an admin.
Go to Setup → Company Settings → My Domain.
Choose a domain name (e.g., acme) and register it.
Deploy the domain to make it active.
Once My Domain is active, your login URL will look like https://acme.my.salesforce.com. This URL becomes the foundation of your Okta SSO Setup with Salesforce.

Create the Okta Application for Salesforce Now we move to the Okta side. The fastest way to achieve a correct Okta SSO Setup with Salesforce is to use Okta’s pre‑built connector.

Log in to your Okta Admin Console.
Navigate to Applications → Applications → Browse App Catalog.
Search for “Salesforce.com” and add the integration.
Choose SAML 2.0 as the sign‑on method.
Click View Setup Instructions – this opens a page with the exact Issuer, Login URL, and Certificate that you will need in Salesforce.
💡 Pro tip: Do not build a custom SAML app unless you have a very specific use case. The pre‑built connector handles most of the heavy lifting for your Okta SSO Setup with Salesforce.

Next Sept - Click Here

Okta Security Architecture: Complete Guide to Authentication, Identity & Threat Protection

Cloud KNowledge — Fri, 03 Jul 2026 08:56:51 +0000

01
HealthInsight Authenticators
Monitor and manage authentication health across your Okta org

HealthInsight is Okta’s built-in security dashboard that gives administrators real-time visibility into the health of their authentication ecosystem — identifying risky configurations before they become vulnerabilities.

Security dashboard monitoring
Real-time authentication health monitoring with Okta HealthInsight

🏅 Health Score
Overall authenticator health score, flagging weak or deprecated methods like SMS OTP.

⚡ Risk Signals
Detects authenticators with low adoption or policy mismatches and sends alerts to admins.

🔑 Authenticator Types
Covers Okta Verify, FIDO2/WebAuthn, Email Magic Link, SMS, Voice, and hardware tokens.

🛠 Recommendations
Suggests remediation steps such as enforcing phishing-resistant authenticators org-wide.

02
Authentication Policies
Define who can access what, when, and with which authenticator

Authentication Policies allow granular, rule-based control over app access. Each policy is composed of conditions, rules, and authenticator requirements.

Conditions
User group membership
Network location (IP)
Device platform
User risk level
Time of access
Rules
Allow access
Deny access
Prompt for MFA
Require re-auth
Challenge step-up
Authenticators
Okta Verify (Push/TOTP)
FIDO2 / WebAuthn
Email Magic Link
SMS / Voice OTP
Hardware Token (TOTP)
MFA Multi-factor authentication security
Multi-factor authentication enforces layered security at every access point

03
Global Session Policy
Controls user session lifetime and re-authentication requirements across the org

Unlike app-level Authentication Policies, the Global Session Policy applies to all apps in your org. Rules are evaluated top-down; the first matching rule wins.

🕐 Max Session Lifetime
Set an upper limit (e.g. 8 hours) for how long any session remains valid.

💤 Idle Timeout
Auto sign-out users after a period of inactivity to reduce exposure risk.

🔄 Re-auth Frequency
Force re-authentication at defined intervals for sensitive workflows.

🍪 Persistent Cookies
Control “Remember Me” behavior and persistent session cookies per group.

🌐 Network Restrictions
Restrict or enforce sessions based on trusted vs. untrusted network zones.

👥 Per-Group Overrides
Different policies for different user groups — e.g. contractors vs. employees.

Best Practice: Combine a short idle timeout (2 hours) with re-authentication enforcement for sensitive applications to significantly reduce risk from unattended sessions.
04
Identity Threat Protection (ITP)
AI-powered continuous authentication and risk-based threat response

Okta’s Identity Threat Protection delivers continuous risk evaluation beyond the initial login moment — integrating with leading security tools via the Shared Signals Framework (SSF).

🔗 Threat Signals
Integrates with CrowdStrike, Zscaler, and other security tools via Shared Signals Framework.

🤖 Risk Engine
Evaluates user behavior in real-time: impossible travel, new devices, credential stuffing patterns.

⚡ Automated Actions
Force re-auth, revoke sessions, lock accounts, or alert admins based on risk score.

🚪 Universal Logout
Terminate all active sessions across all apps simultaneously when a threat is confirmed.

05
User Profile Policies
Control how user profile attributes are sourced, updated, and protected

Okta can act as the profile master or defer to AD, LDAP, or HR systems (Workday, BambooHR). Attributes can be individually locked to prevent account takeover via profile edits.

Attribute Permission
First / Last Name Read-only (sourced from AD)
Email Address User editable
Phone Number User editable (MFA use)
Department / Title Read-only (HR system)
Profile Photo User editable
Custom Attributes Admin configurable
06
Identity Providers & Delegated Authentication
Connect external identity sources and delegate authentication to trusted providers

Okta supports federation with a wide range of external IdPs via SAML 2.0, OIDC, and native integrations, enabling organizations to achieve SSO and MFA without migrating credentials.

SAML 2.0
Azure AD
ADFS
PingFederate
Any SAML-compliant IdP
OIDC / Social
Google
Facebook
Apple
LinkedIn / GitHub
On-Prem / Directory
Microsoft Azure AD
Active Directory
LDAP
Okta AD Agent sync
Delegated Authentication: Okta validates credentials against an external directory (AD/LDAP) without storing the password — ideal for organizations not yet ready to migrate passwords into Okta but wanting SSO and MFA benefits immediately.
1
User enters credentials in Okta
Standard login screen — no change to user experience.

2
Okta sends validation request to AD
Credentials forwarded securely to Active Directory.

3
AD responds pass/fail
The password is never stored in Okta at any point.

4
Okta issues session token
On success, Okta creates a session and applies its MFA/SSO policies.

07
Networks & Behavior Detection
Define trusted network zones and detect anomalous access patterns

Network security monitoring zero trust
Zero trust network architecture — trust nothing, verify everything

🌐 IP Zones
Define IP ranges/CIDRs as trusted or blocked. Corporate office IPs can be marked as a trusted zone.

🛡 Dynamic Zones
Use threat intelligence feeds to auto-block known malicious IP ranges in real time.

🚫 Blocklist Zones
Explicitly block specific IPs, ASNs, or Tor exit nodes from accessing Okta entirely.

📍 New City
Login detected from a city the user has never accessed from before — triggers risk signal.

💻 New Device
Access from a device fingerprint not previously seen for this user account.

✈️ Velocity Check
Impossible travel — logins from geographically distant IPs within impossibly short windows.

08
Advanced Posture Checks & Device Assurance
Evaluate device security state before granting access to critical resources

Advanced Posture Checks evaluate device security at login time and continuously. Combined with Device Assurance Policies, they ensure only healthy, compliant devices access your apps.

Endpoint device management security compliance
Device assurance policies enforce compliance across Windows, macOS, iOS, and Android

🪟 Windows
OS build number minimum
BitLocker encryption
Windows Defender active
Domain join status
Intune compliance status
🍎 macOS
macOS version minimum
FileVault encryption
Gatekeeper enabled
Jamf Pro enrollment
SIP (System Integrity)
📱 iOS
iOS version minimum
Not jailbroken
Passcode set
MDM managed
Okta Verify installed
🤖 Android
Android version minimum
Not rooted
Screen lock enabled
Play Protect active
Work profile configured
09
Device Integrations
Connect Okta with MDM, EDR, and endpoint management platforms

Okta integrates with leading MDM, UEM, and EDR platforms to pull device compliance data and enforce context-aware access policies.

MDM
Microsoft Intune
Bi-directional sync with Intune compliance data. Non-compliant devices blocked at login.

Okta Devices API ↔ Graph API
MDM (macOS)
Jamf Pro
Verifies macOS enrollment and compliance. Certificate-based device trust with Jamf Connect.

Jamf Pro API + SCEP
MDM / UEM
VMware Workspace ONE
Device compliance checks and conditional access via Workspace ONE Intelligence.

REST API integration
EDR / Zero Trust
CrowdStrike Falcon
Device risk score from ZTA evaluated as part of Okta posture checks — real-time signals.

Shared Signals Framework
Passwordless
Windows Hello
Native biometrics and PIN satisfy Okta MFA via FIDO2/WebAuthn integration.

FIDO2 / Platform Auth
Built-in Agent
Okta Verify
Okta’s own agent: device registration, TOTP, push notifications, and device health signals.

Native Okta agent
10a
Administrators & RBAC
Role-Based Access Control for Okta admins — least privilege for your identity platform

Admin Role Scope Key Permissions Risk
Super Admin Full org All actions, create admins, edit policies HIGH
Org Admin Full org All actions except creating Super Admins HIGH
App Admin Specific app(s) Manage assigned apps, user assignments MEDIUM
Group Admin Specific group(s) Manage users within assigned groups LOW
Help Desk Admin User management Reset passwords, unlock accounts, MFA reset LOW
Read-Only Admin Full org View all settings and logs — no changes LOW
Custom Admin Role Configurable Admin-defined fine-grained permissions VARIES
10b
Okta API Security
Managing API tokens, OAuth 2.0 scoped access, and API Access Management

🔑 API Tokens (Legacy)
SSWS tokens tied to an admin user. Not recommended — they don’t expire and inherit creator permissions.

✅ OAuth 2.0 / OIDC
Preferred method. Short-lived access tokens with specific scopes. Service apps use client credentials flow.

🛡 API Access Management
Okta as OAuth 2.0 Authorization Server for your custom APIs. Define custom scopes and policies.

📦 Official SDKs
Node.js, Python, Java, .NET, Go — all handle token management, retries, and pagination.

API Security Best Practices
1
Never use API tokens for automated processes. Use OAuth 2.0 service apps with the narrowest possible scopes.

2
Rotate API tokens regularly. A leaked token inherits full admin permissions.

3
Use Okta’s System Log API to monitor all API activity. Alert on bulk user operations or policy changes via API.

4
Restrict API token creation to Super Admins only. Audit who has created tokens in Security → API.

5
Implement IP allowlisting for API Access Management authorization servers to block unauthorized clients.

DEV Community: Cloud KNowledge

Okta SSO Setup with Salesforce | SAML 2.0 Complete Lab

Okta Security Architecture: Complete Guide to Authentication, Identity & Threat Protection