Here’s the thing that has quietly annoyed every mobile developer who ever added “Sign in with Google”: the moment the user taps that button, they leave your app. The screen flips to a system browser, some Google page loads, they authenticate, and — if the deep link back into your app was configured correctly, and the OS cooperated, and the session cookie survived — they land back where they started. When it works, nobody notices. When it doesn’t, you’re reading Chrome Custom Tabs documentation at 2 a.m. trying to figure out why one Android OEM’s browser refuses to hand control back.
As of today, Entra External ID has a supported answer to that. Social identity providers — Google, Facebook and Apple — are generally available in External ID’s native authentication, using what Microsoft calls browser-delegated flows. In plain terms: the social login now happens inside a webview your app controls, instead of throwing the user out to the full system browser.
Before that sentence means anything, we need to build up from the bottom. Bear with me.
First, which product this is
Entra External ID is not Entra ID. This trips people up constantly, so let’s nail it down. Entra ID (formerly Azure AD) is your workforce directory — employees, service accounts, the tenant your Conditional Access policies live in. Entra External ID is the separate, customer-facing product: the identity layer for the people who use the thing you built, not the people who build it. It’s the successor story to Azure AD B2C, priced per monthly active user rather than per seat.
None of what follows applies to your workforce tenant. If you’re an admin who just wants employees to log in, close this tab. This is for the app you’re shipping to customers.
What “native authentication” means, and why it’s awkward
Most identity integrations are redirect-based. Your app hands the user to a hosted login page — Microsoft’s, in this case — the user does the whole sign-in dance there, and comes back with a token. The library that runs this on Microsoft’s stack is MSAL, and its default is honest and secure: open a real browser, do the OAuth flow in it, come back. The login screen is Microsoft’s, hosted by Microsoft, styled within the limits Microsoft gives you.
Native authentication throws that model out. With native auth, your app owns the UI. You draw the email field. You draw the password field. Your app calls Entra’s APIs directly to validate credentials, send a one-time passcode, complete a sign-up. The user never sees a Microsoft-branded page and never leaves your app. This is what native auth already gave you: email-and-password and one-time-passcode (email OTP) sign-in, fully inside your own screens.
That’s lovely for credentials you own. It falls apart the instant you want “Sign in with Google.”
The problem social login creates
Here’s the mechanical wall. When a user signs in with Google, they do not type their Google password into your app. That’s the entire point of the design — Google will never let you collect its passwords, and you don’t want the liability of touching them. Instead, the user authenticates on a page Google controls, Google issues a token, and that token comes back to you. This is OAuth, and it fundamentally requires a browser context, because the user has to reach a real Google-controlled surface to prove who they are.
So you have a contradiction. Native auth’s whole promise is “the user never leaves your app.” Social login’s whole security model is “the user must visit a page you don’t control.” You cannot have both by pretending. Something has to give.
The compromise: a browser-delegated webview
The answer is a webview — an embedded browser component that lives inside your app. Think of it as a browser-shaped window your app opens in the middle of its own UI. The user taps “Sign in with Google,” a webview slides up, the genuine Google login page loads inside it, the user authenticates against the real Google, and the token comes back — all without the OS switching away from your app.
That’s the “browser-delegated” part. Native auth delegates the one step it genuinely cannot own — the trip to Google, Facebook or Apple — to a browser surface, but keeps it embedded so the experience still feels like your app. Microsoft’s SDK orchestrates the handoff: your code starts the native auth flow, the SDK opens the webview at the right moment, and control returns to your native flow when the provider is done.
Why does the embedded-versus-full-browser distinction matter enough to write about? UX and reliability. The full-browser redirect is the part that breaks in weird ways: app-switch animations, deep links that don’t fire, sessions that vanish between the browser and your app, users who see a browser chrome bar appear and wonder if they got phished. The webview keeps the whole thing in one place. It looks like a modal in your app, not an exit from it. For a single-page or native app where the polish of the sign-in flow actually affects conversion, that’s the difference worth paying for.
I’ll be the grizzled voice here for a second: embedded webviews for OAuth have a complicated reputation. Google has historically been prickly about “sign in with Google” inside generic embedded webviews for security reasons. The fact that Microsoft is shipping this as GA with Google, Facebook and Apple named explicitly suggests they’ve done the integration work to keep the providers happy — but this is exactly the area to read the current documentation on before you assume any given provider or platform behaves. Provider policies on embedded views move, and they don’t ask your permission first.
Where this slots into native auth
Line them up and the picture is clean. Native authentication now covers three ways a customer can get into your app without ever leaving it:
- Email and password — you own the form, you own the flow.
- Email one-time passcode — passwordless, code to inbox, verified in-app.
- Social identity providers — Google, Facebook, Apple, now GA via the browser-delegated webview.
Same SDK, same native auth flow, three front doors. That consistency is the actual product win. Before this, offering social login in a native-auth app meant either dropping back to a redirect model or bolting on each provider’s own SDK and reconciling the results yourself. One SDK covering all three paths is genuinely less code to own.
What you integrate with
This runs on the External ID native authentication SDK — the same client library you already use for the email/password and OTP flows — not a separate per-provider SDK and not the classic full-browser MSAL redirect pattern. You configure Google, Facebook and Apple as identity providers in your External ID tenant (that’s admin-center and provider-console work: register the app on each provider’s side, drop the client ID and secret into External ID), and the SDK handles opening the webview and completing the flow. I’m deliberately not quoting method names here — check the current SDK reference for the exact calls on your platform, because inventing an API signature that’s off by one parameter helps nobody at 2 a.m.
What it costs, and which tier you need
Let’s answer the tier question directly, because people expect the Entra ID pattern — P1, P2, pick your feature set — and reach for it here by reflex. External ID isn’t sold that way. There’s one External ID product, billed on monthly active users: you pay for the customers who actually authenticate in a given month. Social identity providers are part of that base offering. No premium add-on, no separate SKU, no “social login costs extra” gate to clear. If you have External ID, you have this.
For the actual per-MAU rate and any free-tier thresholds, pull the current figures from the External ID pricing page before you put anything in a budget line — those are exactly the numbers Microsoft revises, and I won’t quote a figure that might be stale by the time you read this.
Before you ship it
A few hard constraints to design around, not discover in production:
- Tenant type. Native authentication runs in External ID external tenants only. It is not available in workforce tenants, and it is not a feature of the legacy Azure AD B2C tenants. If your customer identity still lives in a B2C tenant, this is not a drop-in — you’re looking at a move to the newer external tenant model first.
- Platform coverage. The native auth SDKs don’t cover every platform equally. Confirm your target — Android, iOS, or web/SPA — is supported for the social-IdP webview flow before you architect around it, rather than assuming parity across all three.
- Provider rules are the providers’. Each of Google, Facebook and Apple must be registered and configured on its own side, and each sets its own requirements for what it will accept inside an embedded webview. Apple’s Sign in requirements are the strictest and the most likely to bite. Read the GA post’s known-issues section for the current per-provider caveats before you commit to a launch date.
The feature is small on paper and quietly significant in practice. It removes the single ugliest seam in customer sign-in — the browser bounce — and folds social login into the same flow you already use for everything else. That’s the good kind of announcement: less a new capability to learn than an old annoyance retired.
