Episode Details

Ever tried setting up app-only permissions with Microsoft Graph and ended up knee-deep in consent dialogs, confused about what just happened? You’re not alone. Most tutorials gloss over what ‘consent’ really means for non-interactive services—and where things can quietly go off the rails.Today, we’re breaking down the end-to-end workflow: exactly what you must configure in Azure AD, how permissions actually work, and what happens behind the scenes when you grab that elusive access token. Ready to finally fill in the missing pieces?The Consent Gap: Where Most Tutorials Get Microsoft Graph WrongIf you've ever read a quick-start on Microsoft Graph, you've probably seen the moment where the author waves at ‘consent’ and then skips straight to the code. There’s always that implied idea: tick a few boxes in Azure AD, grant the permissions your app needs, and you’re good to go. But the reality is, what happens with consent—especially when there’s no user in the mix—gets glossed over in documentation and walkthroughs alike. It’s easy to assume app-only access is just a matter of flipping a switch, but this is one of those areas where the devil’s in the details, and that devil can sneak up on you in a real tenant.A lot of admins and developers treat setting up app-only access in Microsoft Graph like they’re checking off a grocery list. Pick the permissions, hit “register,” and call it done. But as soon as something changes—a policy update, a new compliance review, or even an audit request from IT—those simple checkboxes start causing headaches. Suddenly, you’re hit with unexpected consent prompts, puzzled users, and security teams asking why an unattended app has sweeping admin-level access. What’s supposed to be non-interactive service access quickly turns into a permission soup that nobody quite remembers approving.Let’s put this in a real-world Microsoft 365 context. Imagine you’ve got a background service—maybe an automation script collecting usage stats, or a tool syncing files from OneDrive to SharePoint. Everything seems to work. Then, one afternoon, a global admin flips a setting related to consent policies, maybe to comply with a security mandate. The next morning? Your automation fails, logs fill up with unhelpful errors, and people are left scratching their heads. The consent mechanics behind that app-only setup are suddenly impossible to ignore, but it’s too late for an easy fix.Microsoft’s own documentation is dense, but here’s the bit that’s easy to miss: app-only permissions aren’t bound to a single user’s access, and they don’t ride along with a person’s security context. This means one consent event—one click, maybe months ago—can assign permissions that persist until someone manually revokes or alters them. If the app was granted ‘Sites.ReadWrite.All’ for SharePoint, that doesn’t just mean it can poke around your own mailbox. It could touch or expose every SharePoint site in the tenant, all because the consent scope was too broad. Most of the time, the tutorials don’t even pause to unpack this, so the risk quietly snowballs in the background.That brings us to a pattern that shows up over and over again in the field. You’ve got delegated permissions—what users see when they log in to an app and consent to “read your profile” or “view your mail.” Then there’s app-only permissions, where a service account operates without a human at the keyboard. Research from tenant-breach post-mortems shows admins often confuse the two, granting overly broad app permissions thinking they’re just approving a narrow workflow. It’s the difference between letting someone peek into one room versus handing them a master key for the whole building. Most folks don’t realize that with application permissions, even one misstep in the Azure portal means that automation can reach far more data than expected, all while nobody’s watching.Let’s take SharePoint as a tangent here, because that’s where things get really interesting—and sometimes risky.