Visit Website →
← Back to blog

Avoid Redirect URI Mismatches in Azure AD B2C Mobile for Developers

September 29, 2026
Avoid Redirect URI Mismatches in Azure AD B2C Mobile for Developers

Yes, Azure AD B2C supports phone-number sign-up and sign-in for mobile apps, with SMS one-time passcodes verifying the phone as the primary identifier. Use built-in user flows for most projects; reach for custom policies only when you need UI or behavioural changes. On the mobile client, implement OAuth 2.0 Authorization Code flow with PKCE through MSAL, and plan around MFA limitations and separate SMS charges from the start.

TL;DR:

  • Built-in user flows are suitable for most projects, handling standard phone verification and recovery options without requiring XML customization.
  • Custom policies offer full control over phone verification behavior, claims, and UI, but require careful XML editing, testing, and ongoing maintenance.
  • Implementing phone sign-in with MSAL on mobile apps demands OAuth 2.0 Authorization Code with PKCE, correct redirect URIs, and matching configurations to prevent errors.
  • SMS OTP delivery varies by carrier and country, making physical testing across multiple carriers essential before releasing a deployment at scale.
  • Using push notification MFA instead of SMS can reduce costs and delay in high-volume apps, but most implementations pair TOTP apps with external APIs for best security and simplicity.
Pocketapp
Build A More Reliable Mobile App
Pocket App designs, develops, and deploys user-focused mobile applications for businesses across industries, including complex identity and authentication projects.
Discuss your mobile app

Table of Contents

Prerequisites: tenant, app registrations and billing notes

Before writing any code, get the Azure foundations right. You need an Azure AD B2C tenant (new or existing) and global administrator access to configure identity providers, user flows and app registrations. Register your mobile app, and any backend API it calls, then set redirect URIs correctly and grant the openid and offline_access scopes where your flow requires silent token renewal.

Decide early whether built-in user flows will cover your requirements or whether you need custom policies, since the latter route means pulling the Identity Experience Framework starter pack from GitHub and adapting it.

  • Provision or reuse an Azure AD B2C tenant with global admin rights for configuration.
  • Register the native mobile app and any backend API, setting redirect URIs and required scopes.
  • Choose between built-in user flows and custom policies before building anything else.
  • Budget separately for SMS OTP costs, which are billed apart from monthly active user licensing and vary by carrier.

Implementing phone sign-up and sign-in with built-in user flows

Built-in user flows get a working phone authentication journey live faster than any custom policy project, and they cover the majority of mobile use cases without touching XML.

  1. In your B2C tenant, enable Phone sign-up (or the combined Phone or email local account option) under Identity providers.
  2. Create a sign-up and sign-in user flow, selecting the phone-based local account and any social identity providers you want alongside it.
  3. Add a recovery email prompt during sign-up, so a user who loses access to their phone number still has a path back into their account.
  4. Run the flow end-to-end against a development tenant and confirm the OTP arrives on a real device, not just an emulator, since some carriers throttle or filter messages differently.
  5. Test with more than one carrier and country code where your user base spans multiple markets, since delivery times and formats can vary.

Pro Tip: Test OTP delivery on physical devices across at least two carriers before your first release; emulator testing hides delivery delays that only show up in production.

Built-in flows are sufficient when you need standard phone verification, a recovery email fallback, and Microsoft's default page layouts with light branding. Escalate to custom policies when you need to remove UI elements such as the country dropdown, change verification behaviour, or persist and manage multiple phone numbers per user, none of which the built-in flow exposes.

Custom policies and the phone-factor technical profile explained

Custom policies (the Identity Experience Framework) give full control over the phone authentication journey, at the cost of more setup and ongoing maintenance. Start from the starter pack, which includes TrustFrameworkBase.xml and TrustFrameworkExtensions.xml, then layer your changes into the extensions file rather than editing the base.

The PhoneFactor technical profile is where the real configuration happens. It defines input and output claims for the phone verification step and exposes settings including authenticationMode (sms, phone, or mixed), plus autodial and autosubmit behaviour for voice verification.

  • Set authenticationMode to sms, phone, or mixed depending on whether you want text, voice, or both offered to users.
  • Persist verified phone numbers to user profile claims so returning users are not re-prompted, and support storing more than one verified number per account where your product needs it.
  • Use the output claim indicating whether a new phone number was entered to trigger different downstream logic, such as an additional verification step.
  • Remove the country dropdown from the phone entry page through content definition overrides when you want to preselect a single country.

Pro Tip: Keep a working copy of your last deployed policy XML before every change; a single malformed claim reference can break sign-in for every user until you roll back.

