Autentiseringsmetoder för Azure DevOps-integreringar

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Den här artikeln fokuserar på mönster för integreringsautentisering för appar, skript och pipelines som anropar Azure DevOps. Använd modern Microsoft Entra ID-baserad autentisering för nya integreringar eftersom det ger starkare säkerhet och bättre långsiktig kompatibilitet.

Om du behöver en översikt på organisationsnivå som omfattar användarinloggning, styrningskontroller och säkerhetsstatus på plattformsnivå kan du läsa Autentiseringsvägledning för Azure DevOps.

Använd Microsoft Entra ID autentisering för nya program som integreras med Azure DevOps Services. Använd personliga åtkomsttoken sparsamt och endast när Microsoft Entra ID inte är tillgänglig.

Viktigt!

Överväg att använda säkrare Microsoft Entra token över personliga åtkomsttoken med högre risk. Mer information finns i Minska PAT-användningen. Läs autentiseringsvägledningen för att välja rätt autentiseringsmekanism för dina behov.

OAuth 2.0- och Microsoft Entra ID-autentisering är endast tillgängliga för Azure DevOps Services, inte Azure DevOps Server.

För lokala scenarier använder du .NET klientbibliotek, Windows authentication eller personliga åtkomsttoken.

Tips/Råd

Du kan använd AI för att hjälpa till med den här uppgiften senare i den här artikeln, eller se Aktivera AI-hjälp med Azure DevOps MCP Server för att komma igång.

Jämföra vanliga autentiseringsalternativ

Använd följande tabell för att jämföra de vanligaste autentiseringsalternativen för appar, skript och pipelines.

Method Bäst för Säkerhetsstatus Hantering av autentiseringsuppgifter Fungerar med Undvik när
Hanterad identitet Azure värdbaserad automatisering, till exempel Azure Functions, App Service eller virtuella datorer Det starkaste alternativet för Azure värdbaserade arbetsbelastningar eftersom token är kortvariga och Azure hanterar identitetens livscykel Ingen klienthemlighet att lagra eller rotera; Azure hanterar identitets- och tokenförvärvet Azure DevOps Services; Azure värdbaserade arbetsbelastningar i samma Microsoft Entra klientorganisation när du har lagt till identiteten i Azure DevOps Arbetsbelastningen körs inte på Azure, eller så behöver du en bärbar identitet som inte är kopplad till en Azure resurs
Service Principal Automatisering som körs utanför Azure, i flera miljöer eller i externa CI/CD-system Starkt alternativ när du använder certifikatbaserad autentisering eller federerade metoder och tillämpar minst behörighet Du hanterar programidentiteten och alla klienthemligheter eller certifikat om inte ett federerat flöde tar bort hemligheten Azure DevOps Services; appar, skript och tjänster som behöver en Microsoft Entra programidentitet Du kan använda en hanterad identitet i stället för samma Azure värdbaserade arbetsbelastning, eller så stöder verktyget endast PAT-baserad autentisering
Azure DevOps tjänstanslutning Azure-pipelines åtkomst till Azure DevOps resurser Starkt alternativ för pipelineautomatisering eftersom den använder Microsoft Entra arbetsbelastningsidentitetsfederation i stället för långlivade token Azure DevOps hanterar tjänstanslutningen och pipelines behöver inte lagra PAT i variabler Azure DevOps Services; pipelines som har åtkomst till lagringsplatser, feeds eller REST-API:er i organisationer Scenariot går inte igenom Azure-pipelines
Personlig åtkomsttoken (PAT) Kortlivade personliga skript, engångstestning eller äldre scenarier som ännu inte kan använda Microsoft Entra baserad autentisering Störst risk för vanliga val eftersom token är en långlivad ägarhemlighet som är kopplad till ett användarkonto Du måste skapa, lagra, rotera och återkalla token manuellt Azure DevOps Tjänster och Azure DevOps Server; CLI, REST-anrop och äldre integreringar som stöder PAT Integreringen är en produktionstjänst, delad automatisering eller ett scenario där tjänstens huvudnamn, hanterade identitet eller tjänstanslutning är tillgänglig

Snabba rekommendationer

  • Välj hanterad identitet först när arbetsbelastningen körs på Azure och Azure kan äga identitetens livscykel.
  • Välj ett huvudnamn för tjänsten när du behöver en programidentitet, men arbetsbelastningen körs inte på Azure eller måste flyttas mellan miljöer.
  • Välj en Azure DevOps tjänstanslutning när Azure-pipelines behöver komma åt Azure DevOps resurser utan pat.
  • Välj endast en PAT för personliga, tillfälliga, äldre eller Azure DevOps Server scenarier där de säkrare alternativen inte gäller.

