EvrixC.38453 (Customer) asked a question.
Federation between Okta and Entra ID
Hi community,
Scenario
- Today we have ~10 enterprise applications registered in Microsoft Entra ID.
- 7 applications will be migrated to Okta over time.
- 3 applications will remain in Entra long-term (Microsoft 365, Azure, Dynamics).
- Okta is planned to become the primary IdP.
- Users should be provisioned from Okta to Entra.
Target user experience
- User tries to access Azure / M365 → Entra redirects to Okta.
- User authenticates in Okta.
- Access to Azure/M365 is granted based on group membership in Entra.
- Once an application is migrated to Okta, users access it directly via Okta (no Entra in the flow).
My current understanding (please correct if wrong)
- From the Entra side, the correct model is federated domain (SAML 2.0)
- Entra acts as a service provider, Okta as the primary Identity Provider. (Okta determines who you are and how you prove your identity)
- Users are linked between Okta and Entra using ImmutableID (preferred).
- Okta is the source of truth for users and groups, provisioning users into Entra.
- Granular migration is done by: keeping Microsoft first-party apps in Entra, moving non-Microsoft apps to Okta one by one, controlling access via assignments and policies, not by changing the IdP per app.
Questions to the community
- Best practices for granularity during migration (per-app, per-group, per-policy)?
- Any reason to prefer External Identity ENTRA and EAM over classic federated domain in this scenario?
Would really appreciate hearing from anyone who has implemented a similar hybrid phase.
Hi @EvrixC.38453 (Customer) , Thank you for reaching out to the Okta Community!
If your goal is to implement Okta as the source of truth, then you will need to leverage the M365 WS-Federation model which will make Okta the IDP and for Entra Authentication and from there also leverage the Provisioning features to push users and assign groups/licenses to users.
You will have to keep in mind that the federation will be all-or-nothing, so you will have to account for admin/service accounts.
Some details in these articles:
Excluding a Service Account from Okta Login Prompts on an O365 WS Fed Domain
How to Continue Using Office 365 Service Accounts after the Domain was Federated with Okta
As for the apps, the Microsoft apps will fall under the blanket WS-FED and the third-party apps migration will be up to you. If you want to move them to be managed by Okta, then you will have to implement Okta as the IDP for each one of them. This blog has some advice about a more seamless migration.
I strongly recommend going over the implementation documentation/FAQs to make sure you are prepared. If you already have an account with us, also reach out to your Okta Account executive to discuss the implementation, perhaps they can put a resource at your disposal that can go over things with you.
It's a high-impact deploymnet with a complex implementation, but once it's done the daily overhead should be minimal.
If my answer helped, remember to mark it as best to increase its visibility for other members of the Okta Community who might have the same questions as you.
Hope my answer helps!
--
Help others in the community by liking or hitting Select as Best if this response helped you.
Collect them all. Learn a new skill and earn a new Okta Learning badge.
Just released: More Okta Community badges just added