How to Connect to SharePoint Online Using PowerShell and an Azure Registered App

If you’ve worked with SharePoint Online long enough, you’ve probably started with user-based authentication—interactive logins, MFA prompts, saved credentials, or scheduled tasks running under a service account.

That approach works… until it doesn’t.

In real enterprise environments, user-based authentication becomes fragile very quickly:

• MFA breaks scheduled scripts
• Service account passwords expire
• Admin accounts are disabled during security reviews
• Automation fails silently after hours

This is why app-only authentication using an Azure AD (Entra ID) registered app has become the gold standard for SharePoint Online automation.

Using an app identity:

• Removes user dependency entirely
• Works cleanly with automation and CI/CD pipelines
• Aligns with Microsoft’s Zero Trust model
• Is auditable, revocable, and scope-controlled

In this guide, I’ll walk through the entire end-to-end process, explain why each step matters, and share lessons learned from implementing this in production environments.

Prerequisites and What You’ll Actually Need

Before you begin, make sure you have:

• Global Administrator or Application Administrator access in Microsoft 365
• Access to the Azure Portal
• PowerShell 7+ (recommended)
• PnP PowerShell module
• A clear understanding of what the script needs to do (read-only vs full control)

💡 Real-world tip:
Decide on permissions before creating the app. Over-permissioning is one of the biggest mistakes I see during SharePoint security reviews.

Step 1: Register an App in Azure AD (Entra ID)

Start by creating an identity for your automation.

1. Sign in to the Azure Portal
2. Navigate to Azure Active Directory (Entra ID) → App registrations
3. Click New registration

Configure the app:

• Name: Something descriptive like SharePoint-PnP-Automation
• Supported account types:
  Choose Single tenant unless you have a specific multi-tenant requirement
• Redirect URI: Not required for app-only authentication

Click Register.

Once created, note:

• Application (Client) ID
• Directory (Tenant) ID

These values uniquely identify your app and tenant.

Step 2: Create a Client Secret (Or Consider Certificates)

Navigate to:
Certificates & secrets → New client secret

• Add a clear description (e.g. “PnP PowerShell automation”)
• Choose the shortest practical expiry

Copy the secret value immediately—you won’t see it again.

Real-World Security Advice

Client secrets work, but for long-term or high-risk environments:

• Certificates are more secure
• Secrets often end up in scripts, pipelines, or config files
• Many breaches start with leaked secrets

If you’re running this in production, certificates are worth the extra effort.

Step 3: Assign API Permissions (This Is Where Most Mistakes Happen)

Go to API permissions → Add a permission

Choose:

• SharePoint
• Application permissions

Add only what you need, for example:

• Sites.Read.All – Read access across all sites
• Sites.ReadWrite.All – Modify content
• Sites.FullControl.All – Full administrative access (use sparingly)

Click Add permissions.

Then Grant admin consent for your tenant.

⚠️ Important:
Without admin consent, the app will authenticate successfully but fail silently when accessing SharePoint.

Step 4: Grant Permissions Inside SharePoint (Often Missed)

Azure permissions alone are not always enough—especially in classic or hybrid scenarios.

Navigate to the target SharePoint site:

https://yourtenant.sharepoint.com/sites/yoursite/_layouts/15/appinv.aspx

• Enter the Client ID
• Click Lookup

Add permission XML:

<AppPermissionRequests AllowAppOnlyPolicy="true">
  <AppPermissionRequest 
    Scope="http://sharepoint/content/sitecollection" 
    Right="FullControl" />
</AppPermissionRequests>

Click Create, then Trust It.

When This Step Is Actually Required

In my experience:

• Older tenants
• Heavily customised environments
• Legacy PnP scripts

…often still require this step for consistent access.

Step 5: Install PnP PowerShell (The Modern Way)

PnP PowerShell replaces older SharePoint modules and is actively maintained.

Run PowerShell as your normal user:

Install-Module PnP.PowerShell -Scope CurrentUser

Verify installation:

Get-Module PnP.PowerShell -ListAvailable

Step 6: Connect to SharePoint Online Using App-Only Authentication

Here’s a clean, production-ready example:

$tenant = "yourtenant"
$siteUrl = "https://$tenant.sharepoint.com/sites/yoursite"
$clientId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
$clientSecret = "your-client-secret"

Connect-PnPOnline `
  -Url $siteUrl `
  -ClientId $clientId `
  -ClientSecret $clientSecret `
  -Tenant "$tenant.onmicrosoft.com"

If authentication succeeds, there will be no prompt, no MFA, and no user context.

Step 7: Validate the Connection (Don’t Skip This)

Always test before running destructive commands:

Get-PnPWeb

If this returns site information, your app-only connection is working correctly.

Other safe test commands:

Get-PnPList
Get-PnPWebPermission

Real-World Use Cases Where This Approach Shines

From hands-on experience, app-only authentication works best for:

• Scheduled SharePoint reporting
• Permission audits
• Site inventory scripts
• Metadata enforcement
• Integration with Power Automate or Azure Functions
• CI/CD pipelines deploying SharePoint assets

Anywhere you don’t want a human involved, this approach is superior.

Common Pitfalls (Learned the Hard Way)

1. “Authentication works but commands fail”

Usually missing admin consent or insufficient API permissions.

2. “Access denied” on specific sites

The app has tenant-level permission but lacks site trust in classic setups.

3. Secrets expiring silently

Use reminders—or better yet, certificates.

4. Over-permissioning

Security teams will flag Sites.FullControl.All without justification.

Security and Governance Best Practices

To stay aligned with Microsoft and security best practices:

• Use separate apps per automation workload
• Name apps clearly for audit visibility
• Rotate secrets regularly
• Remove unused app registrations
• Prefer certificates for long-lived automation

App identities are powerful—treat them like privileged accounts.

The Right Way to Automate SharePoint Online

Connecting to SharePoint Online using PowerShell and an Azure AD registered app isn’t just a technical upgrade—it’s a maturity step.

It removes brittle dependencies on user accounts, aligns with Zero Trust, and scales cleanly across environments.

If you’re still relying on interactive logins or service accounts for SharePoint automation, moving to app-only authentication is one of the highest-value improvements you can make—both technically and from a security standpoint.

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.