Social federation—allowing users to sign in with their existing social identity providers like Google, Facebook, or Apple—is crucial for delivering seamless, user-friendly authentication experiences in modern applications. However, integrating social logins within complex identity platforms like Microsoft Entra External ID (EEID) can be puzzling, especially when documentation lacks explicit references to supporting social federation in certain authentication modes.

In this post, we unravel how EEID supports social federation through native authentication by cleverly leveraging the standard MSAL delegated OAuth2 popup flow rather than relying on the typical native auth API endpoints. This approach effectively bypasses the native auth /initiate endpoint, accommodating social identity providers’ requirement for browser redirects.

We'll walk through the architecture of this solution, unpack the core technical insights, and provide a hands-on look at the implementation details. By the end, you'll understand how to configure EEID and your client app to deliver a smooth social login experience alongside native authentication flows.

Architecture Overview

┌───────────────────────────────┐
│   User Devices & Clients      │
├───────────────────────────────┤
│ • Web SPA using MSAL.js       │
│ • Popup-based delegated flow  │
└──────────────┬────────────────┘
               ↓
┌──────────────┴────────────────┐
│   Entra External ID (EEID)    │
├───────────────────────────────┤
│ • Native Authentication APIs  │
│ • Social Identity Providers   │
│   (Google, Facebook, Apple)   │
│ • User Flows & Federation     │
└──────────────┬────────────────┘
               ↓
┌──────────────┴────────────────┐
│   External Identity Providers │
├───────────────────────────────┤
│ • Google OAuth / OpenID Connect│
│ • Facebook OAuth              │
│ • Apple Sign-In               │
└───────────────────────────────┘

This architecture highlights the flow starting from the user's device, where a SPA uses MSAL's delegated popup flow to initiate authentication against EEID. EEID manages native authentication and coordinates federation with configured social IdPs, supporting seamless browser redirects required for social sign-in flows.

Figure: The New Control Plane - The ecosystem powering federation

Key Technical Observations

• Delegated MSAL Popup Flow Over Native API Calls — Instead of invoking EEID's native /initiate auth endpoint designed for password or OTP, the code utilizes MSAL’s loginPopup() method that triggers a delegated OAuth2/OpenID Connect flow, essential for social providers requiring browser redirects.

• Use of domain_hint to Shortcut the Login Experience — By passing domain_hint=google.com in the authorization request, the flow routes users directly to Google’s federated login page, bypassing EEID’s native login UI and improving UX.

• prompt=login Enforces Explicit Reauthentication — This query parameter disables Single Sign-On (SSO) for social logins, ensuring fresh authentication every time a user signs in via a social provider, improving security and consistency.

• Social Federation as a Fallback Mechanism — Social IdPs are integrated as fallbacks to EEID’s native authentication, effectively bypassing any native auth API-driven flow that cannot handle browser redirects.

• Fine-grained Configuration on Both Client and EEID Side — The SPA config (auth-config.ts) handles clientId, authority (with tenant subdomain), and redirect URIs, while EEID must be configured with external social providers, client secrets, and user flow bindings.

• Handling CORS and Proxy Setup in Development — Due to cross-origin constraints when testing locally, developers often use a CORS proxy or disable CORS via browser extensions for development convenience. This should be handled cautiously to avoid security risks.

How It Works

Initiating Social Sign-In via MSAL Popup

When a user clicks Sign in with Google, the client code calls:

const popUpRequest: PopupRequest = {
  authority: "https://{tenant}.ciamlogin.com",
  scopes: [],
  redirectUri: "/",
  prompt: "login",
  domainHint: "google.com",
};

await authClient.loginPopup(popUpRequest);

This triggers MSAL.js to open a popup window, initiating a standard OAuth2 Authorization Code Flow request against the EEID endpoint for the tenant. The domain_hint=google.com in the query string acts as an explicit hint to route the user straight to Google, skipping EEID's generic login screen.

This approach means the native auth /initiate endpoint is never used for social logins, since social IdPs require a browser redirect flow incompatible with native API calls.

Configuring Entra External ID

On the EEID portal, administrators must:

• Register Google (or other social IdPs) as external identity providers, adding client IDs and secrets from the Google Cloud Console.
• Configure the redirect URI in Google Cloud Console to point back to EEID’s federation endpoint:

https://{tenant}.ciamlogin.com/{tenant-id}/federation/oauth2

• Ensure EEID app registration includes an SPA redirect URI and is configured for native authentication.
• Bind the social IdP to the corresponding user flow/policy to enable federated sign-in.

Running the Sample App Locally

Developers can clone the repo and run:

npm install
npm run build
npm start

or for development mode:

npm run dev

If CORS errors arise running locally, a CORS proxy setup or a temporary Chrome extension disabling CORS can help (used cautiously).

User Experience

• The user clicks Sign in with Google on the SPA.
• A popup opens for Google sign-in (via EEID's routed URL).
• After successful authentication, the popup closes, and the user is signed into EEID.
• On first sign-in, the social account is linked to an EEID user account.
• The user experiences seamless social login alongside native authentication support.

Figure: Sample UI prompt for social sign-in

Quick Tips & Tricks

1. Use domain_hint to Bypass Unnecessary Screens
   Adding domain_hint=google.com or other IdP domains directly navigates users to their chosen provider, trimming the sign-in flow and reducing friction.

2. Force Fresh Social Sign-In with prompt=login
   Avoid silent SSO reauthentication in social flows by setting prompt=login, ensuring users explicitly authenticate each time.

3. Configure SPA Redirect URIs Carefully in EEID and IdP Portals
   Redirect URIs must match exactly in Google Cloud Console and EEID app registrations to prevent authorization code failures.

4. Run a Local CORS Proxy for Development Convenience
   Cross-origin requests to authentication endpoints often block in browsers; a proxy or carefully used CORS extension streamlines local testing.

5. Treat Social Federation as a Delegated Fallback in Your Auth Flows
   Keep native authentication as primary where possible, relegating social login to flows that require browser redirected OAuth2 handling.

6. Link Social IdPs to Appropriate User Flows in EEID
   Without explicit inclusion of social providers in user flows, social federation won’t function even if configured on the portal.

Conclusion

Integrating social federation in Entra External ID via native authentication is less about calling the native auth API directly and more about leveraging MSAL’s delegated OAuth2 popup flow to meet social providers’ browser redirect requirements. This method elegantly sidesteps limitations in the native auth /initiate endpoint and ensures a frictionless UX with Google, Facebook, and Apple IdPs.

The key takeaway is the importance of combining EEID’s configuration with strategic client-side flow control such as domain_hint and prompt parameters. This approach offers a maintainable, extensible path towards broad external identity support in modern applications.

As social identity providers continue evolving and EEID expands capabilities, expect even more seamless, secure federation options that blend native and delegated authentication techniques—unlocking richer, simpler user sign-in experiences.

References

1. Using social federation via native auth in Entra External ID (Medium) — Original walkthrough by Rory Braybrook
2. Native auth social IdPs web view GA (Microsoft Devblogs) — Official Microsoft guidance on native authentication with social IdPs
3. Entra External ID - Configure Google Federation — Microsoft Docs on configuring Google federation in EEID
4. GitHub Repo: ms-identity-ciam-native-javascript-samples — Reference code base for EEID native and social federation
5. Google Cloud Console — Create OAuth credentials for social federation

Author: Rory Braybrook
Article first published August 1, 2026