Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Applies to: 
External tenants (learn more)
Browser-delegated authentication and native authentication are two sign-in approaches in Microsoft Entra External ID that define how your customer-facing app handles the authentication experience. Both approaches are fully supported, but they differ in user experience, development effort, and security model. Understanding these differences helps you choose the approach that best fits your app.
With browser-delegated authentication, your app redirects users to a Microsoft-hosted sign-in page in a system browser or embedded web view. Microsoft Entra handles the entire authentication flow, and your app receives tokens after sign-in completes. This approach requires minimal code and offers built-in branding customization.
With native authentication, you build the sign-in UI experience directly into your app by using the Microsoft Authentication Library (MSAL) SDK or the native authentication API. Users never leave your app. You control every aspect of the UI, but your team is responsible for building and maintaining the authentication experience.
When to use browser-delegated authentication
Browser-delegated authentication is the better fit when:
- Your app can accommodate a browser redirect during sign-in without disrupting the user experience.
- You prefer lower implementation and maintenance effort. Microsoft manages security updates and new features automatically.
- You want to support the broadest range of platforms and languages with less code.
For specific feature availability, see the feature comparison.
When to use native authentication
Native authentication is the better fit when:
- You need full control over the sign-in UI so it blends seamlessly into your app.
- A browser redirect would disrupt the user experience for your target platform.
- Your organization operates both the app and the authorization server, and your users perceive them as a single entity.
- Your development team can take on the additional implementation effort and ongoing maintenance.
For specific feature availability, see the feature comparison.
Feature comparison
The following table shows which features are available in each approach.
| Feature | Browser-delegated authentication | Native authentication |
|---|---|---|
| Sign up and sign in with email one-time passcode (OTP) | ✔️ | ✔️ |
| Sign up and sign in with email and password | ✔️ | ✔️ |
| Sign in with email and password can use username (alias) and password | ✔️ | ✔️ |
| Self-service password reset (SSPR) | ✔️ | ✔️ |
| Custom claims provider | ✔️ | ✔️ |
| Multifactor authentication with email one-time passcode (OTP) | ✔️ | ✔️ |
| Multifactor authentication with SMS one-time passcode (OTP) | ✔️ | ✔️ |
| Social identity provider sign-in (Apple, Facebook, and Google)1 | ✔️ | ✔️ |
| Single sign-on (SSO)2 | ✔️ | ✔️ |
1 Even with native authentication, social sign-in still uses a browser window for the identity provider step.
2 Native authentication supports SSO for embedded web views only. Cross-app SSO through system browsers isn't available with native authentication.
Supported languages and frameworks
The following languages and frameworks are supported for each approach.
| Approach | Supported languages and frameworks |
|---|---|
| Browser-delegated authentication |
|
| Native authentication |
|
Security considerations
Browser-delegated authentication is the more secure option. Microsoft manages the sign-in surface, which reduces your app's exposure to phishing and credential-harvesting attacks.
With native authentication, your development team shares security responsibility with Microsoft Entra. Your team must follow security best practices for handling user credentials. Before you choose native authentication, discuss the security implications with your app's business owner and development team.
Next steps
After you decide on an approach, register your app to continue your integration, or return to the planning guide for the full sequence of steps:
Browser-delegated authentication:
Native authentication: