It’s common to find organizations running Microsoft Entra ID as their primary directory while also managing a set of applications through Okta. When those two systems aren’t connected, you get fragmented identity — users with separate credentials in each platform, access reviews that can’t see the full picture, and joiners/movers/leavers processes that have to be run in two places instead of one. Federate them via SAML 2.0 and that changes: users authenticate once through Entra ID, and Okta trusts that assertion to grant access to whatever it manages.

This post walks through the full setup. The technical steps are straightforward once you understand the data flow — the tricky part is keeping track of which values go where between the two systems.

Architecture

Step 1 — Create Enterprise Application in Entra ID

1. Azure Portal → Microsoft Entra ID → Enterprise applications → New application
2. Choose “Create your own application” → name it (e.g. Okta Federation) → select “Integrate any other application you don’t find in the gallery”
3. Open the app → Single sign-on → select SAML

Generate the SAML signing certificate

1. In Section 3 (SAML Signing Certificate), click Edit → New Certificate
2. Set expiration (default 3 years) → save → download in Base64 format

Also copy from Section 4 — you’ll need these in the next step:

• Login URL
• Microsoft Entra Identifier

Step 2 — Create the Identity Provider in Okta

1. Okta Admin Console → Security → Identity Providers → Add Identity Provider → SAML 2.0 IdP

Name: Entra ID Federation
IdP Username: idpuser.subjectNameId
Match against: Okta username

✓ Automatic account linking
✓ Create users (JIT provisioning)
✓ Update attributes for existing users

SAML protocol settings

# Upload the Base64 cert from Entra ID, then:
IdP Issuer URI:         [Microsoft Entra Identifier from Step 1]
IdP Single Sign-On URL: [Login URL from Step 1]
IdP Single Log-Out URL: leave blank

After saving, copy from Okta:

• Assertion Consumer Service (ACS) URL
• Audience URI

Step 3 — Complete Entra ID Configuration

Return to the Entra ID enterprise app → Single sign-on → Section 1 (Basic SAML Configuration):

Identifier (Entity ID): [Audience URI from Okta]
Reply URL (ACS URL):    [ACS URL from Okta]

Attribute claims

The default Entra ID claim namespaces map cleanly to Okta. Leave them as-is unless you have a specific reason to change them:

email:      http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
givenname:  http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
surname:    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
name:       http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

Step 4 — Map Attributes in Okta

1. Directory → Profile Editor → find the Entra ID IdP profile → Mappings
2. Clear existing mappings (set to “Do not map”) except login
3. Add custom attributes using the external names above

# Attribute definitions
email      → external: ...claims/emailaddress  → maps to: user.email
firstName  → external: ...claims/givenname     → maps to: user.firstName
lastName   → external: ...claims/surname       → maps to: user.lastName

Step 5 — Assign Users and Test

1. In the Entra ID enterprise app → Users and groups → add the users or groups who need Okta access
2. Have a test user navigate to myapps.microsoft.com, authenticate, and click the Okta tile
3. Check Okta System Log for the SAML assertion and confirm the user appears in Directory → People

Troubleshooting

Control Mapping

Federated identity isn’t just an SSO convenience — it’s how you implement centralized authentication control across a split identity environment. Each piece of this configuration maps to requirements that surface in NIST-based assessments.

IA-2 (Identification and Authentication — Organizational Users) requires that users be uniquely identified and authenticated before accessing systems. Routing all authentication through Entra ID as the single IdP satisfies this by consolidating the authentication event to one system with one audit trail rather than two independent credential stores.

IA-5 (Authenticator Management) covers the lifecycle of authentication credentials. The SAML signing certificate is an authenticator — it has an expiration date, it can be revoked, and its compromise breaks the entire federation trust. Managing it with the same rigor as any other credential is an IA-5 requirement, not just an operational best practice.

AC-2 (Account Management) requires managing accounts through their full lifecycle. JIT provisioning handles the creation side, but the more important question from a compliance standpoint is what happens when a user leaves. If the Entra ID account is disabled but the Okta account persists and still has active app assignments, that’s an AC-2 finding. Group rules in Okta that tie access to JIT-provisioned attributes help close that gap.

AU-2 and AU-12 (Audit Events and Audit Record Generation) require that authentication events are logged. The Okta System Log captures every federated login, every failed assertion, and every provisioning event. That log is your evidence trail for federated access — it should be reviewed regularly and retained according to your logging policy.

AC-19 (Access Control for Mobile Devices) — and more broadly, compensating controls for remote access — is where conditional access in Entra ID fits. Requiring MFA or a compliant device before Entra ID issues the SAML assertion means those controls fire before the user ever reaches Okta. That’s the right place to enforce them because it applies regardless of which application the user is ultimately accessing.

Key Points

• The ACS URL and Audience URI from Okta must be pasted into Entra ID exactly — no trailing slashes, no extra characters
• Attribute namespace URLs in the claim mappings are case-sensitive and must match between Entra ID and Okta’s Profile Editor
• JIT provisioning creates Okta users on first login — assign them to the right groups immediately via group rules, otherwise you’re creating accounts with no access policy attached
• The SAML signing cert has an expiration date and when it expires your federation silently breaks — MFA enforcement stops firing, authentication logging gaps out, and users either can’t log in or fall back to local credentials. Put a calendar reminder well before the expiration date and treat cert rotation as a compliance task, not just an IT task
• Configure conditional access policies in Entra ID to require MFA and device compliance before the assertion reaches Okta — this enforces security controls at the identity layer regardless of which application is being accessed downstream