Scegliere il meccanismo di autenticazione corretto
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Per le applicazioni che si interfacciano con Azure DevOps Services, è necessario eseguire l'autenticazione per ottenere l'accesso alle risorse come le API REST. Questo articolo fornisce indicazioni utili per scegliere il meccanismo di autenticazione appropriato per l'applicazione.
La tabella seguente illustra i concetti di autenticazione suggeriti da considerare per diversi scenari di applicazione. Per iniziare, vedere le descrizioni, gli esempi e gli esempi di codice correlati.
| Tipo di applicazione | Descrizione | Esempio | Meccanismo di autenticazione | Esempi di codice |
|---|---|---|---|---|
| App sul lato client interattiva (REST) | Applicazione client che consente all'utente di chiamare le API REST di Azure DevOps Services | Applicazione console che enumera i progetti in un'organizzazione | OAuth con Microsoft Authentication Library (MSAL) | sample |
| App sul lato client interattiva (librerie client) | Applicazione client che consente l'interazione dell'utente chiamando le librerie client di Azure DevOps Services | Applicazione console che enumera i bug assegnati all'utente corrente | OAuth con librerie client | sample |
| App lato client non interattiva | Applicazione solo testo headless sul lato client | App console che visualizza tutti i bug assegnati a un utente | Flusso del profilo dispositivo | sample |
| Token di accesso personale | Token di connessione per accedere alle proprie risorse | Utilizza il PAT al posto della password per le chiamate REST ad hoc. Non ideale per le applicazioni. | Carezze | esempi |
| App server | App Azure DevOps Server con la libreria CLIENT OM | Estensione azure DevOps Server che visualizza i dashboard dei bug del team | Librerie client | sample |
| Principale del servizio o identità gestita | Applicazione con la propria identità | Funzione di Azure per creare elementi di lavoro | Entità servizio e identità gestite | sample |
| Estensione Web | Estensione di Azure DevOps Services | Estensione Schede Agile | VSS Web Extension SDK | sample |
Suggerimento
L'autenticazione basata su Entra è la nostra raccomandazione per gli sviluppatori che vogliono integrarsi con Azure DevOps Services, se si utilizzano account Microsoft Entra. Le app di esempio OAuth in questa tabella usano Piattaforma di gestione delle identità di Microsoft Entra per lo sviluppo di app.
Per l'autenticazione con account Microsoft (MSA) o con Azure DevOps, consultare le librerie client o i PAT .
Per maggiori dettagli, leggere nel nostro blog su come stiamo riducendo l'uso di PAT nella nostra piattaforma.
Domande frequenti
D: Perché l'account del servizio non può accedere all'API REST di Azure DevOps?
R: L'account del servizio potrebbe non avere "materializzato". Gli account di servizio senza autorizzazioni di accesso interattive non possono accedere. Per altre informazioni, vedere questa soluzione alternativa.
D: È consigliabile usare le librerie client di Azure DevOps Services o le API REST di Azure DevOps Services per l'applicazione sul lato client interattiva?
R: È consigliabile usare le librerie client di Azure DevOps Services sulle API REST per accedere alle risorse di Azure DevOps Services. Sono più semplici e facili da gestire quando cambiano le versioni degli endpoint REST. Se le librerie client non dispongono di determinate funzionalità, usare MSAL per l'autenticazione con le API REST.
D: Questo materiale sussidiario è valido solo per Azure DevOps Services o per gli utenti locali di Azure DevOps Server?
R: Queste indicazioni sono principalmente per gli utenti di Azure DevOps Services. Per gli utenti di Azure Devops Server, è consigliabile usare le librerie client, l'autenticazione di Windows o i token di accesso personale per l'autenticazione.
D: Cosa accade se si vuole che l'applicazione esegua l'autenticazione con Azure DevOps Server e Azure DevOps Services?
R: La procedura consigliata consiste nell'avere percorsi di autenticazione separati per Azure DevOps Server e Azure DevOps Services. È possibile usare per requestContext determinare il servizio a cui si accede e quindi applicare il meccanismo di autenticazione appropriato. Se si preferisce una soluzione unificata, i criteri di configurazione funzionano per entrambi.