Metody ověřování pro integrace Azure DevOps

služby Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Tento článek se zaměřuje na vzory ověřování integrace pro aplikace, skripty a kanály, které volají Azure DevOps. Pro nové integrace používejte moderní ověřování založené na Microsoft Entra ID, protože poskytuje silnější zabezpečení a lepší dlouhodobou kompatibilitu.

Pokud potřebujete přehled na úrovni organizace, který se zabývá přihlašováním uživatelů, ovládacími prvky správného řízení a stavem zabezpečení na úrovni platformy, přečtěte si pokyny k ověřování pro Azure DevOps.

Pro nové aplikace, které se integrují se službami Azure DevOps Services, použijte ověřování Microsoft Entra ID. Používejte osobní přístupové tokeny střídmě a pouze v případě, že Microsoft Entra ID není k dispozici.

Důležité

Zvažte použití bezpečnějších tokenů Microsoft Entra než více rizikových osobních přístupových tokenů. Další informace najdete v tématu Snížení využití PAT. Projděte si doprovodné materiály k ověřování a zvolte správný mechanismus ověřování pro vaše potřeby.

Ověřování OAuth 2.0 a Microsoft Entra ID je k dispozici jenom pro služby Azure DevOps, nikoli pro Azure DevOps Server.

V případě místních scénářů použijte klientské knihovny .NET, Windows authentication nebo personal access tokeny.

Návod

S touto úlohou můžete použít AI k pomoci později v tomto článku nebo se podívejte na Povolit asistenci AI s Azure DevOps MCP Serverem k zahájení.

Porovnání běžných možností ověřování

V následující tabulce můžete porovnat nejběžnější možnosti ověřování pro aplikace, skripty a kanály.

Metoda Nejlepší pro Stav zabezpečení Správa přihlašovacích údajů Funguje s Vyhněte se v případech, kdy
Spravovaná identita Azure hostované automatizace, jako jsou Azure Functions, App Service nebo virtuální počítače Nejsilnější možnost pro úlohy hostované Azure, protože tokeny jsou krátkodobé a Azure spravuje životní cyklus identity. Žádný tajný klíč klienta k uložení nebo obměně; Azure spravuje získání identity a tokenu. služby Azure DevOps; Azure úlohy hostované ve stejném tenantovi Microsoft Entra po přidání identity do Azure DevOps Úloha se nespustí na Azure nebo potřebujete přenosnou identitu, která není svázaná s prostředkem Azure
Hlavní služba Automatizace, která běží mimo Azure, napříč několika prostředími nebo v externích systémech CI/CD Silná možnost při použití přístupů založených na certifikátech nebo federovaných přístupů a použití nejnižších oprávnění Identitu aplikace a jakýkoli tajný klíč klienta nebo certifikát spravujete, pokud federovaný tok neodebere tajný kód. Azure DevOps Services; aplikace, skripty a služby, které potřebují Microsoft Entra identitu aplikace Spravovanou identitu můžete použít místo toho pro stejnou úlohu hostované Azure nebo nástroj podporuje pouze ověřování založené na PAT.
připojení služby Azure DevOps Azure Pipelines přístup k prostředkům Azure DevOps Silná možnost pro automatizaci kanálů, protože místo dlouhodobých tokenů používá federaci identit úloh Microsoft Entra Azure DevOps spravuje připojení služby a kanály nemusí ukládat paty do proměnných. Azure DevOps Services; kanály, které přistupují k úložišťm, kanálům nebo rozhraním REST API napříč organizacemi Scénář neproběhne přes Azure Pipelines
Osobní přístupový token (PAT) Krátkodobé osobní skripty, jednorázové testování nebo starší scénáře, které zatím nemůžou používat ověřování na základě Microsoft Entra Nejvyšší riziko běžných voleb, protože token je dlouhodobý nosný tajný kód svázaný s uživatelským účtem Token musíte vytvořit, uložit, otočit a odvolat ručně. Azure DevOps Služby a Azure DevOps Server; Rozhraní příkazového řádku, volání REST a starší integrace, které podporují paty Integrace je produkční služba, sdílená automatizace nebo jakýkoli scénář, ve kterém je k dispozici instanční objekt, spravovaná identita nebo připojení služby.

Rychlá doporučení

  • Při spuštění úlohy na Azure zvolte nejprve spravovanou identitu a Azure může vlastnit životní cyklus identity.
  • Pokud potřebujete identitu aplikace, vyberte instanční objekt, ale úloha se nespustí na Azure nebo se musí přesouvat mezi prostředími.
  • Zvolte připojení služby Azure DevOps, když Azure Pipelines potřebuje přístup k prostředkům Azure DevOps bez patu.
  • Zvolte pat pouze pro osobní, dočasné, starší nebo Azure DevOps Server scénáře, kdy se nepoužijí bezpečnější možnosti.