Autentiseringsmetoder efter scenario

Välj lämplig autentiseringsmetod baserat på programtyp och krav.

Apptyp beskrivning Exempel Rekommenderad metod Kodexempel
Webb-/skrivbordsappar Interaktiva program som använder aktuella ramverk React-app, .NET skrivbordsapp Microsoft Entra OAuth med Microsofts autentiseringsbibliotek (MSAL) Hanterad klientkonsolapp
Tjänst-/bakgrundsappar Program som körs utan användarinteraktion Azure Functions, bakgrundstjänster Tjänsthuvuden och hanterade identiteter Tjänstens huvudnamn
Äldre klientappar Befintliga program som använder klientbibliotek Konsolappar med Azure DevOps .NET bibliotek .NET klientbibliotek med OAuth Klientbibliotekskonsolapp
Headless-/CLI-applikationer Icke-inaktiva kommandoradsverktyg Skapa skript, automatiseringsverktyg Flöde för beviljande av enhetsauktorisering Enhetsprofil
Azure DevOps tillägg Tillägg som körs inom Azure DevOps Anpassade instrumentpanelswidgetar och arbetsobjektformulär Azure DevOps SDK för webbtillägg Lägga till en instrumentpanelswidget
Azure DevOps Server applikationer Lokala Azure DevOps Server integreringar Anpassade servertillägg .NET klientbibliotek eller Windows Auth Klientbibliotekskonsolapp
Personliga/ad hoc-skript Snabbskript för personligt bruk PowerShell-skript, curl-kommandon Personliga åtkomsttoken Kom igång med REST-API:erna
Azure-pipelines Åtkomst till Azure DevOps från pipeline Konsumera artefakter från olika organisationer Azure DevOps tjänstanslutning Lägg till en Azure DevOps Microsoft Entra tjänstanslutning

Förslag för att komma igång

Följande avsnitt innehåller rekommendationer för att komma igång i olika scenarier.

Nya program

Befintliga applikationer

  • Planera migrering från personliga åtkomsttoken till Microsoft Entra ID autentisering.
  • Överväg tidslinje för autentiseringsmigrering för förbättringar av Azure DevOps och minska användningen av personliga åtkomsttokens.
  • Granska din aktuella autentiseringsmetod mot bästa praxis för säkerhet.

Azure DevOps Server

  • Använd .NET klientbibliotek med Windows autentisering när det är möjligt.
  • Använd personliga åtkomsttoken för Azure DevOps Server scenarier när de är acceptabla.
  • Planera för framtida migrering av Azure DevOps Services för att dra nytta av modern autentisering.

Vanliga frågor (FAQ)

Ska jag använda Microsoft Entra ID OAuth eller personliga åtkomsttoken?

Använd Microsoft Entra ID OAuth i följande scenarier:

  • Nya program och integreringar.
  • Produktionsarbetsbelastningar som kräver robust säkerhet.
  • Program som behöver integrering av företagsidentitet.
  • Långsiktiga projekt med efterlevnadskrav.

Använd endast personliga åtkomsttoken i följande scenarier:

  • Personliga skript och ad hoc-uppgifter.
  • Legacy-applikationer under planering av migrering.
  • Azure DevOps Server scenarier där modern autentisering inte är tillgänglig.

Ska jag använda tjänstens huvudnamn eller användardelegering för autentisering?

Använd tjänstens huvudnamn eller hanterade identiteter i följande scenarier:

  • Skapa program som fungerar oberoende (bakgrundstjänster, automatisering).
  • Skapa appar som inte kräver användarinteraktion.
  • Implementera tjänst-till-tjänst-kommunikation.
  • Skapa pipelines för kontinuerlig integrering och kontinuerlig leverans (CI/CD) eller automatiserade arbetsflöden.

Använd användardelegering (OAuth med användarmedgivande) i följande scenarier:

  • Skapa program som fungerar för mänskliga användare.
  • Skapa interaktiva appar där användare loggar in med sina egna autentiseringsuppgifter.
  • Implementera funktioner som kräver användarspecifika behörigheter.
  • Skapa appar som respekterar användarnas individuella åtkomsträttigheter.

