Ermanno Goletto

Cloud, Guide, Microsoft 365
29 Maggio 2026

Configurare l’accesso applicativo ad una Shared Mailbox in Exchange Online tramite IMAP con autenticazione OAuth2

Negli ultimi anni Microsoft ha progressivamente eliminato il supporto alla Basic Authentication nei servizi di Microsoft 365, imponendo l’adozione della Modern Authentication basata su OAuth2 anche per i protocolli legacy come IMAP, POP e SMTP. Questo cambiamento ha un impatto significativo su molte applicazioni aziendali come ad esempio applicativi gestionali, CRM, sistemi di ticketing o integrazioni middleware che possono dover accedere alle caselle di posta tramite IMAP per leggere o elaborare messaggi. A riguardo si veda il post Announcing OAuth 2.0 support for IMAP, SMTP client protocols in Exchange Online del 30 Aprile 2020.

In questo articolo vedremo come configurare Microsoft Entra ID ed Exchange Online per consentire ad un’applicazione di accedere tramite IMAP con autenticazione OAuth2 a una casella di posta condivisa (Shared Mailbox).

L’obbiettivo dell’articolo è quello di fornire una guida per consentire ad un’applicazione di accedere ad una Shared Mailbox con IMAP tramite OAuth2 analizzando nel dettaglio i seguenti passi:

registrazione dell’applicazione in Microsoft Entra ID
assegnazione dei permessi necessari all’ applicazione in Microsoft Entra ID
configurazione del Service Principal in Exchange Online relativo all’ applicazione in Microsoft Entra ID
concessione dei permessi sulla casella di posta condivisa al Service Principal in Exchange Online
configurazione della casella di posta condivisa per l’accesso tramite IMAP
test di connessione

Scenario e prerequisiti

Nell’articolo si ipotizzerà di dover consentire ad una applicazione gestionale che supporta il protocollo IMAP e l’autenticazione OAuth2 di accedere mediante il protocollo IMAP ad una casella di posta condivisa denominata [email protected].

I prerequisiti per poter eseguire le configurazioni richieste sono l’accesso amministrativo a Exchange Online e Microsoft Entra ID e la disponibilità di Exchange Online PowerShell (a riguardo si veda Connect to Exchange Online PowerShell).

Per meglio comprendere i passi necessari alla configurazione occorre analizzare l’architettura della soluzione che permette all’applicazione di accedere ad una casella condivisa con IMAP tramite autenticazione OAuth2.

L’applicazione che necessita di accedere alla casella di posta condivisa non utilizza più credenziali username/password per accedere alla mailbox, ma deve prima ottenere un OAuth2 Access Token da Microsoft Entra ID. Per farlo utilizza i parametri associati alla propria identità registrata nel tenant, ovvero l’applicazione applicazione registrata in Microsoft Entra ID:

Client ID
Tenant ID
Client Secret

L’App registrata in Microsoft Entra ID rappresenta l’identità dell’applicazione all’interno del tenant Microsoft 365 e tramite essa vengono configurati i permessi API necessari per accedere a Exchange Online. Quindi App registrata in Microsoft Entra ID oltre a rappresentare l’identità dell’applicazione definisce anche cosa l’applicazione è autorizzata a fare all’interno del tenant.

Una volta ottenuto il token, l’applicazione può utilizzarlo per autenticarsi verso Exchange Online tramite il meccanismo SASL XOAUTH2.

Microsoft Entra ID svolge il ruolo di Identity Provider (IdP) nel processo di autenticazione rilasciando a fronte di una richiesta valida un Access Token OAuth2 che svolge le seguenti:

identifica l’applicazione
contiene i permessi concessi
è firmato da Entra ID
ha una validità temporale limitata

Il token verrà poi utilizzato per autenticarsi verso Exchange Online.

