Informazioni sull'accesso delegato
Quando un utente accede a un'app e lo usa per accedere ad altre risorse, ad esempio Microsoft Graph, l'app dovrà prima chiedere l'autorizzazione per accedere a questa risorsa per conto dell'utente. Questo scenario comune è denominato accesso delegato.
Perché è consigliabile usare l'accesso delegato?
Persone usare spesso applicazioni diverse per accedere ai dati dai servizi cloud. Ad esempio, un utente potrebbe voler usare un'applicazione di lettura PDF preferita per visualizzare i file archiviati in OneDrive. Un altro esempio può essere l'applicazione line-of-business di un'azienda che potrebbe recuperare informazioni condivise sui colleghi in modo che possano scegliere facilmente i revisori per una richiesta. In questi casi, l'applicazione client, il lettore PDF o lo strumento di approvazione della richiesta dell'azienda deve essere autorizzato ad accedere a questi dati per conto dell'utente che ha eseguito l'accesso all'applicazione.
Usare l'accesso delegato ogni volta che si vuole consentire a un utente connesso di lavorare con le proprie risorse o risorse a cui possono accedere. Che si tratti di un amministratore che configura i criteri per l'intera organizzazione o un utente che elimina un messaggio di posta elettronica nella posta in arrivo, tutti gli scenari che coinvolgono le azioni utente devono usare l'accesso delegato.
Al contrario, l'accesso delegato è in genere una scelta scarsa per gli scenari che devono essere eseguiti senza un utente connesso, ad esempio l'automazione. Può anche essere una scelta scarsa per gli scenari che comportano l'accesso a molte risorse degli utenti, ad esempio la prevenzione della perdita dei dati o i backup. È consigliabile usare l'accesso solo all'applicazione per questi tipi di operazioni.
Richiesta di ambiti come app client
L'app dovrà chiedere all'utente di concedere un ambito specifico o un set di ambiti per l'app di risorse a cui si vuole accedere. Gli ambiti possono anche essere definiti autorizzazioni delegate. Questi ambiti descrivono le risorse e le operazioni che l'app vuole eseguire per conto dell'utente. Ad esempio, se vuoi che l'app mostri all'utente un elenco di messaggi di posta elettronica ricevuti di recente e messaggi di chat, potresti chiedere all'utente di fornire il consenso a Microsoft Graph Mail.Read e Chat.Read agli ambiti.
Dopo che l'app ha richiesto un ambito, un utente o un amministratore dovrà concedere l'accesso richiesto. Gli utenti consumer con account Microsoft, ad esempio Outlook.com o gli account Xbox Live, possono sempre concedere ambiti a se stessi. Gli utenti dell'organizzazione con account Microsoft Entra possono o non essere in grado di concedere ambiti, a seconda delle impostazioni dell'organizzazione. Se un utente dell'organizzazione non può acconsentire direttamente agli ambiti, dovrà chiedere all'amministratore dell'organizzazione di fornire il consenso.
Segui sempre il principio dei privilegi minimi: non devi mai richiedere ambiti non necessari per l'app. Questo principio consente di limitare il rischio di sicurezza se l'app è compromessa e rende più semplice per gli amministratori concedere l'accesso all'app. Ad esempio, se l'app deve elencare solo le chat a cui appartiene un utente, ma non deve mostrare i messaggi di chat stessi, è necessario richiedere l'ambito di Microsoft Graph Chat.ReadBasic più limitato anziché Chat.Read. Per altre informazioni sugli ambiti openID, vedere Ambiti OpenID.
Progettazione e pubblicazione di ambiti per un servizio risorse
Se si sta creando un'API e si vuole consentire l'accesso delegato per conto degli utenti, è necessario creare ambiti che altre app possono richiedere. Questi ambiti devono descrivere le azioni o le risorse disponibili per il client. È consigliabile prendere in considerazione gli scenari di sviluppo durante la progettazione degli ambiti.
Come funziona l'accesso delegato?
L'aspetto più importante da ricordare per l'accesso delegato è che sia l'app client che l'utente connesso devono essere autorizzati correttamente. La concessione di un ambito non è sufficiente. Se l'app client non ha l'ambito corretto o l'utente non dispone di diritti sufficienti per leggere o modificare la risorsa, la chiamata avrà esito negativo.
- Autorizzazione dell'app client: le app client sono autorizzate concedendo ambiti. Quando a un'app client viene concesso un ambito da un utente o da un amministratore per accedere ad alcune risorse, tale concessione verrà registrata in Microsoft Entra ID. Tutti i token di accesso delegati richiesti dal client per accedere alla risorsa per conto dell'utente pertinente conterranno quindi i valori attestazioni degli ambiti nell'attestazione
scp. L'app per le risorse controlla questa attestazione per determinare se all'app client è stato concesso l'ambito corretto per la chiamata. - Autorizzazione utente: gli utenti sono autorizzati dalla risorsa che si sta chiamando. Le app per le risorse possono usare uno o più sistemi per l'autorizzazione utente, ad esempio il controllo degli accessi in base al ruolo, le relazioni di proprietà/appartenenza, gli elenchi di controllo di accesso o altri controlli. Ad esempio, Microsoft Entra ID verifica che un utente sia stato assegnato a un ruolo di gestione delle app o amministratore generale prima di consentire loro di eliminare le applicazioni di un'organizzazione, ma consente anche a tutti gli utenti di eliminare le applicazioni di cui sono proprietari. Analogamente, il servizio SharePoint Online verifica che un utente disponga dei diritti di proprietario o lettore appropriati su un file prima di consentire all'utente di aprirlo.
Esempio di accesso delegato: OneDrive tramite Microsoft Graph
Si consideri l'esempio seguente:
Alice vuole usare un'app client per aprire un file protetto da un'API risorsa, Microsoft Graph. Per l'autorizzazione dell'utente, il servizio OneDrive verificherà se il file viene archiviato nell'unità di Alice. Se è archiviato nell'unità di un altro utente, OneDrive negherà la richiesta di Alice come non autorizzata, perché Alice non ha il diritto di leggere le unità degli altri utenti.
Per l'autorizzazione dell'app client, OneDrive verificherà se al client che effettua la chiamata è stato concesso l'ambito Files.Read per conto dell'utente connesso. In questo caso, l'utente connesso è Alice. Se Files.Read non è stato concesso all'app per Alice, OneDrive avrà esito negativo anche la richiesta.
| GET /drives/{id}/files/{id} | Ambito concesso all'app Files.Read client per Alice |
L'app client non ha concesso Files.Read l'ambito per Alice |
|---|---|---|
| Il documento si trova in OneDrive di Alice. | 200 : accesso concesso. | 403 - Non autorizzato. Alice (o il suo amministratore) non ha consentito a questo client di leggere i file. |
| Il documento si trova in OneDrive*di un altro utente. | 403 - Non autorizzato. Alice non dispone dei diritti per leggere il file. Anche se il cliente lo ha concesso Files.Read deve essere negato quando agisce per conto di Alice. |
403 - Non autorizzato. Alice non dispone dei diritti di lettura di questo file e il client non può leggere i file a cui ha accesso. |
L'esempio specificato è semplificato per illustrare l'autorizzazione delegata. Il servizio OneDrive di produzione supporta molti altri scenari di accesso, ad esempio i file condivisi.