Hur autentiserar jag med både Azure DevOps Services och Azure DevOps Server?

Skapa separata autentiseringssökvägar för varje tjänst:

  • Azure DevOps Services: Använd Microsoft Entra ID OAuth.
  • Azure DevOps Server: Använd .NET klientbibliotek med Windows-autentisering eller personliga åtkomsttoken.

requestContext Använd metoden för att identifiera tjänsttypen och tillämpa lämplig autentiseringsmetod.

Varför kan inte mitt tjänstkonto komma åt Azure DevOps API:er?

Här följer några vanliga problem som påverkar åtkomsten till tjänstkontot:

  • Tjänstkontot är inte "materialiserat": Använd rätt inloggningsmetod. Tjänstkonton behöver interaktiva inloggningsbehörigheter eller korrekt Microsoft Entra ID registrering.
  • Otillräckliga behörigheter: Kontrollera att tjänstkontot har lämpliga Azure DevOps-behörigheter.
  • Autentiseringsmetod: Använd tjänstens huvudnamn eller hanterade identiteter i stället för att försöka autentisera som ett tjänstkonto.

Hur migrerar jag från personliga åtkomsttoken till modern autentisering?

Följ de här stegen:

  1. Identifiera aktuell användning av personlig åtkomsttoken i dina program.

  2. Välj en alternativ autentiseringsmetod:

    • Microsoft Entra ID OAuth för användardelegaterade scenarier
    • Tjänsthuvudnamn för tjänst-till-tjänst-scenarier
    • Azure DevOps tjänstanslutning

  3. Uppdatera autentiseringskoden med hjälp av Azure DevOps migreringsautentiseringsexempel.

  4. Testa ändringarna noggrant innan du tar bort personliga åtkomsttokenberoenden.

  5. Övervaka och verifiera den nya autentiseringsmetoden.

Varför ska jag inte avkoda eller läsa anspråk från autentiseringstoken?

Autentiseringstoken finns enbart för att bevisa vem anroparen är och vad de har behörighet att göra. De är inte ett stabilt datagränssnitt eller ett schema som du kan vara beroende av.

Tokenanspråk dokumenteras aldrig offentligt och Azure DevOps förbehåller sig rätten att ändra, byta namn på, ta bort eller kryptera dem när som helst utan föregående meddelande. Från och med sommaren 2025 krypterar Azure DevOps ytterligare autentiseringstoken, vilket innebär att klienter inte kan läsa tokennyttolaster. Alla program som avkodar tokens för att extrahera anspråk slutar fungera.

I stället för att läsa tokenanspråk följer du dessa metoder:

  • Behandla token som ogenomskinliga – skicka dem i auktoriseringshuvuden, men avkoda eller inspektera dem inte.
  • Använd rest-API:er som stöds – hämta användar- eller organisationsdata från Azure DevOps REST API:er, som tillhandahåller stabila kontrakt och dokumentation.
  • Anta att alla anspråk kan ändras – om du parsar tokeninnehåll för att läsa värden placerar du den logiken i ett API-anrop i stället.

Dessa ändringar påverkar inte program som redan behandlar token som ogenomskinliga.

Implementeringsprocedurer

När du har valt autentiseringsmetod för ditt scenario slutför du implementeringsstegen:

Använda AI för att välja en autentiseringsmetod

Om du ansluter Azure DevOps MCP Server till DIN AI-agent i agentläge kan du använda frågor på naturligt språk för att få autentiseringsrekommendationer för ditt scenario.

Task Exempelprompt
Välj autentisering för en bakgrundstjänst Which authentication method should I use for a background Azure Function that needs to access Azure DevOps APIs?
Jämför autentiseringsalternativ Help me choose between service principals, managed identities, and personal access tokens for my Azure DevOps integration
Autentisering för en webbapp I'm building a React web app that needs to access Azure DevOps on behalf of signed-in users — what authentication approach should I use?
Migrera från PAT Help me plan a migration from personal access tokens to Microsoft Entra ID authentication for my Azure DevOps integrations
Autentisering för CI/CD What's the most secure way to authenticate Azure DevOps REST API calls from a GitHub Actions workflow?
Felsöka autentiseringsfel I'm getting 401 errors when calling the Azure DevOps REST API with my token — help me diagnose the issue

Anmärkning

Agentläget och MCP-servern använder naturligt språk, så du kan justera dessa frågor eller ställa uppföljningsfrågor för att förfina resultatet.

Relaterat innehåll

  • Last updated on