This course is designed for infrastructure and security administrators who manage Microsoft cloud environments. The focus is on architecture, capabilities, and controls - with enough developer context (token structure, OAuth flows, REST APIs) to reason about security without requiring a development background.

Participants leave with an understanding of how service principals and permissions work under the hood, how to write or evaluate automation using modern credential-free patterns, and practical deployable tools for their own environments.

Expected Prerequisites

• Familiarity with the Entra admin center and Azure portal navigation
• Basic PowerShell scripting - reading and modifying scripts; no authoring from scratch required
• General understanding of Active Directory and Entra ID: users, groups, service accounts, Kerberos, OAuth
• Working knowledge of Microsoft 365 administration: tenant management, Exchange Online, SharePoint Online basics
• No developer background required - OAuth flows, REST APIs, and token structure are taught from first principles

Attendee Machine Requirements

For the hands-on labs, the attendee machine should have the following tools installed in advance:

Base attendee machine

• PowerShell 7
• Azure CLI
• Azure Developer CLI (azd)
• GitHub Account
• Visual Studio Code with Git installed is highly recommended for editing, reviewing output, and following the lab steps

Microsoft Graph PowerShell

Either of the following approaches is acceptable:

• Install the full Microsoft.Graph module
• Or install only the modules used in the course: Microsoft.Graph.Authentication, Microsoft.Graph.Users, Microsoft.Graph.Applications, Microsoft.Graph.Identity.SignIns, and Microsoft.Graph.Reports

Az PowerShell modules

• Az.Accounts
• Az.KeyVault

Lab Environment Options

Traditional Service Accounts in Active Directory

Organizations built around Active Directory typically used ordinary user accounts for service identities - with static passwords, no MFA support, and broad group memberships accumulated over time. Real-world examples still common in enterprise environments: SQL Server service accounts, IIS application pool identities, scheduled tasks, DFS replication, backup agents (Veeam, Commvault), and vulnerability scanners (Tenable, Qualys).

Managed Service Accounts are introduced as the bridge concept: they reduce password management on-premises, but the larger transition is toward workload identities that avoid stored credentials entirely.

Service Principals and Authentication Methods

Service Principals are the cloud-native equivalent of service accounts in Microsoft Entra. They are not subject to MFA or Conditional Access by default - but they offer authentication methods that are fundamentally stronger than any password-based account.

The section compares the main authentication patterns for service principals: client secrets, certificates, workload identity federation, and managed identities. The emphasis is simple: managed identity is preferred for Azure workloads, workload identity federation is preferred for CI/CD, certificates are situational, and secrets are the weakest option.

When a credential cannot be eliminated, the guidance stays high level: store it in Key Vault, retrieve it at runtime, and treat sign-in logs, credential rotation, and compromise response as separate governance tasks.

Enterprise Applications, IDs, and Token Types

The App Registration / Enterprise Application split is a persistent source of confusion - and the wrong ID in a Graph query is a common bug.

---

Delegated vs. Application Permissions

The distinction maps to a familiar concept: delegated permissions are like Kerberos constrained delegation - the app acts on behalf of a signed-in user and cannot exceed what that user is allowed to do. Application permissions are like an unconstrained service account - the app acts as itself with no user context, accessing data across the entire tenant.

Attack Patterns and OAuth Exploitation

Illicit Consent Grant Attacks

An attacker registers a malicious multi-tenant app and tricks a user into consenting to it - granting persistent, MFA-bypassing access without stealing a password. Unlike credential theft, revoking access requires explicitly revoking the consent grant.

Defenses: Restrict user consent to verified publishers and low-risk permissions only (or disable entirely). Enable the admin consent workflow. Deploy App Governance anomaly detection in Defender for Cloud Apps.

Device Code Flow Phishing

The attacker initiates a device code authentication request and sends the resulting code to the victim. When the victim enters it at microsoft.com/devicelogin, the attacker receives valid tokens without needing the victim's password or MFA. Microsoft Threat Intelligence has tracked active campaigns (Storm-2372) using this technique since 2024.

Non-Graph API Permissions - The Auditing Blind Spot

