Organizations that run Microsoft Entra ID as their primary identity provider often end up with some applications living in Okta. Rather than maintaining separate credentials, you can federate the two: users authenticate once with Entra ID, and Okta trusts that assertion to grant access to whatever it manages. This post walks through the full setup using SAML 2.0.

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 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

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 — useful, but make sure you assign them to the right groups immediately via group rules
• The SAML signing cert has an expiration date — put a reminder on your calendar well before it expires or your federation will silently break
• Add conditional access policies in Entra ID (MFA, compliant device) to enforce security controls before the assertion reaches Okta