Occorre però precisare che quando un’applicazione viene registrata in Entra ID, Exchange Online non la riconosce automaticamente. Per consentire l’accesso ai servizi Exchange è necessario creare un Service Principal corrispondente che rappresenta l’identità dell’applicazione all’interno di Exchange Online.

Il Service Principal ha due funzioni principali:

rappresentare l’applicazione nel contesto di Exchange Online
permettere l’assegnazione di permessi sulle mailbox

In altre parole, il Service Principal è il meccanismo che consente a Exchange Online di associare l’Access Token ricevuto con un’entità autorizzata ad accedere alle mailbox.

Exchange Online è il servizio di posta che ospita le mailbox e quando l’applicazione stabilisce una connessione IMAP verso il server Exchange Online che verifica:

la validità del token
che il Service Principal associato abbia i permessi necessari

Se tutte le verifiche hanno esito positivo, la sessione IMAP viene autenticata e per permettere l’accesso alla casella di posta condivisa è necessario concedere al Service Principal i permessi appropriati sulla mailbox.

Quindi il flusso di autenticazione può essere riassunto nei seguenti passaggi:

L’applicazione utilizza i dati dell’App registrata in Microsoft Entra ID per autenticarsi verso Microsoft Entra ID.
Microsoft Entra ID verifica l’identità dell’applicazione e rilascia un Access Token OAuth2 con i permessi richiesti.
L’applicazione apre una connessione IMAP verso Exchange Online.
L’applicazione invia il comando AUTHENTICATE XOAUTH2 includendo il token OAuth2.
Exchange Online valida il token e identifica il Service Principal associato all’ App registrata in Microsoft Entra ID, ovvero all’applicazione.
Exchange Online verifica che il Service Principal abbia i permessi sulla Shared Mailbox.
Se la verifica ha esito positivo, la connessione IMAP viene autorizzata e l’applicazione può accedere ai messaggi della mailbox.

Per ulteriori approfondimenti si veda anche Authenticate an IMAP, POP or SMTP connection using OAuth | Microsoft Learn.

Figura 1: Flusso di autenticazione per l’accesso applicativo ad una cassetta di posta condivisa tramite OAuth2

Registrazione App in Entra ID

Il primo passo per consentire a un’applicazione di accedere a Exchange Online tramite IMAP con autenticazione OAuth2 consiste nel registrare l’applicazione all’interno di Microsoft Entra ID.

La registrazione crea un’identità applicativa nel tenant Microsoft 365 che potrà essere utilizzata per richiedere token OAuth2 e accedere ai servizi Microsoft.

Durante questo processo verranno generati alcuni identificativi fondamentali che l’applicazione dovrà utilizzare per autenticarsi:

ID applicazione (client)
ID della directory (tenant)
Client Secret

Questi identificativi consentono all’applicazione di autenticarsi verso Microsoft Entra ID e ottenere un Access Token OAuth2 da utilizzare successivamente per accedere a Exchange Online.

Per una gestione più sicura degli accessi applicativi conviene registrare un App in Entra ID per ogni applicazione che ha necessità di accedere a caselle di posta anche se si tratta sempre della stessa casella. Come indicato precedentemente l’App registrata in Microsoft Entra ID rappresenta l’identità dell’applicazione all’interno del tenant Microsoft 365 e quindi per poter discriminare gli accessi applicativi in base alla specifica applicazione occorre registrare un’App in Microsoft Entra ID per ogni applicazione. Per ulteriori informazioni si veda anche Security best practices for application properties – Microsoft identity platform | Microsoft Learn dove viene appunto riportato quanto segue:

“Review the credentials used in applications for freshness of use and their expiration. An unused credential on an application can result in a security breach. Rollover credentials frequently and don’t share credentials across applications. Don’t have many credentials on one application.”

Per registrare una nuova App in Microsoft Entra ID è necessario accedere al portale di amministrazione di Microsoft Entra ID e utilizzare la seguente procedura:

