Come verificare le app OAuth di terze parti su Slack, GitHub e Microsoft 365

Per verificare le app OAuth di terze parti, controllate separatamente l'elenco di autorizzazione di ciascuna piattaforma: la pagina Installed Apps di Slack, la policy delle app OAuth dell'organizzazione GitHub e l'elenco delle applicazioni aziendali di Microsoft Entra. Ciascuna mostra una porzione diversa dello stesso problema di fondo — quali app possono agire sui vostri dati — e nessuna delle tre mostra le altre due.

Questa guida fornisce il percorso esatto per ciascuna piattaforma, cosa mostra e dove una verifica per singola piattaforma si esaurisce.

Dove posso vedere le app OAuth autorizzate in Slack?

Andate su Settings & administration → Manage apps, che apre il Slack Marketplace limitato al vostro workspace, quindi selezionate Installed Apps in alto nella barra laterale. Questa funzione è disponibile su ogni piano Slack ed elenca ogni app installata con gli scope per cui è stata approvata.

Su Enterprise Grid, la sezione Integrations della dashboard amministrativa aggiunge una vista a livello di organizzazione su tutti i workspace contemporaneamente. Questa vista cross-workspace è resa possibile dallo scope admin.apps:read, che è riservato a Enterprise Grid e — anche lì — mostra soltanto quali app sono approvate, limitate o in attesa; non espone l'elenco completo degli scope di ogni app nella stessa chiamata. Su un singolo workspace, la pagina Installed Apps resta la fonte autorevole di ciò che un'app può effettivamente fare.

Dove posso vedere le app OAuth autorizzate in GitHub?

Andate su Settings → Third-party Access → OAuth app policy della vostra organizzazione. Le nuove organizzazioni hanno per impostazione predefinita le restrizioni di accesso alle app OAuth attive, quindi questa pagina è anche il punto in cui i membri richiedono l'accesso a una nuova app e in cui un owner la approva o la nega. Per revocare un'app precedentemente approvata, individuatela nello stesso elenco e selezionate Deny access.

Le GitHub Apps (un meccanismo distinto dalle classiche OAuth Apps, utilizzato dalla maggior parte delle integrazioni moderne) si verificano in un punto diverso: Settings → Integrations → GitHub Apps (o Installed GitHub Apps) dell'organizzazione elenca ciò che è installato e quali repository ciascuna app può raggiungere.

A partire dal 2026, un'organizzazione può inoltre impostare controlli graduati su chi è autorizzato persino a *richiedere* una nuova app, da Settings → Third-party Access: sia i membri sia i collaboratori esterni possono richiedere app (l'impostazione predefinita di lunga data), i collaboratori esterni possono essere bloccati mentre i membri possono ancora fare richiesta, oppure entrambi i gruppi possono essere impossibilitati a richiedere qualsiasi app — restringendo la superficie di verifica prima ancora che una richiesta arrivi alla coda di un owner. La restrizione di accesso alle app OAuth a livello di organizzazione può anche essere disattivata del tutto, il che rimuove il passaggio di approvazione per ogni membro — un'impostazione che vale la pena confermare sia ancora attiva prima di considerare l'elenco della OAuth app policy un registro completo di ciò che è stato autorizzato.

Dove posso vedere le app OAuth autorizzate in Microsoft 365?

Accedete al Microsoft Entra admin center e andate su Identity → Applications → Enterprise applications → All applications. Selezionate un'app, quindi Permissions. La scheda Admin consent mostra le autorizzazioni concesse per l'intero tenant — e può essere revocata direttamente lì. La scheda User consent mostra ciò che i singoli utenti hanno approvato per se stessi — e il portale non offre un pulsante di revoca per questo; per revocarla è necessaria una chiamata alle API di Microsoft Graph o un cmdlet PowerShell eseguito da qualcuno con il ruolo Cloud Application Administrator. Se un tenant blocca del tutto il consenso utente, un Global Administrator può attivare invece un flusso di lavoro di consenso amministrativo, così una richiesta bloccata diventa qualcosa da riesaminare anziché un vicolo cieco — consultate la guida sull'accesso a Microsoft 365 per il funzionamento esatto di quella coda di revisione.

Perché una verifica per singola piattaforma è difficile da mantenere aggiornata?

Tre console, tre formati, tre ruoli amministrativi diversi richiesti anche solo per aprirle. La vista programmatica a livello di organizzazione di Slack richiede Enterprise Grid; le autorizzazioni a livello utente di Microsoft richiedono PowerShell o Graph, non un clic nel portale; GitHub separa le classiche OAuth Apps dalle GitHub Apps come due elenchi distinti che un amministratore deve sapere di dover controllare separatamente. Slack, inoltre, suddivide la propria vista Installed Apps nelle schede Approved, Restricted e Requests, quindi una verifica completa richiede il controllo di tre filtri oltre alle tre piattaforme. Nessuna delle tre classifica un'app per livello di rischio, e nessuna delle tre vi dice se lo stesso fornitore è connesso anche sulle altre due piattaforme con un insieme più ampio di autorizzazioni.

Cosa non può dirvi un elenco per singola piattaforma, e come risponde 8200.dev

Ciascuna console vi dice cosa è autorizzato su quella singola piattaforma. Nessuna vi mostra il quadro combinato — lo stesso assistente AI per prendere appunti connesso a canali Slack, a un repository GitHub e a una casella di posta Microsoft 365, ciascuno con il proprio scope concesso separatamente. Agent Guard di 8200.dev legge tutte e tre le piattaforme con scope di sola lettura a privilegio minimo — per Slack channels:read, groups:read, files:read, users:read e altri scope di lettura correlati oltre a una verifica della configurazione del workspace; per GitHub read:org, accesso in sola lettura ai repository, read:user, inventario delle installazioni, visibilità in sola lettura sulla fatturazione Copilot e read:audit_log; e per Microsoft 365 Sites.Read.All, Files.Read.All, Directory.Read.All, Application.Read.All, User.Read.All, Policy.Read.All, Reports.Read.All, AuditLog.Read.All, RoleManagement.Read.Directory e DelegatedPermissionGrant.Read.All — e riunisce ogni risultato di tutte e tre in un unico inventario con punteggio di rischio. Il connettore Microsoft 365 funziona con la directory work o school Microsoft di qualsiasi organizzazione, non con un singolo tenant fisso, quindi si collega allo stesso modo sia che la vostra organizzazione sia l'unica coinvolta sia che sia una tra diverse.

Ognuno di questi scope è di sola lettura. Nulla qui revoca autonomamente l'accesso di un'app — questo resta una raccomandazione su cui un'organizzazione agisce deliberatamente, oppure un'adesione esplicita per la regola specifica che desidera automatizzare.

Consultate le pagine dei connettori Slack, GitHub e Microsoft 365 per l'elenco completo degli scope e cosa ciascuno analizza.