I tested Entra’s new native-to-webview SSO. Here’s which handoff actually wins

Nothing tanks a checkout funnel like forcing users to log in twice. Microsoft's new GA feature passes native app sessions to embedded web views without a prompt—closing the last UX gap in mobile CIAM.

Mo Wasay7 min read

Nothing tanks a checkout funnel like a login screen the user thought they’d already cleared. They signed into your iOS app three days ago with Face ID. Now they tap Complete purchase, an embedded web view slides up because your payments and promo-code logic lives on the web, and — surprise — there’s a sign-in box. Same brand, same user, same session five seconds ago. Different context. Re-authenticate, please.

That seam is exactly what Microsoft closed today. Single Sign-On from native apps to embedded web views in Entra External ID Native Authentication is now generally available. If you don’t build CIAM apps this means nothing to you, so let me be blunt up front: this is External ID, Microsoft’s customer identity offering. It is not workforce Entra ID. If you’re securing employees, close the tab.

Still here? Good. Because this GA quietly settles a fight that’s been running since Native Authentication shipped, and it’s worth walking through the two contenders side by side — not on a feature grid, but on the things that actually cost you sleep.

First, what Native Authentication even is

Traditionally, a mobile app that uses Microsoft identity does browser-delegated auth. MSAL hands sign-in off to the system browser — ASWebAuthenticationSession on iOS, Chrome Custom Tabs on Android — the user authenticates on a Microsoft-hosted page, and a redirect drops a token back into your app. Secure, but it looks like a browser popped up in the middle of your beautifully designed app. Because it did.

Native Authentication is the alternative. It’s an API-driven flow: your app draws every pixel of the sign-up and sign-in screens itself, and talks directly to a set of Entra endpoints to move the user through the states — start, challenge, verify, token. No redirect. No browser chrome. The user never leaves your UI. A rough sketch of the sign-in exchange:

request.httpHTTP
POST https://{tenant}.ciamlogin.com/{tenant}/oauth2/v2.0/initiate
Content-Type: application/x-www-form-urlencoded
​
client_id={app-id}
&[email protected]
&challenge_type=oob password redirect
​
# → returns a continuation_token, then you /challenge, then /token

The payoff is total brand control and a login that feels like part of the app instead of a detour. The cost — and here’s the crux — is that you’ve walked away from the shared browser cookie that made SSO trivially easy everywhere else.

The two ways to get a signed-in user into a web view

Say your app is native for the good stuff and web for the rest — checkout, a support portal, a partner-run rewards page. The user is authenticated natively. How does the embedded web view know that?

Contender A — Browser-delegated SSO. Use MSAL’s system-browser flow. The auth cookie lives in the shared web session, so when your web view (or the browser) hits Entra, the session is already there and the user sails through. SSO for free, essentially.

Contender B — Native Authentication + the new web-view SSO handoff. Keep your custom native login, and use today’s GA feature to pass that session into an embedded WKWebView or Android WebView without a prompt.

Before today, Contender B had a hole in it. You could build a gorgeous native login and then fall off a cliff the moment a web view appeared, because Native Auth kept its tokens in the app’s private MSAL cache — invisible to any web content. Your options were re-prompt (bad) or bolt the system browser back on for the web bits (defeats the point). That hole is now filled.

Round 1 — Brand and UX control

Not close. Native Authentication owns every pixel; browser-delegated hands you a chrome bar and a domain the user notices. If you’ve ever had a designer ask why the login “looks different from the rest of the app,” you already know this round. Point: Native Auth.

Round 2 — The handoff itself

This is the round the GA was built to win. The mechanics, in plain terms: the native app already holds a refresh token from the Native Auth sign-in. When it’s time to open the web view, MSAL mints a short-lived authorization code scoped for the web context and seeds the web view’s opening navigation with it. The web app completes its OIDC exchange against Entra silently — the code is already in hand, the session already proven — and gets its own tokens for API calls. No visible redirect. No second password. The user sees a web page load, nothing more.