Accedere al portale di Microsoft Entra
https://entra.microsoft.com.
Nel menu laterale selezionare Registrazioni app.
Selezionare Nuova registrazione
Compilare i parametri principali:
1. Nome: Nome descrittivo dell’applicazione (ad esempio EO App OAuth IMAP Fatture)
2. Tipi di account supportati: Solo tenant singolo
3. URI di reindirizzamento (facoltativo): Non necessario per scenari IMAP application
Confermare con Registra.

Figura 2: Registrazione app in Microsoft Entra

Recupero degli identificativi dell’App in Entra ID

Dopo la registrazione dell’App è possibile visualizzare nella schermata di overview dell’App i principali identificativi necessari alla configurazione dell’applicazione e del Service Principal in Exchange Online:

Nome visualizzato: Nome descrittivo
ID applicazione (client): Identificativo univoco dell’applicazione
Directory (tenant) ID: Identificativo del tenant Microsoft 365
ID oggetto: Identificativo dell’oggetto applicativo nel tenant

Come detto precedente, l’applicazione utilizzerà il Directory (tenant) ID e l’ID applicazione (client) quando richiederà il token OAuth2 a Microsoft Entra ID, mentre per la creazione del Service Principal in Exchnage Online sarà necessario l’ID oggetto.

Figura 3: Identificativi dell’App in Entra ID

Creazione di un Client Secret per l’App in Entra ID

Per consentire all’applicazione di autenticarsi è necessario generare una credenziale. Nel caso più comune si utilizza un Client Secret che può essere creato con la seguente procedura:

Accedere al portale di Microsoft Entra
https://entra.microsoft.com.
Nel menu laterale selezionare Registrazioni app.
Selezionare Tutte le applicazioni e ricercare l’App creata (EO App OAuth IMAP Fatture).
Aprire l’App e quindi selezionare nel menù laterale dell’App Gestione /
Certificati e segreti.
Selezionare Nuovo segreto client.
Digitare una Descrizione (per esempio EO App CS OAuth IMAP Fatture 2026)
Selezionare una Scadenza (per esempio 12 mesi).
Selezionare Aggiungi.

Figura 4: Creazione Client Secret per l’App in Entra ID

Microsoft Entra ID genererà il valore del Client Secret. Si noti che il valore del secret è visibile solo al momento della creazione, di conseguenza è necessario copiarlo immediatamente e conservarlo in modo sicuro.

Figura 5: Salvataggio del Valore del Client Secret

Configurazione dei permessi API per l’accesso IMAP sull’App in Entra ID

Dopo aver registrato l’applicazione in Microsoft Entra ID, il passo successivo consiste nel configurare i permessi API che consentiranno all’applicazione di accedere a Exchange Online tramite IMAP utilizzando OAuth2.

I permessi API definiscono quali operazioni l’applicazione è autorizzata a eseguire sui servizi Microsoft 365.

Senza i permessi corretti, Microsoft Entra ID non rilascerà un Access Token valido per Exchange Online, impedendo quindi l’autenticazione IMAP.

Microsoft Entra ID supporta due principali modelli di autorizzazione:

Delegated permissions: l’applicazione agisce per conto di un utente autenticato.
Application permissions: l’applicazione agisce autonomamente senza un utente.

Nel contesto di una integrazione server-to-server, come ad esempio un’applicazione gestionale o un servizio backend che accede a una Shared Mailbox, è generalmente preferibile utilizzare Application Permissions, poiché l’applicazione opera in modo indipendente da un utente.

Per consentire a un’applicazione di accedere a Exchange Online tramite IMAP con OAuth2 è necessario configurare uno dei seguenti permessi in base al modello di autorizzazione:

Permesso	Modello di autorizzazione	Note
IMAP.AccessAsUser.All	Delegated	Consente all’applicazione di accedere alle mailbox tramite IMAP per conto di un utente.
IMAP.AccessAsApp	Application	Consente all’applicazione di accedere alle mailbox tramite IMAP come applicazione.