The most dangerous example: the Azure Service Management API (https://management.azure.com/) - the user_impersonation delegated scope grants an application the same Azure subscription management rights as the signed-in user, including RBAC modification, Key Vault secret access, and compute creation. Most permission reviews focus on Graph and miss this entirely.

End-to-End Attack Chain Scenario

A representative attack chain ties the section together: a forgotten application with excessive permissions, a leaked credential, weak ownership, and poor monitoring. The section uses that scenario to show how silent access happens, why Application Administrator is a serious escalation path, and which controls break the chain early.

Permission Hardening and Governance

• Enumerate permissions at scale - Get-MgServicePrincipalAppRoleAssignment and Get-MgOauth2PermissionGrant in PowerShell; Microsoft Defender for Cloud Apps App Governance dashboard for a visual inventory
• Revoke without reinstalling - permissions granted via admin consent can be removed with Remove-MgOauth2PermissionGrant; revoking a permission does not revoke existing valid tokens
• Entitlement Management for API permissions - access packages with app role assignments enable time-limited, approval-gated access to application roles for developers who need temporary elevated API access
• Lifecycle Workflows - Entra ID Governance automates Joiner/Mover/Leaver tasks including group memberships, account enable/disable, and custom task extensions (Logic Apps, Function Apps) that tie identity governance to the same automation patterns covered later in this course

---

Token Acquisition and IMDS

This section walks through token acquisition with managed identities, including the IMDS endpoint used on Azure compute. The focus is practical troubleshooting: request the right token for the right resource, understand the IMDS protections that matter for SSRF, and use token claims to explain why an API call succeeds or fails.

Reading JWT Claims for Debugging

When automation fails with a 403, inspect the token before anything else. The two critical claims:

• roles - lists application permissions granted to the managed identity; if empty, the identity hasn't been granted the app role
• scp - lists delegated scopes; only present in delegated tokens, not app-only
• aud - confirms which service the token is scoped to; a Graph token won't work against ARM
• exp - expiry time; cache tokens and refresh before this time rather than re-authenticating on every call

Microsoft Graph, ARM, and Other APIs

The outline also briefly distinguishes supported APIs from internal browser-discovered endpoints: Graph, ARM, and supported service tooling are the production surfaces, while undocumented endpoints are useful for investigation but not for durable automation.

Microsoft Graph API

Graph is the unified REST API for Microsoft 365 and Entra. Key operational concepts:

• Versioning: /v1.0 for stable features; /beta for capabilities not yet in /v1.0, but Microsoft states the beta version is not supported for production use. See beta version support policy.
• OData parameters: $filter, $select, $top, $expand - always use $select to request only needed fields
• Pagination: responses over the page size include @odata.nextLink; automation must loop until this key is absent - a common bug produces silently incomplete compliance reports
• Throttling: HTTP 429 with Retry-After header; honor the returned delay, and use exponential backoff when a retry interval is not provided

Azure Resource Manager vs. Microsoft Graph

---

Azure Automation Platforms

Workload Identity Federation - CI/CD Authentication

WIF is presented as the preferred CI/CD authentication pattern: no stored secrets, a federated trust to GitHub Actions or Azure DevOps, and tightly scoped subject claims so only expected repositories and branches can exchange tokens. The section also calls out Logic App connection objects as credentials to govern and vNet integration plus Private Endpoints as the main network controls for private-resource scenarios.

Triggers and Event Patterns

---

Source Control and CI/CD for Automation

All runbooks, Logic App definitions, Function App code, and pipeline YAML should live in a Git repository. Never edit runbooks directly in the Azure portal for production systems - treat the portal as read-only for production code.

The point is straightforward: source control and CI/CD are treated as security requirements, not convenience features, because portal-only edits remove review, testing, and history.

AI-Assisted Development - Security Review Checklist

AI-assisted development is covered from a review perspective: remove hardcoded secrets, reduce scopes, add error handling, avoid logging tokens, and request only the Graph fields you actually need.

Monitoring, Observability, and Service Principal Hygiene

This section explicitly adds monitoring and alerting so failed jobs, broken permissions, and automation drift surface quickly through Log Analytics, Azure Monitor, and platform-native telemetry.

It closes with service principal hygiene: naming conventions, owners, credential expiry tracking, orphan detection, and inactivity review so automation remains understandable and supportable over time.

---

ARM Templates and Bicep

Azure portal, Azure CLI, Az PowerShell, Bicep, and ARM templates all rely on Azure Resource Manager for management and deployment operations. Understanding ARM as the underlying control plane explains why tokens scoped to management.azure.com are needed for infrastructure automation, and why Azure RBAC (not OAuth consent) governs Azure resource access.

The comparison stays at the authoring level: ARM JSON is the deployment format, while Bicep is the easier authoring layer that compiles to it and is the default fit for azd-based solutions.

Azure Developer CLI (azd)

azd bundles infrastructure-as-code (Bicep), application code, and CI/CD pipeline configuration into a single deployable, shareable template. For IT and security professionals, community-built security tools can be deployed with a single command rather than manual resource creation and permission assignment steps.

The template structure is part of the overview: azure.yaml defines the solution, /infra holds the Bicep deployment layer, /src holds application code, and core commands such as azd up, azd pipeline config, and azd down cover deployment, pipeline setup, and teardown.

Example Solutions and Labs

Representative examples include break-glass Conditional Access exclusion automation, azd-maester as a ready-to-deploy security testing solution, and a Key Vault-backed passkey pattern that reinforces that the vault must be treated as the effective credential store.

Additional lab examples show the same packaging model applied to identity governance, endpoint telemetry, notification workflows, and audit monitoring.

---

Securing Applications and Automation - Course Outline  ·  Content validated May 2026