Metody ověřování podle scénáře

Zvolte odpovídající metodu ověřování na základě typu a požadavků vaší aplikace.

Typ aplikace Popis Příklad Doporučená metoda Ukázky kódu
Webové nebo desktopové aplikace Interaktivní aplikace využívající aktuální architektury Aplikace React, .NET desktopová aplikace Microsoft Entra OAuth s knihovnou Identity a ověřování Microsoftu (MSAL) Konzolová aplikace pro správu klienta
Služby/aplikace na pozadí Aplikace spuštěné bez zásahu uživatele Azure Functions, služby na pozadí Principály služby a spravované identity Hlavní služby
Starší klientské aplikace Existující aplikace využívající klientské knihovny Konzolové aplikace s knihovnami Azure DevOps .NET Klientské knihovny .NET s OAuth konzolová aplikace knihovny Client
Bezobsádové aplikace nebo aplikace rozhraní příkazového řádku Neinteraktivní nástroje příkazového řádku Vytváření skriptů, automatizačních nástrojů Tok udělení autorizace zařízení Profil zařízení
rozšíření Azure DevOps Rozšíření spuštěná v rámci Azure DevOps Vlastní widgety řídicího panelu a formuláře pracovních položek Azure DevOps sdk pro webové rozšíření Přidání widgetu řídicího panelu
Azure DevOps Server aplikace Místní integrace Azure DevOps Server Vlastní serverová rozšíření klientské knihovny .NET nebo ověřování Windows konzolová aplikace knihovny Client
Osobní/ad hoc skripty Rychlé skripty pro osobní použití Skripty PowerShellu, příkazy curl Osobní přístupové tokeny Začínáme s rozhraními REST API
Azure Pipelines Přístup k Azure DevOps z potrubí Využívání artefaktů z jiné organizace připojení služby Azure DevOps Přidat připojení služby Azure DevOps Microsoft Entra

Návrhy pro začátek

Následující části obsahují doporučení pro zahájení práce v různých scénářích.

Nové aplikace

  • integrace Build Azure DevOps s aplikacemi Microsoft Entra OAuth pro nejlepší zabezpečení a budoucí kompatibilitu.
  • Používejte poskytovatele služeb nebo spravované identity pro scénáře mezi službami.
  • Vyhněte se osobním přístupovým tokenům v produkčních aplikacích.

Existující aplikace

  • Naplánujte migraci z osobních přístupových tokenů na ověřování Microsoft Entra ID.
  • Zvažte časovou osu migrace ověřování pro vylepšení systémů Azure DevOps a snížení používání osobních přístupových tokenů.
  • Zkontrolujte svůj současný přístup k ověřování oproti osvědčeným postupům zabezpečení.

Azure DevOps Server

  • Pokud je to možné, používejte klientské knihovny .NET s ověřováním Windows.
  • Osobní přístupové tokeny používejte pro Azure DevOps Server scénáře, kdy jsou přijatelné.
  • Naplánujte budoucí migraci Azure DevOps Services, abyste mohli využívat moderní ověřování.

Často kladené otázky (FAQ)

Mám používat Microsoft Entra ID OAuth nebo osobní přístupové tokeny?

V následujících scénářích použijte Microsoft Entra ID OAuth:

  • Nové aplikace a integrace
  • Produkční úlohy, které vyžadují robustní zabezpečení
  • Aplikace, které potřebují integraci podnikové identity.
  • Dlouhodobé projekty s požadavky na dodržování předpisů.

Osobní přístupové tokeny používejte pouze v následujících scénářích:

  • Osobní skripty a ad hoc úkoly
  • Starší verze aplikací během plánování migrace
  • Ve scénářích Azure DevOps Server, kdy není moderní ověřování dostupné.

Mám k ověřování použít služební principály nebo delegování uživatelských práv?

Služební principály nebo spravované identity použijte v následujících scénářích:

  • Vytvářejte aplikace, které pracují nezávisle (služby na pozadí, automatizace).
  • Vytvářejte aplikace, které nevyžadují interakci uživatele.
  • Implementujte komunikaci mezi službami.
  • Vytvářejte kanály kontinuální integrace a nepřetržitého doručování (CI/CD) nebo automatizované pracovní postupy.

