We’re excited to announce the General Availability of Social Identity Provider (IdP) support for Native Authentication in Microsoft Entra External ID. This release enables developers to integrate popular social sign‑in options such as Google, Facebook, and Apple — into native and single‑page applications that use Native Authentication. Importantly, social identity providers are supported through a browser‑delegated (web‑view) authentication flow. This approach ensures compatibility with social providers while maintaining the security posture expected of enterprise‑grade identity systems.

Clarifying native vs. browser‑delegated social authentication

Native Authentication in Entra External ID supports integrating Social Identity Providers while maintaining application‑centric user experiences.

Social sign‑in is currently supported:

After a user selects a Social Identity Provider, authentication continues in a browser‑delegated (web‑view) experience to comply with provider OAuth requirements. Subsequent authentication steps such as MFA when Conditional Access is enabled — are also completed within this delegated flow. This model enables Social IdP support in Native Authentication today. A future release will introduce native UX for post‑social authentication steps, replacing the current browser‑delegated experience where applicable.

Why Social Identity Providers matter for native apps

Consumer and external‑facing applications increasingly need to offer familiar sign‑in options such as Google, Facebook, or Apple without compromising security or standards compliance.

• When social sign‑in is required — for example, to streamline onboarding, improve conversion, or support bring‑your‑own‑identity scenarios.
• While preserving app‑centric experiences — the initial sign‑in or sign‑up screens remain native within the application.
• Without handling user credentials in application code — authentication with social providers is performed using a browser‑delegated (web‑view) flow that aligns with OAuth requirements.

Native Authentication enables developers to integrate Social Identity Providers into native experiences while maintaining security boundaries enforced by the provider and Entra External ID. Subsequent authentication steps such as MFA when Conditional Access is enabled — continue within the same browser‑delegated flow.

What’s now generally available

With this GA release, developers can now:

• Enable Social Identity Providers (such as Google and Facebook) in native sign‑in and sign‑up experiences.
• Allow users to authenticate with supported social providers using a browser‑delegated (web‑view) flow within the application.
• Leverage standards‑compliant OAuth redirect flows required by social identity providers.
• Rely on Entra External ID to issue ID and access tokens after successful social authentication—without handling user credentials in application code.

• Present a native sign‑in or sign‑up screen within the app, after which authentication continues in a browser‑delegated (web‑view) experience for:

  • The selected social identity provider (for example, Google, Facebook, or Apple), and
  • Any subsequent Entra External ID authentication steps (such as MFA when Conditional Access is enabled).

Native Authentication continues to issue tokens only after the selected social provider has successfully completed authentication through the browser‑delegated flow.

Ready to get started?

To begin using Social Identity Providers with Native Authentication, configure the provider in your Entra External ID tenant and integrate using the Native Authentication SDKs. Social sign‑in is supported through a browser‑delegated (web‑view) authentication flow.

Stay connected and informed

To learn more or test out features in the Microsoft Entra suite of products, visit our developer center. Make sure you subscribe to the Identity blog for more insights and to keep up with the latest on all things Identity. And, follow us on YouTube for video overviews, tutorials, and deep dives.