How to Access Microsoft 365 Services via a Client Application

Introduction

Accessing Microsoft 365 data (SharePoint, Outlook, Teams, or OneDrive) through a client application involves securely authenticating to Microsoft Entra ID (Azure AD) and requesting tokens to call APIs like Microsoft Graph or SharePoint REST.

This article explains:

How Microsoft 365 authentication works
When to use delegated vs app-only permissions
When tokenization and app registration are required
How SPFx apps access Microsoft 365 without manual app registration

Authentication Models

Before a client application can access Microsoft 365 services (like SharePoint, OneDrive, Teams, or Outlook), it must first authenticate. There are two main models of authentication for client applications:

1. Delegated (User) Authentication

Also called: On-behalf-of authentication.
Scenario: Your application acts on behalf of a signed-in user.
How it works:
- The user signs in and grants consent to the app.
- The app gets an access token for the user.
- The app can only access resources that the signed-in user has permission for.
Use cases:
- Web or mobile apps where a user interacts with Microsoft 365.
- Accessing user emails, calendars, or OneDrive files.
Token Type: OAuth 2.0 access token with user context.

Example:
A SharePoint client app that reads the logged-in user’s documents in OneDrive.

2. Application (App-Only) Authentication

Also called: Client credentials flow
Scenario: The app acts as itself, without a signed-in user.
How it works:
- You register your application in Azure AD and assign it the required permissions.
- The app uses its client ID and secret/certificate to authenticate and obtain an access token.
- The app can access resources at the application level, independent of any user.
Use cases:
- Automated workflows, background services, or daemons.
- Accessing SharePoint sites, Teams data, or mailboxes for all users.
Token Type: OAuth 2.0 access token for app-only context.

Example:
A service that automatically archives emails from all user mailboxes in an organization.

When Do You Need Tokenization and App Registration?

You need App Registration and Tokens when

Scenario	Reason
Client or Console App (Python, C#, Node.js)	You must register your app in Entra ID to get a Client ID and Secret/Certificate to authenticate.
Custom Web App connecting to Microsoft Graph	Web apps outside Microsoft 365 need tokens to prove identity and permissions.
Background/Migration Tools (App-Only)	Need tenant-wide access, require Sites.Read.All or Sites.FullControl.All.
Service Accounts replaced by Modern Auth	Token-based auth replaces legacy username-password.
PowerShell Graph scripts (using MSAL)	Each script authenticates via an app registration or managed identity.

You do not need App Registration or Tokens when

Scenario	Why
SPFx (SharePoint Framework) web parts or extensions	SPFx runs within the SharePoint security context, automatically using the user’s existing Azure AD session.
Graph calls made via MSGraphClient or AadHttpClient in SPFx	These clients use SharePoint’s pre-registered Azure AD application. No manual registration or secrets are needed.
Power Automate / Power Apps	Tokens are handled internally by Microsoft’s Power Platform identity layer. You simply grant permissions via connectors.
SharePoint Add-ins (legacy model)	Add-ins are registered in SharePoint directly and use the built-in OAuth trust (not Entra ID registration).

Example
If you’re building an SPFx web part that fetches user profile data via Microsoft Graph (/me endpoint), you just use:

this.context.msGraphClientFactory
  .getClient()
  .then((client) => {
    client
      .api('/me') // Current user
      .get()
      .then((response) => {
        console.log('User details:', response);
      })
      .catch((error) => {
        console.error('Error fetching user:', error);
      });
  });

No manual token, no app registration, no consent prompt for end-users.

But, if you use a Python script or any client application to access the Microsoft 365 service, like a SharePoint Site or List detail or User Information, you need to use an access token.

Steps to Register an App in Azure AD (for Client Access)

Go to Azure Portal → App Registrations → New Registration

Provide App Name, select Accounts in this organization only
Note down Application (Client) ID and Directory (Tenant) ID
Under Certificates & Secrets, generate a Client Secret
Under API Permissions, add:
- User.Read (delegated, for sign-in)
- Sites.Read.All (delegated or app-only, to access SharePoint)

Click Grant admin consent (if required)
Use the MSAL library to request tokens in your app

Below is the Python script to get the user details

import msal
import requests

# Azure AD App details
TENANT_ID = 'YOUR_TENANT_ID'
CLIENT_ID = 'YOUR_CLIENT_ID'
CLIENT_SECRET = 'YOUR_CLIENT_SECRET'

# Microsoft Graph endpoint
AUTHORITY = f"https://login.microsoftonline.com/{TENANT_ID}"
SCOPE = ["https://graph.microsoft.com/.default"]
GRAPH_ENDPOINT = "https://graph.microsoft.com/v1.0/me"

# Create a confidential client (for daemon or service apps)
app = msal.ConfidentialClientApplication(
    CLIENT_ID,
    authority=AUTHORITY,
    client_credential=CLIENT_SECRET
)

# Acquire token
result = app.acquire_token_for_client(scopes=SCOPE)

if "access_token" in result:
    headers = {"Authorization": f"Bearer {result['access_token']}"}
    response = requests.get(GRAPH_ENDPOINT, headers=headers)

    if response.status_code == 200:
        user = response.json()
        print("User Details:")
        print(f"Display Name: {user.get('displayName')}")
        print(f"Email: {user.get('mail')}")
        print(f"Job Title: {user.get('jobTitle')}")
    else:
        print("Error:", response.status_code, response.text)
else:
    print("Error acquiring token:", result.get("error_description"))

Summary

Access Type	Requires App Registration	Requires Admin Consent	Typical Use Case
SPFx (user context)	No	No	UI components in SharePoint
Python / API client (delegated)	Yes	Sometimes	End-user tools or scripts
App-only (background/migration)	Yes	Yes	Automation, migration
Power Automate / Power Apps	No	Managed by Microsoft	Business process apps

Key Takeaway

SPFx, Power Apps, Power Automate - no need for manual tokens or registration.
Custom Python, Node.js, C#, or background services require App Registration + Tokenization for secure access.
Admin consent is only needed when app scopes exceed user-level permissions.