<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D5WR00001C6tAV0AZOkta Classic EngineAuthenticationAnswered2026-09-01T18:35:20.000Z2026-01-21T16:03:08.000Z2026-09-01T18:35:20.000Z

EvrixC.38453 (Customer) asked a question.

January 21, 2026 at 4:03 PM

Federation between Okta and Entra ID

Hi community,

Scenario

  1. Today we have ~10 enterprise applications registered in Microsoft Entra ID.
  2. 7 applications will be migrated to Okta over time.
  3. 3 applications will remain in Entra long-term (Microsoft 365, Azure, Dynamics).
  4. Okta is planned to become the primary IdP.
  5. Users should be provisioned from Okta to Entra.

Target user experience

  1. User tries to access Azure / M365 → Entra redirects to Okta.
  2. User authenticates in Okta.
  3. Access to Azure/M365 is granted based on group membership in Entra.
  4. 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)

  1. From the Entra side, the correct model is federated domain (SAML 2.0)
  2. Entra acts as a service provider, Okta as the primary Identity Provider. (Okta determines who you are and how you prove your identity)
  3. Users are linked between Okta and Entra using ImmutableID (preferred).
  4. Okta is the source of truth for users and groups, provisioning users into Entra.
  5. 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

  1. Best practices for granularity during migration (per-app, per-group, per-policy)?
  2. 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.

  • 5 answers
  • 716 views

  • Mihai N. (Okta, Inc.)

    Updating this response for ease of access and reference:

     

    Administrators migrating applications from Microsoft Entra ID to Okta require a strategy to establish Okta as the primary Identity Provider (IdP) and source of truth. Implementing the Microsoft 365 (M365) WS-Federation model allows Okta to handle Entra authentication and provision users, while third-party applications migrate individually.

     

    Applies To

    • Okta Identity Engine (OIE)
    • Okta Classic Engine
    • Microsoft Entra ID
    • Microsoft 365 (M365)

     

    Solution

    How does an administrator configure Okta as the primary Identity Provider for Microsoft Entra ID?

    To establish Okta as the source of truth, implement the M365 WS-Federation model. This configuration designates Okta as the IdP for Entra authentication. Administrators must also utilize Okta provisioning features to push users and assign groups or licenses to users in Entra.

     

    Administrators must account for service accounts and third-party applications.

    Configure the domain federation requirements and migrate the individual third-party applications to ensure a successful deployment.

    • Apply the WS-Federation implementation to the entire domain.
    • Exclude admin and service accounts to prevent lockout.
    • Manage Microsoft applications under the blanket WS-Federation configuration.
    • Configure Okta as the IdP for each individual third-party application to complete the migration.

     

    Complex deployments require thorough preparation and Okta Account Executive consultation.

    Review the implementation documentation thoroughly before beginning the deployment. Administrators should contact the Okta Account Executive to discuss the implementation and request additional resources for this high-impact deployment.

     

    Related References

     

    Summary

    Implement the Microsoft 365 WS-Federation model to establish Okta as the primary Identity Provider for Microsoft Entra ID.

     

     

     

    Regards.

    --

    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

    Expand Post
    Selected as Best

  • Mihai N. (Okta, Inc.)

    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

    Expand Post

  • EvrixC.38453 (Customer)

    Thanks for the detailed answer - it really helped, and the core setup is working as expected.

    I do have one follow-up question around the B2B scenario.

    Look like this (link)

     

    From the Entra side, could External ID (B2B) be used as an alternative approach here?

    I understand that this would result in guest users being created in Entra, but conceptually it feels like a way to introduce a second, temporary external domain into the tenant.

     

    Is this considered a valid / supported pattern in practice ?

    Expand Post

  • Mihai N. (Okta, Inc.)

    Updating this response for ease of access and reference:

     

    Administrators migrating applications from Microsoft Entra ID to Okta require a strategy to establish Okta as the primary Identity Provider (IdP) and source of truth. Implementing the Microsoft 365 (M365) WS-Federation model allows Okta to handle Entra authentication and provision users, while third-party applications migrate individually.

     

    Applies To

    • Okta Identity Engine (OIE)
    • Okta Classic Engine
    • Microsoft Entra ID
    • Microsoft 365 (M365)

     

    Solution

    How does an administrator configure Okta as the primary Identity Provider for Microsoft Entra ID?

    To establish Okta as the source of truth, implement the M365 WS-Federation model. This configuration designates Okta as the IdP for Entra authentication. Administrators must also utilize Okta provisioning features to push users and assign groups or licenses to users in Entra.

     

    Administrators must account for service accounts and third-party applications.

    Configure the domain federation requirements and migrate the individual third-party applications to ensure a successful deployment.

    • Apply the WS-Federation implementation to the entire domain.
    • Exclude admin and service accounts to prevent lockout.
    • Manage Microsoft applications under the blanket WS-Federation configuration.
    • Configure Okta as the IdP for each individual third-party application to complete the migration.

     

    Complex deployments require thorough preparation and Okta Account Executive consultation.

    Review the implementation documentation thoroughly before beginning the deployment. Administrators should contact the Okta Account Executive to discuss the implementation and request additional resources for this high-impact deployment.

     

    Related References

     

    Summary

    Implement the Microsoft 365 WS-Federation model to establish Okta as the primary Identity Provider for Microsoft Entra ID.

     

     

     

    Regards.

    --

    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

    Expand Post
    Selected as Best
This question is closed.
Loading
Federation between Okta and Entra ID