Delegování uživatele (OAuth se souhlasem uživatele) použijte v následujících scénářích:

  • Vytvářejte aplikace, které fungují pro lidské uživatele.
  • Vytvářejte interaktivní aplikace, ve kterých se uživatelé přihlašují pomocí vlastních přihlašovacích údajů.
  • Implementujte funkce, které vyžadují oprávnění specifická pro uživatele.
  • Vytvářejte aplikace, které respektují jednotlivá přístupová práva uživatelů.

Jak se můžu ověřit pomocí služeb Azure DevOps i Azure DevOps Server?

Vytvořte pro každou službu samostatné cesty ověřování:

  • Azure DevOps Services: Použijte Microsoft Entra ID OAuth.
  • Azure DevOps Server: Používejte klientské knihovny .NET s ověřovacími nebo osobními přístupovými tokeny Windows.

requestContext Pomocí metody detekujte typ služby a použijte příslušnou metodu ověřování.

Proč můj účet služby nemá přístup k rozhraním API Azure DevOps?

Tady je několik běžných problémů, které mají vliv na přístup k účtu služby:

  • Účet služby není materializovaný: Použijte správnou metodu přihlášení. Účty služeb potřebují interaktivní přihlašovací oprávnění nebo správnou registraci Microsoft Entra ID.
  • Insufficient permissions: Ujistěte se, že má účet služby odpovídající oprávnění Azure DevOps.
  • Metoda ověřování: Místo pokusu ověřit se jako účet služby používejte principy služby nebo spravované identity.

Jak můžu migrovat z osobních přístupových tokenů na moderní ověřování?

Postupujte následovně:

  1. Identifikujte aktuální využití osobních přístupových tokenů ve vašich aplikacích.

  2. Zvolte alternativní metodu ověřování:

    • Microsoft Entra ID OAuth pro scénáře delegované uživatelem
    • Instanční objekty pro scénáře service-to-service
    • připojení služby Azure DevOps

  3. Aktualizujte ověřovací kód pomocí příkladů autentizace migrace Azure DevOps.

  4. Před odstraněním jakýchkoli závislostí na osobních přístupových tokenech pečlivě otestujte změny.

  5. Monitorujte a ověřte novou metodu ověřování.

Proč bych neměl dekódovat nebo číst deklarace identity z ověřovacích tokenů?

Ověřovací tokeny existují výhradně k prokázání toho, kdo je volající a co má oprávnění dělat. Nejedná se o stabilní datové rozhraní nebo schéma, na kterém můžete záviset.

Deklarace identity tokenů nejsou nikdy veřejně zdokumentované a Azure DevOps si vyhrazuje právo kdykoli změnit, přejmenovat, odebrat nebo zašifrovat. Od léta 2025 Azure DevOps dále šifruje ověřovací tokeny, což znamená, že klienti nemůžou číst datové části tokenů. Jakákoliv aplikace, která dekóduje tokeny, aby extrahovala nároky, selže.

Místo čtení deklarací identity tokenů postupujte podle těchto postupů:

  • Považovat tokeny za neprůhledné – předávejte je v autorizačních hlavičkách, ale nedekódujte je ani je nezkoumejte.
  • Používejte podporovaná rozhraní REST API – načtěte data uživatelů nebo organizací z rozhraní Azure DevOps REST API, která poskytují stabilní kontrakty a dokumentaci.
  • Předpokládejme, že jakékoli tvrzení může být změněno – pokud zjistíte, že čtete hodnoty analýzou obsahu tokenu, vložte tuto logiku do volání rozhraní API.

Tyto změny nemají vliv na aplikace, které už považují tokeny za neprůhlené.

Postupy implementace

Po výběru metody ověřování pro váš scénář dokončete kroky implementace:

Použití AI k výběru metody ověřování

Pokud připojíte Azure DevOps MCP Server k agentu AI v režimu agenta, můžete k získání doporučení pro ověřování pro váš scénář použít výzvy přirozeného jazyka.

Úkol Příklad výzvy
Vyberte autentizaci pro službu na pozadí Which authentication method should I use for a background Azure Function that needs to access Azure DevOps APIs?
Porovnání možností ověřování Help me choose between service principals, managed identities, and personal access tokens for my Azure DevOps integration
Ověřování pro webovou aplikaci 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?
Migrace z PATů Help me plan a migration from personal access tokens to Microsoft Entra ID authentication for my Azure DevOps integrations
Ověřování pro CI/CD What's the most secure way to authenticate Azure DevOps REST API calls from a GitHub Actions workflow?
Řešení potíží s chybami ověřování I'm getting 401 errors when calling the Azure DevOps REST API with my token — help me diagnose the issue

Poznámka:

Režim agenta a server MCP používají přirozený jazyk, takže tyto výzvy můžete upravit nebo položit následné otázky, abyste výsledky upřesněte.

Související obsah

  • Last updated on