Quindi per gli scenari di integrazione applicativa con Shared Mailbox è generalmente consigliato utilizzare il permesso IMAP.AccessAsApp che consente all’applicazione di accedere direttamente alle mailbox senza dipendere dal contesto di un utente autenticato.

Per configurare i permessi necessari è possibile utilizzare la seguente procedura:

Accedere al portale di Microsoft Entra
https://entra.microsoft.com.
Nel menu laterale selezionare Registrazioni app.
Selezionare Tutte le applicazioni e ricercare l’App creata (EO App OAuth IMAP Fatture).
Aprire l’App e quindi selezionare nel menù laterale dell’App Gestione /
Autorizzazioni API.
Selezionare Aggiungi un’autorizzazione.
Selezionare API usate dall’organizzazione.
Ricercare Office 365 e quindi selezionare Office 365 Exchange Online (si veda la Figura 6).
Selezionare le Autorizzazioni applicazione.
Ricercare IMAP e quindi selezionare IMAP.AccessApp.
Selezionare Aggiungi autorizzazioni (si veda la Figura 7).
Dopo aver aggiunto il permesso API, è necessario concedere il consenso amministrativo (Admin Consent) affinché l’applicazione possa effettivamente utilizzare tali permessi. Questa operazione deve essere eseguita da un amministratore globale o da un amministratore con privilegi adeguati selezionando l’autorizzazione IMAP.AccessApp e l’opzione Consentire consenso amministratore, quindi confermare con Sì alla richiesta di conferma (si veda la Figura 8).

Figura 6: Selezione delle API per Office 365 Exchange Online

Figura 7: Aggiunta dell’Autorizzazione applicativa IMAP.AccessApp

Figura 8: Concessione del Consenso Amministrativo per l’Autorizzazione applicativa IMAP.AccessApp

Si noti che per default viene concessa l’autorizzazione Microsoft Graph / User.Read, ma tale autorizzazione può essere rimossa dal momento che l’accesso alla Shared Mailbox avviene tramite Service Principal e non tramite un utente, di conseguenza l’autorizzazione Microsoft Graph / User.Read (delegated permission).

Quando si crea una nuova app in Entra ID, viene aggiunta automaticamente l’autorizzazione User.Read (delegated permission per Microsoft Graph), ma questa serve solo per scenari interactive login e non ha alcuna utilità negli scenari app‑only. Quindi è possibile rimuovere tale autorizzazione selezionando Sì, rimuovi nel messaggio di richesta di confema (si veda la Figura 9). Per ulteriori informazioni si veda Microsoft Graph permissions reference – Microsoft Graph | Microsoft Learn.

Figura 9: Rimozione dell’autorizzazione Microsoft.Graph / User.Read

Creazione del Service Principal in Exchange Online

Dopo aver registrato l’applicazione in Microsoft Entra ID e configurato i permessi API necessari, è necessario creare il corrispondente Service Principal in Exchange Online.

Questo passaggio è fondamentale perché Exchange Online deve poter riconoscere l’applicazione che presenterà il token OAuth2 durante l’autenticazione IMAP.

Il Service Principal rappresenta l’identità applicativa nel contesto di Exchange Online.

Quando Microsoft Entra ID emette un Access Token OAuth2 questo identifica l’applicazione, ma Exchange Online deve poter associare quel token a un’entità autorizzata che è rappresentata dal Service Principal.

In altre parole, il Service Principal consente di rappresentare l’applicazione all’interno di Exchange Online, assegnare permessi sulle mailbox e autorizzare l’accesso IMAP tramite OAuth2.

La creazione di un Service Principal deve essere fatta mediante i seguenti comandi PowerShell del modulo Exchange Online PowerShell.

# Installazione del modulo Exchange Online PowerShell (se necessario)

Install-Module ExchangeOnlineManagement -Organization <Directory (tenant) ID>

