Volba vhodného mechanismu ověřování
Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019
U aplikací, které jsou rozhraním Azure DevOps Services, je nutné ověřit, abyste získali přístup k prostředkům, jako jsou rozhraní REST API. Tento článek obsahuje pokyny, které vám pomůžou zvolit správný mechanismus ověřování pro vaši aplikaci.
Následující tabulka popisuje navrhované koncepty ověřování, které je potřeba zvážit pro různé scénáře aplikací. Projděte si doprovodné popisy, příklady a ukázky kódu, které vám pomůžou začít.
| Typ aplikace | Popis | Příklad | Mechanismus ověřování | Ukázky kódu |
|---|---|---|---|---|
| Interaktivní aplikace na straně klienta (REST) | Klientská aplikace, která umožňuje interakci uživatelů s voláním rozhraní REST API služby Azure DevOps Services | Výčet projektů v organizaci v konzolové aplikaci | OAuth s knihovnou MSAL (Microsoft Authentication Library) | ukázka |
| Interaktivní aplikace na straně klienta (klientské knihovny) | Klientská aplikace, která umožňuje interakci uživatelů s voláním klientských knihoven Azure DevOps Services | Výčet chyb přiřazených aktuálnímu uživateli v konzolové aplikaci | OAuth s klientskými knihovnami | ukázka |
| Neinteraktivní aplikace na straně klienta | Bezobsadová textová aplikace pouze na straně klienta | Konzolová aplikace zobrazující všechny chyby přiřazené uživateli | OAuth s tokem profilu zařízení | ukázka |
| Token PAT (Personal Access Token) | Nosný token pro přístup k vlastním prostředkům | Místo hesla použijte svůj PAT pro ad hoc volání REST. Není ideální pro aplikace. | Poplácává | příklady |
| Serverová aplikace | Aplikace Azure DevOps Server s využitím klientské knihovny OM | Rozšíření Azure DevOps Serveru zobrazující řídicí panely týmových chyb | Klientské knihovny | ukázka |
| Principál služby nebo spravovaná identita | Aplikace s vlastní identitou | Funkce Azure pro vytváření pracovních položek | Instanční objekty a spravované identity | ukázka |
| Webové rozšíření | Rozšíření Azure DevOps Services | Rozšíření Agilní karty | Sada SDK webového rozšíření VSS | ukázka |
Spropitné
ověřování založené na entra je naším doporučením pro vývojáře, kteří chtějí integrovat se službou Azure DevOps Services, pokud pracujete s účty Microsoft Entra. Ukázkové aplikace OAuth v této tabulce používají pro vývoj aplikací
Pro ověřování účtů Microsoft (MSA) nebo uživatelů Azure DevOps Serveru se podívejte na naše klientské knihovny nebo na PATy .
Přečtěte si další informace v našem blogu o tom, jak snižujeme využití PAT na naší platformě.
Nejčastější dotazy
Otázka: Proč můj účet služby nemá přístup k rozhraní REST API Azure DevOps?
A: Váš účet služby nemusí mít materializovaný. Účty služeb bez interaktivních přihlašovacích oprávnění se nemůžou přihlásit. Další informace najdete v tomto alternativním řešení.
Otázka: Mám pro svou interaktivní aplikaci na straně klienta používat klientské knihovny Azure DevOps Services nebo rozhraní REST API služby Azure DevOps Services?
A: Pro přístup k prostředkům Azure DevOps Services doporučujeme používat klientské knihovny Azure DevOps Services přes rozhraní REST API. Při změně verzí koncového bodu REST jsou jednodušší a jednodušší. Pokud klientské knihovny nemají určité funkce, použijte msAL k ověřování pomocí našich rozhraní REST API.
Otázka: Jedná se o tyto pokyny pouze pro Azure DevOps Services nebo je relevantní také pro místní uživatele Azure DevOps Serveru?
A: Tyto pokyny jsou primárně určené pro uživatele Azure DevOps Services. Pro uživatele Azure DevOps Serveru doporučujeme pro ověřování použít klientské knihovny, ověřování systému Windows nebo tokeny PAT (Personal Access Tokens).
Otázka: Co když chci, aby se moje aplikace ověřila pomocí Azure DevOps Serveru i Azure DevOps Services?
A: Osvědčeným postupem je mít samostatné cesty ověřování pro Azure DevOps Server a Azure DevOps Services. Můžete použít requestContext k určení, ke které službě přistupujete, a pak použít příslušný mechanismus ověřování. Pokud dáváte přednost jednotnému řešení, paty fungují pro obojí.