Here’s a fun fact: embedding credentials in your Azure apps is basically handing out house keys at a bus stop. Entra ID and managed identities let you lock every door without juggling keyrings or hoping nobody notices the Post-It note under your keyboard. The good news—you don’t need to be a cryptography wizard to do this. I’ll show you step by step how to swap secrets for tokens and sleep better at night.The Doormat Key ProblemWhy do so many Azure apps still stash passwords in config files like we’re all still writing VBScript in 2003? Seriously, it’s 2024. We have cloud-native security systems that mint tokens on demand, yet someone somewhere is still committing a literal `sa` password to their repo like it’s a badge of honor. And the excuse is always the same: “We hard‑code it just to save time.” Save time today, and then spend weeks cleaning up the mess when it leaks. That's not a shortcut. That’s procrastination with extra steps. The problem is bigger than laziness. Developers think dropping usernames and passwords into a web.config file or appsettings.json is harmless because it stays internal. Except nothing ever stays internal. That config gets copied to dev, test, staging, three different QA branches, backups, and a laptop someone left on a plane. That’s not a secret; that’s a distributed broadcast. Add in Git, where “oops, wrong push” has put more production passwords public than I care to count, and you’ve got an incident queue that writes itself. Here’s the part nobody likes to admit: these “quick fixes” don’t just risk exposure—they guarantee it over time. Secrets are slippery. They creep into log files because you forgot to sanitize an exception. They hide in screenshots shared over Teams. They get zipped into backups sitting unencrypted in blob storage because no one paid for the vault tier. All it takes is one bored attacker scanning public repos for obvious strings—`Password123!` is still a goldmine—and suddenly your entire app is wide open. One of my favorites? Remember when thousands of credentials showed up in public GitHub a few years back because devs used personal repos for “just testing”? Attackers didn’t even have to try. They ran keyword scans, found connection strings, and walked straight into production resources. No zero‑day. No Hollywood hacking montage. Just copy, paste, profit. That’s what hard‑coding secrets buys you—a house where the burglar doesn’t even need to pick a lock. The key’s under the mat, and you spray‑painted “KEY IS UNDER REACT APP SETTINGS” on the front porch. You wouldn’t leave your front door unlocked with the garage code written on a sticky note, but that’s exactly how connection strings behave when they include credentials. Sure, it works. Until a neighbor—by which I mean some anonymous botnet—figures out where you hid them. Microsoft has been very clear these days: hard‑coded credentials are being pushed into the same bucket as Internet Explorer and Clippy. Deprecated. You can limp along with them, but expect disappointment, breakage, and an audit log screaming at you. Add to that the sprawl problem. Each environment needs its own settings, so now you’ve got a password per dev box, an admin string in staging, another one production, and nobody knows if they’re rotated. Different teams hoard slightly out‑of‑date copies. Someone comments out an old connection string instead of deleting it. Congratulations: your app is a digital junk drawer of skeleton keys. Attackers love it because it’s a buffet. And let’s not even mention what happens when contractors get read‑access to your repos. You think they only take the code? The takeaway here is simple: the real danger isn’t just a password leaking. It’s the way secrets breed. Once you let them into configs, they replicate across environments, backups, scripts, and documentation. You cannot manage that sprawl. You cannot contain it with “clever” obfuscation tricks. It’s not a problem you patch; it’s a problem you eliminate. Stop thinking about where to hide the key. Instead, stop using keys at all. That’s why tokens exist. They don’t behave like passwords. They aren’t long‑lived, they aren’t static, and they don’t sit in files for years daring the wrong person to find them. The cure for password sprawl isn’t to hide the passwords better—it’s to replace them with something that self‑destructs when it’s misused. Tokens let you do exactly that, and Entra ID is the system handing them out. Okay, so if we throw the doormat keys away, how do tokens avoid turning into even messier problems for us admins? Let’s talk about why they actually make life easier instead of harder.Why Tokens Beat Passwords Every TimeIf passwords are car keys, tokens are valet tickets—you use them for a single ride, and they’re worthless once the trip’s done. Nobody makes a sneaky copy of a valet ticket, and if they try, someone spots it right away. That’s the fundamental difference: passwords are static. Tokens are temporary and scoped. Which means if they leak, the blast radius is tiny, and the clock is already ticking before they expire. So what even is a token? In Azure land, your app hits Entra ID and says, “Hey, can I get permission to do this thing?” Entra ID checks who or what’s asking, does its paperwork, and then hands back a signed package: the access token. That token is short‑lived. It’s tied to the user or service identity. It’s got limits on what it can touch. And when the time window closes, it’s dead. Nobody resets it, nobody rotates it—it just vanishes. Of course, when you tell devs this, the first instinct is panic. “Oh no, now we’ve got rotating tokens flying around, do we have to cache them, store them, chase refresh codes, build replacement logic?” The answer: no, stop sweating. The Microsoft Identity libraries do that plumbing for you. The SDKs literally grab, refresh, and dispose like janitors cleaning up after a conference. You don’t have to reinvent OAuth. You just call the function and focus on your actual app logic. Compare it with the old school way. A static password is like handing someone the master key to your entire building. They don’t just get into their floor; they can hit the executive suite, the server room, even the candy stash in HR’s drawer. Now take a token: it’s a guest pass that only works for Floor 3, and it shuts off at 5 p.m. If someone tries to use it after hours, access denied. No guessing, no lingering. It’s scope matched to function, not wide open duct tape. Tokens also carry brains inside them. Ever open up a token? It’s like inspecting a boarding pass—there’s your flight, seat row, gate, and zone. Tokens store claims: roles, scopes, tenant IDs, even the user’s basic info. That means your API isn’t just trusting “this person logged in.” It’s checking “this person is in finance, has the payments role, and was approved today.” You can build way tighter rules directly into your app logic, without managing ten different password sets. Here’s a real comparison. One shop I worked with had a database locked only with SQL credentials hard‑coded everywhere. That account had system admin. Predictably, one contractor copied it to a tool, and bam—the entire database was their playground. Every table exposed. Now look at a newer system using tokens scoped only to what the app needed: read access on a single schema. Even if someone stole that token, all they could do was select records, and only until the token expired. It turned a nightmare into a minor annoyance. Now I can hear some devs groaning: “Tokens sound neat in theory, but they’ll break my workflow. I don’t have time to micromanage renewal or expiration.” That’s the myth. Nobody’s expecting you to refresh them manually. The libraries you’re already using in .NET or Node grab the refresh token, swap it invisibly, and keep rolling. You don’t even know it happened unless you were sniffing packets. Which is the point—stop babysitting secrets; let the system handle it. Think of Entra ID as the passport office. You show up, prove who you are, and they stamp an ID that border guards (your APIs) trust. Expired stamp? No boarding. Wrong stamp? Denied. It centralizes the identity question in one authority. Your apps don’t argue, your APIs don’t babysit passwords—they just check the stamp and let you through. That’s infinitely better than juggling a dozen mystery keys and wondering which ones are still valid. The best part for us IT folks: no more forced password rotations every 90 days, no more scripts running at 3 a.m. to reset service accounts, no more debates about whether to store secrets in Key Vault or under a heavy dose of wishful thinking. Tokens expire on their own, and that expiration is your safety net. If something leaks, it’s already doomed to stop working. You didn’t fix anything—you just built a system that auto‑heals by design. So yes, tokens handle user logins securely and cleanly. Great. But it’s not just about users clicking sign‑in. The real test is when apps need to talk to other apps, or services fire off requests at three in the morning without a human anywhere near a keyboard. That’s where things shift from neat to necessary.Meet Managed Identities: Service Principals, but Less DumbImagine if your app could march into Azure services without ever typing a password, because it already came out of the factory with its own stamped identity. That’s not science fiction—it’s how Managed Identities work. And once you start using them, the whole idea of shuffling service principals around with expiring secrets will feel as dated as carrying a pager. Here’s the old mess we used to live with: service principals. You’d register one, generate a client secret or maybe a certificate, and stuff that into Key Vault. Then you hand that identity to your app so it could do things like connect to SQL or hit Storage. On paper, it sounded fine—credentials weren’t hard‑coded anymore, they were centralized. In reality, you were babysitting hot
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
Follow us on:
LInkedIn
Substack