# Connessione ad Exchange Online tramite un account con i privilegi amministrativi in Exchange Online

Connect-ExchangeOnline

# Creazione del Service Principal

New-ServicePrincipal -AppId <ID applicazione (client)> -ObjectId <ID oggetto> -DisplayName "EO Service Principal per EO App OAuth IMAP Fatture"

Per gli ID necessari si faccia riferimento alla sezione precedente “Recupero degli identificativi dell’App in Entra ID”

Per verificare che il Service Principal sia stato creato correttamente è possibile utilizzare il seguente comando:

1 2	Get-ServicePrincipal \| fl

Assegnazione dei permessi alla Shared Mailbox

Dopo aver creato il Service Principal in Exchange Online, è necessario autorizzarlo ad accedere alla Shared Mailbox.

Questo passaggio è fondamentale perché, anche se l’applicazione possiede un token OAuth2 valido e il Service Principal è correttamente registrato, Exchange Online consentirà l’accesso alla mailbox solo se il Service Principal dispone dei permessi necessari.

In altre parole, il token OAuth2 autentica l’applicazione, mentre i permessi sulla mailbox ne autorizzano l’accesso ai contenuti.

Exchange Online, infatti, verifica la validità del token OAuth2 e i permessi assegnati al Service Principal sulla mailbox e solo se entrambe le verifiche hanno esito positivo la connessione IMAP viene autenticata.

Per consentire all’applicazione di leggere i messaggi tramite IMAP è generalmente necessario assegnare il permesso FullAccess ovvero Lettura e gestione (accesso completo):

L’assegnazione dei permessi sulla Shared Mailbox al Service Principal deve essere fatta mediante i seguenti comandi PowerShell del modulo Exchange Online PowerShell.

# Installazione del modulo Exchange Online PowerShell (se necessario)

Install-Module ExchangeOnlineManagement -Organization <Directory (tenant) ID>

# Connessione ad Exchange Online tramite un account con i privilegi amministrativi in Exchange Online

Connect-ExchangeOnline

# Impostazione del Service Principal

$EOServicePrincipal = Get-ServicePrincipal -Identity "EO Service Principal per EO App OAuth IMAP Fatture"

# Impostazione dei permessi FullAccess sulla Shared Mailbox

Add-MailboxPermission -Identity "[email protected]" -User $EOServicePrincipal.Identity -AccessRights FullAccess

Per verificare che i permessi di accesso siano stati assegnaticorrettamente è possibile utilizzare il seguente comando:

1 2	Get-MailboxPermission -Identity "[email protected]"

In alternativa è anche possibile verificare dalla console di Exchange Online che nelle impostazioni di Delega della casetta postale condivisa il Service Principal risulti presente come membro nelle autorizzazioni “Lettura e gestione (accesso completo)”.

Test di accesso alla Shared Mailbox tramite IMAP con autenticazione OAuth2 mediante PowerShell

Dopo aver completato la configurazione è consigliabile eseguire un test di connessione tramite PowerShell per verificare che:

il token OAuth2 venga emesso correttamente
Exchange Online accetti l’autenticazione OAuth2
il Service Principal abbia accesso alla Shared Mailbox
la connessione IMAP venga autenticata con successo

Di seguito un esempio delle istruzioni PowerShell per verificare che tutto funzioni correttamente, per eseguire il test è necessario che il computer da cui si esegue il test possa accedere ad Internet mediante le porte TCP 443 (Https) e 993 (IMAPS).

Di seguito il codice PowerShell necessario per verificare che il token OAuth2 venga emesso correttamente.

# Parametri

$TenantId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

$ClientId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

$ClientSecret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

$SharedMailbox = fatture@azienda.it

$Scope = https://outlook.office365.com/.default

# Endpoint OAuth2

$TokenEndpoint = "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token"

# Richiesta token OAuth2

