# The Secure Login Journey: What Happens When You Tap Sign In > A secure app never touches your password. It hands you to Microsoft Entra ID, gets back a signed token, and that token is all your API ever sees. - **Author:** Suthahar Jegatheesan (MSDEVBUILD) - **Published:** 2026-10-12 - **Category:** Azure - **Tags:** Azure, Microsoft Entra ID, OAuth, JWT, Authentication, MFA, MSAL - **Canonical URL:** https://blog.msdevbuild.com/blog/secure-login-journey/ --- **Highlight:** Your password goes to exactly one place: Microsoft Entra ID. Your app, your API and your database only ever see a short-lived signed token. If your login screen has a password field you built yourself, that is the thing to replace — with MSAL and the system browser. import Callout from '../../../../components/mdx/Callout.astro'; Priya opens a food delivery app at 7pm, hungry, and taps **Sign in**. About a second and a half later she's looking at her past orders. In that second and a half, her password went to exactly one place. It wasn't the app. It wasn't your API. It definitely wasn't your database. This post follows that one tap all the way down, because once you've seen the journey, it's very hard to go back to building your own login form. ## What happens when you tap "Sign in" on a secure app? A secure app never handles your password. It hands you to Microsoft Entra ID, Entra ID checks who you are, and the app gets back a signed token: that token, not the password, is what every system after that point sees.
![Six steps drawn top to bottom, each with an icon. 1, a phone: Priya taps Sign in and the app opens Microsoft's sign-in page instead of its own password box. 2, a globe: she types her password on Microsoft's page, and only Microsoft sees it. A red dashed line below this step reads "her password never goes below this line". 3, a bell: she approves on her phone (MFA), so a stolen password alone is useless. 4, a shield with a tick: Microsoft hands back a signed pass, the token, which says who she is and expires in about an hour. 5, the App Service icon: your API checks the pass by itself, without calling Microsoft. 6, the Azure SQL icon: the API opens the database with its own managed identity, so no password exists in code, config or the database. A green box at the end reads "Her password went to exactly one place: Microsoft."](./images/secure-login-journey-beginner.png)
Figure 1 — one sign-in, in plain English. The password exists only above the red line.
## Step by step: where the password goes **1. The app hands off (about 20ms).** It opens the system browser, or a secure web view, on the Microsoft sign-in page. Not a text field the app drew itself. This sounds like a detail. It's the whole thing: if your app renders the password field, your app has the password, and every promise you make after that is on trust. **2. The password stops at Entra ID.** It travels to Microsoft and nowhere else. Your API isn't in this step and never will be. If your database leaks tomorrow, there are no passwords in it. You never had any. **3. MFA: the slow bit, and it's her, not the system.** Priya approves the prompt on her phone. That's what makes a stolen password worthless. It matters a lot, because password reuse is exactly what credential-stuffing bots run on (more on those in [the post on automated login attacks](../ai-bot-attacks-mobile-app)). **4. A signed token comes back (about 1.4 seconds in).** A JWT: who she is, what she's allowed to do, when it expires, and Microsoft's signature over all of it. Usually valid for 60–90 minutes. The app stores it in the iOS Keychain or Android Keystore, never in `UserDefaults` or `SharedPreferences`. **5. Your API verifies it locally (microseconds).** This is the step people assume is a network call. It isn't. Your API downloaded Microsoft's public signing keys once, cached them, and now checks every token on its own. **6. No password below the API either.** Your API reaches Azure SQL with a managed identity: ```text Server=msdev.database.windows.net; Authentication=Active Directory Default; ``` No password in the connection string. Nothing to leak, nothing to rotate. ## What does the API check on every token? Four things, and all four matter: | Check | What it proves | What goes wrong if you skip it | | --- | --- | --- | | Signature | Microsoft issued it and nobody edited it | Anyone can forge a token | | Issuer (`iss`) | It came from *your* tenant | A token from another tenant gets in | | Audience (`aud`) | It was issued for *this* API | A valid token for a different app works on yours | | Expiry (`exp`) | It's still in date | A token stolen last week still works | Signature alone isn't enough. The audience check is the one teams forget. A perfectly valid token issued for some other application is still perfectly valid. Just not for you. ## The part that surprises people After step 2, there's no password anywhere. Not in the app. Not in your config, the connection string or the database. The only thing moving through the system is a short-lived signed token. It expires on its own. ## What happens after the token expires The access token expires after about an hour. A refresh token quietly gets a new one in the background, which is why a well-built app doesn't sign you out every 60 minutes, and it's also why a stolen access token is a much smaller problem than a stolen password. It stops working by itself, soon. ## How to check your own app Open your login screen and look for a password field you built, because if it's there, your app is handling passwords. Nothing above applies to you yet. Moving to [MSAL](https://learn.microsoft.com/entra/identity-platform/msal-overview) and the system browser is the change that makes it apply. It's usually less work than the login form you'd be deleting. ## Key takeaways - A secure app never renders its own password field — it hands the user to Microsoft's sign-in page via the system browser. - The password reaches Microsoft Entra ID and stops there; your API and database never see it. - Token verification is a local check against cached signing keys, not a network call per request. - Check signature, issuer, audience **and** expiry — a valid signature doesn't mean the token was meant for your API. - Reach Azure SQL with a managed identity, so no password exists anywhere past sign-in. Earlier in this series: [Insecure vs Secure: The Same Mobile App, Two Azure Architectures](/blog/insecure-vs-secure-architecture/) and [Azure Key Vault Explained: The One Secret Tutorials Never Remove](/blog/azure-key-vault-explained/). --- ## Frequently asked questions ### Does a mobile app's API ever see the user's password? Not in a secure design. The app opens the system browser on Microsoft's own sign-in page, so the password goes to Microsoft Entra ID and stops there. Your API only ever receives a signed, short-lived token that proves who the user is. ### Why does a secure mobile app open a system browser instead of its own login form? Because if the app renders the password field, the app has the password, and every promise about security after that point rests on trust alone. Handing off to the system browser means the password travels to Microsoft Entra ID directly and is never visible to the app's own code. ### How does an API verify a JWT without calling Microsoft Entra ID on every request? It downloads Microsoft's public signing keys once from the OpenID configuration endpoint and caches them, then checks the signature, issuer, audience and expiry entirely offline. That costs microseconds rather than a network round trip. All four checks matter: a valid token issued for another application is still valid. ### Where should a mobile app store the access token? In the platform's secure store: the iOS Keychain or the Android Keystore (SecureStorage in .NET MAUI). Never in UserDefaults or SharedPreferences, which are plain files readable on a rooted or jailbroken device and from device backups. ### Does a database need to store user passwords in a Microsoft Entra ID login flow? No. The password stops at Entra ID and never reaches the application's own API or database. The API connects to Azure SQL with a managed identity, so there is no password anywhere in the chain after sign-in — nothing to leak if the database is ever compromised.