I've actually created this setup (in order to ditch Okta as it is far more expensive than AAD P1 if you want MFA).

You federate AAD and Okta. Sign in to Okta and it's smooth sailing into AAD-based resources like M365.

Okta puts on a good dog and pony show for execs. From a technical perspective, they're no better for corps (at least in first party auth or B2B -- I don't get into the B2C space). We found, for the apps we used, AAD as of ~4 years ago had better SCIM support (!) than Okta.

On top of getting O365 E5 + Ent Sec (I think they're just now called M365 E5) which gave us AAD P2 licenses, overall it was much cheaper than Okta. The goal was to just get MFA, which Microsoft gives away for free (with limited toggles) or in P1 licenses (with more toggles) where-as Okta wanted $6/user/month _just for_ MFA.

Microsoft puts on a terrible sales pitch, though. We were fortunate enough to have an _awesome_ Principal Program Manager spend days with us in-person answering all of our questions and explaining AAD to our IT management.

I don’t know the specific setup, but the app passes you to AAD which passes you to a SAML source (Okta in this instance, but we use Cisco Duo). The SAML provider authenticates you, sets a cookie, then sends you back to AAD, which sets its own cookie, then passes you back to the App. (Or something like that.) if the next app you sign into is an AAD app, you pass through quickly, but if the next app you sign into uses SAML directly you have a cookie set for that as well.

We use AAD for O365 and the few apps that won’t use generic SAML, but everything else uses Duo directly. The reason for this is at our O365 license level we don’t get the ability to restrict access to applications by AD group—everyone or we have to manually manage access account by account.

Identity federation can be pretty complex to set up and administer, but once the trust relationship is configured and the identity mapping set up, it's pretty transparent to use. Source: I do this for a living.