$Body = @{client_id = $ClientId; scope = $Scope; client_secret = $ClientSecret; grant_type = "client_credentials"}

$TokenResponse = Invoke-RestMethod -Method Post -Uri $TokenEndpoint -Body $Body -ContentType "application/x-www-form-urlencoded"

$AccessToken = $TokenResponse.access_token

If ($AccessToken) {Write-Host "Token ottenuto correttamente"} Else {Write-Host "Errore ottenimento token"; Exit}

Ottenuto il token OAuth2 è possibile verificare che la connessione IMAP venga stabilita correttamente utilizzando il seguente codice PowerShell.

# Costruzione payload XOAUTH2

$XOAuthString = "user=$SharedMailbox" + [char]1 + "auth=Bearer $AccessToken" + [char]1 + [char]1

$XOAuthBytes = [System.Text.Encoding]::ASCII.GetBytes($XOAuthString)

$XOAuthBase64 = [Convert]::ToBase64String($XOAuthBytes)

# Connessione IMAP SSL

$TcpClient = New-Object System.Net.Sockets.TcpClient

$TcpClient.Connect("outlook.office365.com", 993)

$SslStream = New-Object System.Net.Security.SslStream($TcpClient.GetStream(), $false, ({ $true}))

$SslStream.AuthenticateAsClient("outlook.office365.com")

$StreamReader = New-Object System.IO.StreamReader($SslStream)

$StreamWriter = New-Object System.IO.StreamWriter($SslStream)

$StreamWriter.AutoFlush = $true

# Lettura Banner IMAP

$Response = $StreamReader.ReadLine()

Write-Host "SERVER: $Response"

# Invio autenticazione XOAUTH2

Write-Host "Invio autenticazione XOAUTH2..."

$StreamWriter.WriteLine("A1 AUTHENTICATE XOAUTH2 $XOAuthBase64")

# Lettura risposta server

Start-Sleep -Milliseconds 500

Do {$Response=$StreamReader.ReadLine(); Write-Host "SERVER: $Response"} Until ($Response -match "^A1 ")

# Chiusura connessione

$StreamWriter.WriteLine("A2 LOGOUT")

$StreamWriter.Close()

$StreamReader.Close()

$SslStream.Close()

$TcpClient.Close()

Il codice PowerShell proposto è volutamente semplice per poter essere utilizzato anche nella Shell tramite copia e incolla, senza la necessità di creare uno script.

Se il test ha successo si dove ottenere un output di questo tipo:

Token ottenuto correttamente

SERVER: * OK The Microsoft Exchange IMAP4 service is ready. (BACKENDAUTHENTICATE) [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]

SERVER: A1 OK AUTHENTICATE completed.

Considerazioni finali

Terminata e testata la configurazione dell’accesso applicativo ad una Shared Mailbox in Exchange Online tramite IMAP con autenticazione OAuth2 è possibile utilizzare i valori client id, client secret e tenant id in applicazioni di terze che supportano OAUTH.

In scenari moderni di integrazione con Exchange Online, l’utilizzo di OAuth2 rappresenta ormai un requisito imprescindibile, soprattutto dopo la dismissione della Basic Authentication da parte di Microsoft. Anche per protocolli storicamente “legacy” come IMAP, il modello di autenticazione si è evoluto verso un approccio basato su identità applicative, consenso amministrativo e autorizzazioni granulari.

La configurazione descritta consente di mantenere compatibilità con applicazioni che richiedono ancora l’accesso IMAP, introducendo al tempo stesso un livello di sicurezza significativamente superiore rispetto alle modalità tradizionali basate su username e password.

Dal punto di vista operativo, è consigliabile adottare una gestione centralizzata delle autorizzazioni tramite gruppi di sicurezza e limitare l’accesso alle sole mailbox strettamente necessarie. In questo modo si ottiene una soluzione più scalabile, governabile e coerente con le moderne pratiche di Identity & Access Management.