Example.swiftSwift
// Conceptual — after native sign-in, acquire the code for the web view
let result = try await nativeAuthResult.getAccount()
let ssoUrl = try await result.getWebFallbackUrl(
    targetUrl: "https://shop.contoso.com/checkout"
)
webView.load(URLRequest(url: ssoUrl))
// The embedded web app completes OIDC silently and calls its APIs

Browser-delegated gets SSO too, of course — that was always its whole appeal. But it earns SSO by living in the shared browser session in the first place, which is precisely the thing you gave up to get a native login. So on a like-for-like basis — you want a custom native login and a clean web-view handoff — Contender A can’t play. Point: Native Auth. This is the round that flipped.

Round 3 — Security posture

Here the browser flow has the stronger story, and I won’t pretend otherwise. The system browser isolates auth from your app process, benefits from the platform’s anti-phishing and cookie protections, and never lets your app touch the credential surface. Native Authentication puts the login inside your app, which means the security burden of the input UI is now partly yours — you’re responsible for not doing something daft with what the user types.

The web-view handoff is designed sensibly: it passes a single-use authorization code, not a long-lived token, and the web app redeems it against Entra under its own client. That’s the right shape. But an embedded WKWebView is a bigger trust surface than a system browser, full stop — you control the JavaScript running next to that session. Point: browser-delegated.

Round 4 — Effort and rollback

Browser-delegated is less code and less to maintain; the platform does the heavy lifting. Native Auth means you build and own sign-up, sign-in, password reset, error states, throttling messages — all of it. And rollback matters: if a browser-flow release misbehaves, you’re mostly reconfiguring a user flow server-side. If your custom native login has a bug, you’re shipping an app-store update and waiting on review. Point: browser-delegated.

I turned it on for a week

I wired the web-view SSO into a test app — native sign-in with email plus one-time passcode, then an embedded web view for a mock checkout. The honest verdict: the handoff is the boring kind of good. It just works, the web page loads already-signed-in, and there’s no flicker of a login form. That flicker is the whole enemy, and it’s gone.

What bit me was everything around it. Native Auth today covers email/password and email OTP cleanly; social and federated identity through this path is thinner than the browser flow, so check your IdP mix before committing. Token lifetimes between the native cache and the web session need thought — decide deliberately what happens when the native refresh token is revoked while a web view is open. And the app-store-review rollback tax is real. Plan your feature flags accordingly.

Setting it up

In the Entra admin center, in an External ID tenant (not your workforce one — create or switch tenants deliberately):

  1. App registrations → your app → Authentication — enable the public client and turn on native authentication for the app.
  2. External Identities → User flows — create or edit the flow, associate the native-auth app, and confirm the identity providers and attributes you actually support natively.
  3. In the flow’s SSO settings, enable web-view session sharing so the native app can seed embedded web content.
  4. Pull the latest MSAL native-auth SDK (Swift for iOS, Kotlin for Android) — the web-fallback/SSO helper is what carries the code into the web view.

On licensing: External ID bills per monthly active user, with the first 50,000 MAU free, then per-MAU above that. Native Authentication and this SSO feature don’t carry a separate SKU — they’re part of External ID. Budget on your MAU curve, not on the feature.

The verdict

Score’s 2–2, which tells you this isn’t a knockout — it’s a genuine trade. But the reader who cares about this GA has already decided they want a native-drawn login for the CIAM experience. For that person, the web-view handoff was the missing piece, and it’s now shipped and GA. If you’re building a mobile-first consumer app where the login is the brand and you mix native UI with embedded web content, Native Authentication now wins outright. The last excuse to bounce users to a browser is gone.

The one case where I’d still pick the loser: if your login surface is generic, your identity-provider mix is heavy on social and federation, and your security team wants auth isolated in the system browser — take the browser-delegated flow, write less code, and sleep better. Owning every pixel is a privilege that comes with a bill. Just make sure you’re being paid in conversion before you sign for it.