Het juiste verificatiemechanisme kiezen
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Voor toepassingen die interface hebben met Azure DevOps Services, moet u zich verifiëren om toegang te krijgen tot resources zoals REST API's. Dit artikel bevat richtlijnen om u te helpen bij het kiezen van het juiste verificatiemechanisme voor uw toepassing.
De volgende tabel bevat een overzicht van voorgestelde verificatieconcepten die moeten worden overwogen voor verschillende toepassingsscenario's. Raadpleeg de bijbehorende beschrijvingen, voorbeelden en codevoorbeelden om u op weg te helpen.
| Type toepassing | Beschrijving | Voorbeeld | Verificatiemechanisme | Codevoorbeelden |
|---|---|---|---|---|
| Interactieve app aan clientzijde (REST) | Clienttoepassing waarmee gebruikersinteractie azure DevOps Services REST API's aanroept | Consoletoepassing die projecten in een organisatie opsommen | OAuth met Microsoft Authentication Library (MSAL) | monster |
| Interactieve client-side app (clientbibliotheken) | Clienttoepassing waarmee gebruikers kunnen communiceren met Azure DevOps Services via -clientbibliotheken | Consoletoepassing die fouten opsommen die zijn toegewezen aan de huidige gebruiker | OAuth met clientbibliotheken | monster |
| Niet-interactieve app aan clientzijde | Alleen hoofdloze teksttoepassing aan de clientzijde | Console-app met alle bugs die zijn toegewezen aan een gebruiker | OAuth met apparaatprofiel stroom | monster |
| Persoonlijk toegangstoken (PAT) | Bearer-token voor toegang tot uw eigen resources | Gebruik uw PAT in plaats van uw wachtwoord voor ad-hoc REST-aanroepen. Niet ideaal voor toepassingen. | Pats | voorbeelden |
| Server-app | Azure DevOps Server-app met behulp van de Client OM-bibliotheek | Azure DevOps Server-extensie met dashboards voor teamfouten | Clientbibliotheken | monster |
| Service principal of beheerde identiteit | Toepassing met een eigen identiteit | Azure-functie voor het maken van werkitems | Service-principals en beheerde identiteiten | monster |
| Webextensie | Azure DevOps Services -extensie | Agile Cards-extensie | VSS Web Extension SDK | monster |
Tip
verificatie op basis van Entra is onze aanbeveling voor ontwikkelaars die willen integreren met Azure DevOps Services, als u interactie hebt met Microsoft Entra-accounts. De OAuth-voorbeeld-apps in deze tabel gebruiken identiteitsplatform van Microsoft Entra voor app-ontwikkeling.
Voor authenticatie met Microsoft-accounts (MSA) of voor gebruikers van Azure DevOps Server, neem een kijkje in onze clientbibliotheken of PAT's.
Lees meer in onze blog over hoe we het PAT-gebruik op ons platform verminderen.
Veelgestelde vragen (FAQ's)
V: Waarom kan mijn serviceaccount geen toegang krijgen tot de Azure DevOps REST API?
A: Uw serviceaccount is mogelijk niet 'gerealiseerd'. Serviceaccounts zonder interactieve aanmeldingsmachtigingen kunnen zich niet aanmelden. Zie deze oplossing voor meer informatie.
V: Moet ik Azure DevOps Services-clientbibliotheken of Azure DevOps Services REST API's gebruiken voor mijn interactieve toepassing aan de clientzijde?
A: We raden u aan azure DevOps Services-clientbibliotheken te gebruiken via REST API's voor toegang tot Azure DevOps Services-resources. Ze zijn eenvoudiger en eenvoudiger te onderhouden wanneer REST-eindpuntversies worden gewijzigd. Als de clientbibliotheken bepaalde functionaliteit missen, gebruikt u MSAL voor verificatie met onze REST API's.
V: Is deze richtlijnen alleen voor Azure DevOps Services of is deze ook relevant voor on-premises Azure DevOps Server-gebruikers?
A: Deze richtlijnen zijn voornamelijk bedoeld voor Gebruikers van Azure DevOps Services. Voor Azure Devops Server-gebruikers wordt u aangeraden de clientbibliotheken, Windows-verificatie of PERSOONLIJKE toegangstokens (PAT's) te gebruiken voor verificatie.
V: Wat gebeurt er als ik wil dat mijn toepassing wordt geverifieerd met zowel Azure DevOps Server als Azure DevOps Services?
A: De aanbevolen procedure is om afzonderlijke verificatiepaden te hebben voor Azure DevOps Server en Azure DevOps Services. U kunt de requestContext functie gebruiken om te bepalen welke service u gebruikt en vervolgens het juiste verificatiemechanisme toe te passen. Als u de voorkeur geeft aan een geïntegreerde oplossing, werken PAW's voor beide.