AzureAD
Error while signing in: Browser required. Use acquireTokenInteractively instead.
MSAL Version
2.0.0
Description
I’m attempting to use native authentication with a user flow (email + password) in my application.
I believe I’ve configured all the necessary settings correctly, including enabling native authentication and mobile/desktop flows. I am actually using a sample from Azure Samples: https://github.com/Azure-Samples/ms-identity-ciam-native-auth-ios-sample?tab=readme-ov-file
However, when I try to sign in, I receive the following error:
"Error while signing in: Browser required. Use acquireTokenInteractively instead."
I'm looking for guidance on why this might be occurring and how to resolve it.
Error Details
I have followed the below MSAL doc for implementing the Native Authentication in my iOS App. https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-native-authentication-ios-sign-in
MSAL Logs
Signing in with email ********** and password MSAL: TID=1608244 MSAL 2.0.0 iOS Sim 17.5 [2025-06-24 07:32:25 - DE474181-7123-46E5-9F4A-808A23703F6B] [MSAL] SignIn started MSAL: TID=1608244 MSAL 2.0.0 iOS Sim 17.5 [2025-06-24 07:32:25 - DE474181-7123-46E5-9F4A-808A23703F6B] [MSAL] Sending network request: (not-null), headers: (not-null) MSAL: TID=1608204 MSAL 2.0.0 iOS Sim 17.5 [2025-06-24 07:32:26 - DE474181-7123-46E5-9F4A-808A23703F6B] [MSAL] Received network response: (not-null), error (null) MSAL: TID=1608204 MSAL 2.0.0 iOS Sim 17.5 [2025-06-24 07:32:26 - DE474181-7123-46E5-9F4A-808A23703F6B] [MSAL] Parsed response: (not-null), error (null), error domain: (null), error code: 0 MSAL: TID=1608243 MSAL 2.0.0 iOS Sim 17.5 [2025-06-24 07:32:26 - DE474181-7123-46E5-9F4A-808A23703F6B] [MSAL] SignIn: an error occurred after calling /initiate API: MaskedError(MSAL.MSALNativeAuthSignInInitiateValidatedErrorType, 5) SignInStartDelegate: onSignInStartError: <MSAL.SignInStartError: 0x600002128500>
Reproduction Steps
- Download the Sample(https://github.com/Azure-Samples/ms-identity-ciam-native-auth-ios-sample?tab=readme-ov-file)
- Follow the steps from readme, like creating application and user flow.
- Run the App and try signing in
Expected Behavior
it shouldn't be asking for web browser, instead it should either login or throw some proper error. That web-browser requirement error doesn't make sense in native authentication
Regression
No response
Screenshots & Screen Recordings
Additional context
No response
Hi Raja, thanks for reaching out. "Browser required" is a proper error of the MSAL SDK, you can find more details here. Couple of questions:
- Did you create the user you're using to sign in using the native authentication SDK?
- Did you complete the prerequisites steps described here on Microsoft learn?
No, I didn’t create the user I’m trying to sign in with using the Native Authentication SDK. It’s actually my official email address. When I attempt to sign up using this email, I receive the message: “User already exists.”
I’ve already completed all the prerequisite steps outlined in the official documentation for “Sign in users in a sample iOS (Swift) mobile app by using native authentication.”
I’ve created a user flow with the Email + Password option.
Added my application to the user flow.
And I’m using the correct App ID in the configuration, along with the subdomain of my external tenant.
Please let me know if there’s anything I might have missed or if additional configuration is needed.
Note: The reason I’m using my official account is because the "Supported account types" setting for the app I created is configured as "My organization only."
Regarding the first point — I understand that "Browser required" is a valid error returned by the MSAL SDK. However, I’m a bit surprised that native authentication is prompting a browser-based flow. My intention is to provide users with a fully native sign-in experience, without redirecting them to a web view or system browser.
Could you help clarify why the SDK is falling back to an interactive browser flow, despite native authentication being configured?
One minor update I missed earlier — the value of error.isBrowserRequired is true.
I’ve attached a screenshot for your reference.
Thanks for the information @RajaNeox . Could you try creating a new user with native authentication? This will help us determine whether the issue is specific to that individual user.
About your note here:
Note: The reason I’m using my official account is because the "Supported account types" setting for the app I created is configured as "My organization only."
I suppose you're referring to the "Supported account types - Accounts in this organizational directory only", right? This setting allows all user and guest accounts within your tenant to access the application you created, so using your "official account" specifically isn't required.
About your question here:
Could you help clarify why the SDK is falling back to an interactive browser flow, despite native authentication being configured?
I'm happy to clarify. The "browser required" error acts as a fallback to enhance the resilience of client apps using native authentication by allowing them to switch to browser-based authentication. This situation arises when native authentication alone cannot complete the process. For example, if an administrator sets up a user flow that involves email and code verification, and the application doesn't support this, a "browser required" error is triggered. Instead of blocking the user from signing in, you can address this error by opening a browser to facilitate sign-in. This isn't mandatory but is an additional safeguard we provide.
@nilo-ms Thanks for your time and support!
Sure, I’ll try creating a new user with native authentication and let you know the outcome. Just to confirm—should the admin first invite me to access applications within the organization, and then I proceed with creating the user for testing native authentication?
Yes, you're right. I mentioned my official account to clarify that I'm using a regular user account (not a guest) under the same tenant where the app is registered.
Thanks for the clarification—understood. However, my scenario is a bit different, as I'm using a different user flow than the one you described.
@RajaNeox
Sure, I’ll try creating a new user with native authentication and let you know the outcome. Just to confirm—should the admin first invite me to access applications within the organization, and then I proceed with creating the user for testing native authentication?
No, the admin should not invite you first to access the application. Please create the user the same way your customer would—by using the mobile application with native authentication. Could you try creating a new user (one who hasn't been invited by your admin) through the mobile app? Specifically, the app should instantiate the MSALNativeAuthPublicClientApplication and call the method signUp(parameters:MSALNativeAuthSignUpParameters, delegate: SignUpStartDelegate).
Sure, I’ll try creating a new user with native authentication and let you know the outcome. Just to confirm—should the admin first invite me to access applications within the organization, and then I proceed with creating the user for testing native authentication?
No, the admin should not invite you first to access the application. Please create the user the same way your customer would—by using the mobile application with native authentication. Could you try creating a new user (one who hasn't been invited by your admin) through the mobile app? Specifically, the app should instantiate the
MSALNativeAuthPublicClientApplicationand call the methodsignUp(parameters:MSALNativeAuthSignUpParameters, delegate: SignUpStartDelegate).
Thank you for the guidance @nilo-ms
I wanted to clarify one point regarding the sign-up process using the mobile application. Currently, my app registration is configured with "Supported account types" set to "My organization only". As I understand it, this configuration typically requires that users already exist in the directory in order to authenticate.
However, your instructions suggest creating a new user through the mobile app using native authentication—specifically, without the user being invited first by an admin.
Could you please clarify how this is expected to work in this setup?
Looking forward to your insights.
No problem @RajaNeox . I can replicate the issue on my side now. The issue is that you are attempting to sign in using native authentication with a user account that was created via an "invite." To resolve this, the user should be created through the native application, and in the Microsoft Entra portal, the account should be marked as a "local account."
I wanted to clarify one point regarding the sign-up process using the mobile application. Currently, my app registration is configured with "Supported account types" set to "My organization only". As I understand it, this configuration typically requires that users already exist in the directory in order to authenticate.
Could you let me know where you got this information? This setting allows only users within your tenant to access your application. Read more here.
Could you please clarify how this is expected to work in this setup?
Please, follow instructions here. In brief, open the sample app, select "Email + Password" or "Email + code" tab (it depends by your user flow settings), set an email (one it hasn't been invited by your admin), set a password, press "SignUp". Follow instructions on sample app.
No problem @RajaNeox . I can replicate the issue on my side now. The issue is that you are attempting to sign in using native authentication with a user account that was created via an "invite." To resolve this, the user should be created through the native application, and in the Microsoft Entra portal, the account should be marked as a "local account."
I wanted to clarify one point regarding the sign-up process using the mobile application. Currently, my app registration is configured with "Supported account types" set to "My organization only". As I understand it, this configuration typically requires that users already exist in the directory in order to authenticate.
Could you let me know where you got this information? This setting allows only users within your tenant to access your application. Read more here.
Could you please clarify how this is expected to work in this setup?
Please, follow instructions here. In brief, open the sample app, select "Email + Password" or "Email + code" tab (it depends by your user flow settings), set an email (one it hasn't been invited by your admin), set a password, press "SignUp". Follow instructions on sample app.
Thanks a lot @nilo-ms, I was able to successfully sign up and sign in a local account user—one that wasn't invited by the admin—using the Native Authentication sample app. I simply used an email address that hadn’t been invited (e.g., [email protected]), and it worked.
However, this result surprised me.
If the app is configured with "Accounts in this organizational directory only (Single tenant)", I expected that only users from our Azure AD tenant could sign in. So I’m confused: How was a non-invited, external email like [email protected] able to sign up and sign in, while the invited users (User 1 and User 2) are unable to log in?
I'm attaching an image for reference:
User 3 (a local account) can sign in
User 1 and User 2 (invited users) cannot
Could you please help clarify how this behavior aligns with the "single tenant" configuration? Also, is there any configuration setting that governs who can register or sign in as a local account?
Thanks a lot @nilo-ms, I was able to successfully sign up and sign in a local account user—one that wasn't invited by the admin—using the Native Authentication sample app.
@RajaNeox glad you were able to use native authentication to signUp and signIn.
If the app is configured with "Accounts in this organizational directory only (Single tenant)", I expected that only users from our Azure AD tenant could sign in.
When you set your application to "Accounts in this organizational directory only (Single tenant)", only users from your tenant can access it. However, an external tenant can include various user types. Internal accounts, which are added by invitation, are usually admins of your application and won't use native authentication. For more details about user types in external tenants, please see this resource. You may also want to review this document for an introduction to Entra External ID, external tenants, and customized sign-in methods.
It looks like this issue has been resolved, so I will mark it as closed. Thank you, @RajaNeox
@nilo-ms I sincerely appreciate your time and effort in understanding the issue and guiding me on how to use the feature correctly. Thank you for helping clarify my concerns and pointing me in the right direction.