Custom policy XML is unforgiving. Test each change in an isolated development tenant, use the trace tool in Application Insights or the browser network tab to inspect claims at each orchestration step, and deploy to production only after a full sign-up and sign-in pass.

Mobile client setup: PKCE, MSAL and redirect URIs

Get the mobile-side configuration wrong and no amount of correct policy XML will save the flow. Microsoft recommends the OAuth 2.0 Authorization Code flow with PKCE for mobile apps, using the Microsoft Authentication Library rather than the older implicit grant, which exposes tokens in ways PKCE avoids.

  • Implement Authorization Code with PKCE through MSAL for iOS and Android rather than implicit grant.
  • Configure MSAL with knownAuthorities and a separate authority entry per user flow or custom policy you call.
  • Set account_mode to MULTIPLE for B2C mobile apps, and register a redirect URI with a unique scheme and path per app.
  • Set authorization_user_agent to DEFAULT or BROWSER and avoid embedded WebView, which breaks some identity providers and modern security flows.
  • Exchange the authorization code for access and refresh tokens at the token endpoint, then use the refresh token for silent renewal until it is revoked.

Access and refresh tokens are obtained through the /token endpoint, and refresh tokens support silent renewal until revoked, which is what keeps users signed in across app sessions without repeated prompts. Redirect URI mismatches are the single most common cause of failed token exchanges on mobile, so confirm the registered value matches your app's scheme and path exactly.

MFA constraints and account recovery for phone-primary accounts

Phone-primary accounts create a specific gap: SMS cannot double as both the primary sign-in channel and a second factor, so Azure AD B2C limits your MFA options in that scenario. Email OTP is available by default when phone is primary, and it works, but a TOTP authenticator app gives stronger protection than either SMS or email.

  1. Prompt users to enrol a TOTP authenticator app during sign-up or at first sign-in, rather than leaving it as an optional later step.
  2. Configure the user flow to offer TOTP alongside or instead of email OTP for the second factor.
  3. Require recovery email verification at account creation, since it becomes the fallback path if a user loses their phone entirely.
  4. Build a manual support pathway for edge cases, such as a user who loses both phone and recovery email access, with identity checks before any account handover.

Pro Tip: Push TOTP enrolment during onboarding rather than after; users who skip optional MFA setup rarely come back to complete it later.

Each option trades differently: email OTP is the lowest-friction default, TOTP costs a little more onboarding effort for meaningfully better security, and manual recovery protects against lockout at the cost of support overhead. Our guide to mobile app MFA and recovery-first design covers this trade-off in more depth.

Fixing common phone authentication errors during development

Most phone authentication bugs during development trace back to a handful of repeat offenders.

  • Format handling: normalise numbers before sending them to B2C, since users will enter 07123 456789, +447123456789 and 447123456789 interchangeably; strip spaces and enforce E.164 format server-side.
  • Country dropdown confusion: the default flow shows a country selector that international users often get wrong; remove or preselect it through content definition overrides in a custom policy if your user base is single-market.
  • SMS delivery failures: test both long code and short code sending where available, and check whether the destination carrier filters messages from Azure AD B2C's sending numbers, particularly for cross-border test accounts.
  • MSAL redirect errors: a redirect URI mismatch throws immediately and is almost always a scheme or path typo between the app registration and the MSAL configuration file.
  • AADB2C90118: this error code signals a password reset request; catch it explicitly in your error handler and route the user to the reset policy rather than showing a generic failure.

Application Insights traces and MSAL's own logging are the fastest way to isolate which claim or step failed, rather than guessing from the error message alone.

Adding push notification MFA as an alternative to SMS OTP

SMS OTP works, but it is not free and it is not instant in every market. Push notification-based MFA, delivered through an authenticator app that a user approves with a single tap, sidesteps both the delivery cost and the delay that SMS can introduce in markets with slower carrier routing.

Azure AD B2C does not expose native push-approval MFA in the same way some enterprise identity platforms do, so most teams pair a TOTP authenticator app (which generates codes without needing network delivery at all) with a custom policy step rather than building bespoke push infrastructure. This gets you most of the benefit, code approval without an SMS round trip, without a custom mobile push backend.

Where a project genuinely needs push-approval MFA rather than TOTP, that logic sits outside B2C's built-in phone factor and requires a REST API technical profile calling an external MFA provider from within a custom policy. This adds real engineering effort, so it is worth reserving for projects where SMS cost or delivery reliability is already a proven problem, not a theoretical one. For most mobile apps, TOTP enrolment covers the same ground with far less build time.

Comparison of SMS TOTP and push MFA

