azure active directory – AADSTS50107: Requested federation realm object does not exist, when integrating Okta as an IdP for AAD

First, make sure the integration is in fact set up correctly. To use Okta as an IdP for inbound federation to AAD for guest users, you’ll want to create a new custom app in Okta:

enter image description here

Create a web platform app using the SAML 2.0 signin method with these settings:

  • Single sign on URL:
  • Use this for recipient URL and destination URL: yes
  • Audience URI (SP Entity ID):{your AAD tenant id}/
  • Default RelayState: leave this blank, but it might be possible to put something here to create a smart link maybe
  • Name ID format: unspecified
  • Application username: Email (or okta username if your okta usernames are emails)

If you stopped here, your users wouldn’t be able to sign in (they will get some generic access denied depending on how your application is deployed), and buried in the HTTP transcript of the sign-in attempt will be this:

AADSTS5000819: SAML Assertion is invalid. Email address claim is missing or does not match domain from an external realm.

To resolve this issue, you must add an attribute statement:

  • Name:
  • Name format: Unspecified
  • Value:

The documentation implies you also have to add this other attribute to tell it what to use for email addresses, but it doesn’t appear to be actually needed:

  • Name: emailaddress
  • Name format: Unspecified
  • Value:

Click on “show advanced settings” and make it look like this (note to the future, check that RSA and SHA256 are still safe, and update to something better if it becomes available):

enter image description here

Email address is somewhat special here and may not necessarily be an actual email. For best results, I’d suggest using an alias domain, especially if you already use AAD, because of what follows.

Save your app and grab the metadata file:

enter image description here

On the AAD side, you should set up your external IdP in External Identities ( In this part, you register an email address domain with the Microsoft sign-in portal and make it so that attempts to sign in with email addresses in that domain send users through Okta.

There are many pitfalls. It has to be a domain nobody is currently using for AAD, and has to match several rules ( – pertinently, either you need the domain name to match the domain name part of the passive authentication endpoint, or you need to set up a TXT record in the domain like DirectFedAuthUrl= (where the URL is the same as the one you have configured in “passive authentication endpoint”).

Create a SAML identity provider with “Domain name of federating IdP” set to the domain name you’d like users to use to log in.

Load the metadata from your file. The issuer URI should look like “”.

Set the metadata endpoint URL, or your integration will mysteriously stop working in about 10 years when the certificate expires. The URL is the same one you clicked the link to get the metadata file from earlier.

Your users access your application and it redirects them to the Microsoft account login page. They enter their email, with the domain name being the one you set in “Domain name of federating IdP”. They get sent through Okta, sign in there, and get redirected back.

Probably, they will get “AADSTS50020: User account … from identity provider … does not exist in tenant … and cannot access the application … in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account”. This is happening because you need to provision them somehow, as AAD does not infer their existence from the initial inbound SAML attesting their identity.

Irritatingly, you cannot enable user flows for self-service sign up with a SAML IdP (they only allow it for Microsoft Account and other AAD instances right now). So currently, for each user, you have to invite them as a guest user in your AAD instance ( and select “New guest user”). When you invite them, you can provision them whatever app access and AAD groups they will need to use things in your environment. Use the email address they will type at the Microsoft login prompt.

The first time they sign in, they will be sent through the consent flow. Beware; if you’ve enabled “security defaults” in AAD, they’ll also be asked to set up Microsoft Authenticator even if they are already authenticated with MFA in Okta.

And that’s it! Now your users can be sent through Okta instead of having an additional password for your AAD environment.