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 het aanbevolen verificatiemechanisme voor verschillende toepassingstypen. Zie de volgende basisbeschrijvingen, voorbeelden en codevoorbeelden om u op weg te helpen.

Type toepassing	Beschrijving	Voorbeeld	Verificatiemechanisme	Codevoorbeelden
Interactieve clientzijde (REST)	Clienttoepassing waarmee gebruikersinteractie azure DevOps Services REST API's aanroept	Consoletoepassing die projecten in een organisatie opsommen	Microsoft Authentication Library (MSAL)	Monster
Interactieve clientzijde (clientbibliotheek)	Clienttoepassing waarmee gebruikersinteractie azure DevOps Services-clientbibliotheken kunnen aanroepen	Consoletoepassing die fouten opsommen die zijn toegewezen aan de huidige gebruiker	Clientbibliotheken	Monster
Interactief JavaScript	Op GUI gebaseerde JavaScript-toepassing	AngularJS-app met één pagina met projectgegevens voor een gebruiker	Microsoft Authentication Library voor JavaScript (MSAL JS)	Monster
Persoonlijk toegangstoken (PAT)	Bearer-token voor toegang tot uw eigen resources	Gebruik uw PAT in plaats van uw wachtwoord.	Pats
Niet-interactieve clientzijde	Alleen hoofdloze teksttoepassing aan de clientzijde	Console-app met alle bugs die zijn toegewezen aan een gebruiker	Apparaatprofiel	Monster
Interactieve app aan de clientzijde gericht op Azure DevOps	Clienttoepassing die gebruikersinteractie toestaat, verifieert Azure DevOps-gebruikers	Consoletoepassing waarmee Azure DevOps-gebruikers toegewezen fouten kunnen zien	Clientbibliotheek (interactieve en Windows-verificatie)	Monster
Interactief web	Op GUI gebaseerde webtoepassing waarvoor gebruikerstoestemming is vereist	Aangepast webdashboard met samenvattingen van build	Azure DevOps OAuth	Monster
Service-principals of beheerde identiteiten	Toepassing met toegang tot Azure DevOps-resources van de organisatie	Azure-functie voor het maken van werkitems	Service-principals en beheerde identiteiten	Monster
Azure DevOps Server-toepassing	Azure DevOps Server-app met behulp van de Client OM-bibliotheek	Azure DevOps Server-extensie met dashboards voor teamfouten	Clientbibliotheken	Monster
Azure DevOps Services-extensie	Azure DevOps Services-extensie	Agile-kaarten	VSS Web Extension SDK	Monster

Zie Over beveiliging en identiteit voor een inleiding tot beveiligings- en identiteitsconcepten in Azure DevOps. Zie Referentieopslag voor Azure DevOps voor meer informatie over hoe we uw referenties opslaan.

Het inschakelen van IIS-basisverificatie is ongeldig met behulp van PAT's voor Azure DevOps Server

Zie IiS-basisverificatie gebruiken met Azure DevOps on-premises voor meer informatie.

Veelgestelde vragen (FAQ's)

V: Waarom heeft een van mijn serviceaccounts geen toegang tot de Azure DevOps REST API?

A: Uw serviceaccount is mogelijk niet 'gerealiseerd'. Aangezien aanmelden niet mogelijk is met een serviceaccount dat geen interactieve aanmeldingsmachtigingen heeft, bekijkt u dit werk.

V: Ik maak een interactieve toepassing aan de clientzijde. Moet ik Azure DevOps Services-clientbibliotheken of Azure DevOps Services REST API's gebruiken?

A: We raden u aan azure DevOps Services-clientbibliotheken te gebruiken via REST API's bij toegang tot Azure DevOps Services-resources. Ze zijn eenvoudiger en eenvoudiger te onderhouden wanneer versiewijzigingen in onze REST-eindpunten plaatsvinden. Als de functionaliteit ontbreekt in de clientbibliotheken, is MSAL het beste verificatiemechanisme voor gebruik 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. Clientbibliotheken zijn een reeks pakketten die speciaal zijn gebouwd voor het uitbreiden van de Functionaliteit van Azure DevOps Server. Voor on-premises gebruikers raden we u aan om de clientbibliotheken, Windows-verificatie of persoonlijke toegangstokens (PAW's) te gebruiken om te verifiëren voor een gebruiker.

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 verschillende verificatiepaden te hebben voor Azure DevOps Server en Azure DevOps Services. U kunt de requestContext gebruiken om erachter te komen welke treffer u gebruikt en vervolgens het beste mechanisme voor elk item te gebruiken. Als u een geïntegreerde oplossing wilt, werken PAW's voor beide.