Consider pairing either option with biometric authentication at the device level, which removes friction from repeat sign-ins without touching your B2C policy at all.

Scaling SMS OTP verification for high-volume mobile apps

SMS costs and delivery reliability become real operational concerns once a mobile app moves from pilot to scale, since SMS charges are billed separately from Azure AD B2C's monthly active user pricing and add up quickly across a large sign-up base.

A few practical levers help at scale. Cache verified phone numbers against user profile claims so returning users are never re-sent an OTP they do not need, which cuts volume immediately for any app with meaningful repeat usage. Rate-limit OTP requests per phone number and per IP address to blunt both cost spikes and abuse from automated sign-up attempts, since an unthrottled endpoint is an open invitation for SMS-pumping fraud. Monitor delivery success rates by carrier and country, because a silent failure in one region can go unnoticed for weeks if your only signal is aggregate sign-up conversion.

For apps expecting genuinely high volume, review whether TOTP enrolment can become the default second factor rather than SMS, reserving SMS purely for initial phone verification at sign-up. That single change removes the recurring cost and delivery risk from every subsequent sign-in, leaving SMS to do the one job it is actually needed for.

Designing the phone sign-in experience for mobile screens

A phone number field that works well on desktop often fails on mobile, where screen space and keyboard behaviour change the calculus entirely. Set the input field's keyboard type to numeric so users are not fighting a full alphabetic keyboard for a ten-digit number, and keep the country selector visually lightweight rather than a full-screen picker that interrupts the flow.

Autofill matters more on mobile than almost anywhere else in the sign-up journey. Both iOS and Android can detect an incoming SMS OTP and offer to autofill it directly into the input field, provided your message format follows the platform's expected pattern, so test this specifically rather than assuming it works by default. Where autofill is not available, keep the OTP field short and give clear, immediate feedback on an incorrect code rather than a generic error.

Resist the temptation to cram sign-up, phone verification and profile completion onto a single screen. Splitting these into distinct steps with a visible progress indicator reduces abandonment, particularly for users verifying a phone number for the first time in your app. Keep the resend OTP option visible but not aggressive, a 30 to 60 second cooldown before it becomes tappable prevents accidental double-sends while still giving users a way out of genuine delivery delays.

Designing the phone sign-in experience for mobile screens — overview diagram

What Pocket App recommends after delivering mobile identity projects

Across retail, healthcare and charity mobile projects, we default to built-in user flows unless a client has a specific UX or compliance requirement that forces custom policy work, since the maintenance overhead of custom XML is real and ongoing.

Our operational checklist before launch always includes carrier testing across the client's actual user base, not a single test SIM, clear consent language around phone number storage, and analytics on OTP delivery success from day one. That last point catches regional delivery problems long before support tickets do.

— Paul

Get hands-on help with your Azure AD B2C mobile build

Getting phone authentication right on mobile takes more than following documentation: it takes someone who has hit the redirect URI mismatches, the carrier filtering quirks and the custom policy XML failures before. Our Mobile App Clinics provide development teams with short, focused technical sessions to work through implementation problems related to identity flows.

If your project needs more than a clinic session, whether that is a full discovery workshop to scope your authentication requirements or hands-on development support to get a custom policy over the line, our Discover, Design, Develop and Deploy process covers the full path from initial requirements to a released app. Get in touch to talk through what your mobile identity build actually needs.

FAQ

Is Azure AD B2C being discontinued?

Azure AD B2C is not being shut down immediately, but new purchases ended on 1 May 2025, and Microsoft is directing new projects toward Microsoft Entra External ID. Existing B2C tenants continue to be supported for several years, so current deployments are not at immediate risk, but new projects should evaluate External ID first.

Is there an Azure DevOps mobile app?

This question is usually about the identity platform rather than a dedicated mobile client, and Azure AD B2C itself does not ship as a standalone mobile app since it is an identity service you integrate into your own mobile app through MSAL. Azure DevOps has separate mobile access options unrelated to the B2C authentication flows covered here.

What is replacing Azure AD B2C?

Microsoft Entra External ID is the successor platform for customer identity scenarios, and Microsoft recommends most customers plan a standard migration path toward it. Very large, high-scale tenants have a separate HSC migration mode, though it carries functional limitations around social providers and certain conditional access scenarios worth reviewing before committing.

What is B2C in Azure AD?

B2C stands for business-to-consumer, and Azure AD B2C is Microsoft's identity platform for managing sign-up, sign-in and profile management for a company's external customers rather than internal staff. It supports multiple identity types, including phone number, email and social sign-in, through customisable user flows or fully custom policies.