Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
W tym artykule opisano metody uwierzytelniania na potrzeby integracji usługi Azure DevOps i pomaga wybrać najlepszą opcję dla danego scenariusza. Nowoczesne metody uwierzytelniania, takie jak Microsoft Entra ID, zapewniają zwiększone zabezpieczenia i najlepsze podejście do nowych aplikacji.
Ważne
Zalecamy uwierzytelnianie za pomocą identyfikatora Entra firmy Microsoft dla nowych aplikacji, które integrują się z usługami Azure DevOps Services. Używaj osobistych tokenów dostępu oszczędnie i używaj ich tylko wtedy, gdy identyfikator Entra firmy Microsoft jest niedostępny.
Uwierzytelnianie OAuth 2.0 i Microsoft Entra ID są dostępne tylko dla usług Azure DevOps Services, a nie dla usługi Azure DevOps Server.
W przypadku scenariuszy lokalnych użyj bibliotek klienckich platformy .NET, uwierzytelniania systemu Windows lub osobistych tokenów dostępu.
Metody uwierzytelniania według scenariusza
Wybierz odpowiednią metodę uwierzytelniania na podstawie typu aplikacji i wymagań.
| Typ aplikacji | opis | Przykład | Zalecana metoda | Przykłady kodu |
|---|---|---|---|---|
| Aplikacje internetowe/klasyczne | Aplikacje interakcyjne korzystające z bieżących struktur | Aplikacja React, aplikacja klasyczna platformy .NET | Microsoft Entra OAuth z biblioteką Microsoft Authentication Library (MSAL) | Zarządzana aplikacja konsolowa klienta |
| Aplikacje usługi/w tle | Aplikacje uruchomione bez interakcji użytkownika | Azure Functions, usługi w tle | Jednostki usługi i tożsamości zarządzane | Podstawowe składniki usługi |
| Starsze aplikacje klienckie | Istniejące aplikacje korzystające z bibliotek klienckich | Aplikacje konsolowe z bibliotekami .NET dla Azure DevOps | Biblioteki klienta platformy .NET z uwierzytelnianiem OAuth | Aplikacja konsolowa biblioteki klienta |
| Aplikacje bezgłowe/interfejsu wiersza polecenia | Narzędzia wiersza polecenia nieinteraktywne | Tworzenie skryptów, narzędzi automatyzacji | Przepływ udzielania autoryzacji urządzenia | Profil urządzenia |
| Rozszerzenia usługi Azure DevOps | Rozszerzenia uruchomione w usłudze Azure DevOps | Niestandardowe widżety pulpitu nawigacyjnego i formularze elementów roboczych | SDK do rozszerzeń internetowych Azure DevOps | Dodawanie widżetu pulpitu nawigacyjnego |
| Aplikacje usługi Azure DevOps Server | Lokalne integracje usługi Azure DevOps Server | Niestandardowe rozszerzenia serwera | Biblioteki klienta platformy .NET lub uwierzytelnianie systemu Windows | Aplikacja konsolowa biblioteki klienta |
| Skrypty osobiste/ad hoc | Szybkie skrypty do użytku osobistego | Skrypty programu PowerShell, polecenia curl | Osobiste tokeny dostępu | Rozpocznij korzystanie z interfejsów API REST |
Sugestie dotyczące rozpoczynania pracy
W poniższych sekcjach przedstawiono zalecenia dotyczące rozpoczynania pracy w różnych scenariuszach.
Nowe aplikacje
- Tworzenie integracji usługi Azure DevOps z aplikacjami Microsoft Entra OAuth w celu uzyskania najlepszych zabezpieczeń i przyszłej zgodności.
- Użyj jednostek usługi lub tożsamości zarządzanych dla scenariuszy między usługami.
- Unikaj osobistych tokenów dostępu w aplikacjach produkcyjnych.
Istniejące aplikacje
- Zaprojektuj migrację z osobistych tokenów dostępu do uwierzytelniania Microsoft Entra ID.
- Zastanów się nad harmonogramem migracji uwierzytelniania w celu wprowadzenia ulepszeń w Azure DevOps i zmniejszenia użycia osobistych tokenów dostępu.
- Zapoznaj się z bieżącym podejściem do uwierzytelniania pod kątem najlepszych rozwiązań w zakresie zabezpieczeń.
Azure DevOps Server
- Jeśli to możliwe, użyj bibliotek klienckich platformy .NET z uwierzytelnianiem systemu Windows.
- Używaj osobistych tokenów dostępu w scenariuszach usługi Azure DevOps Server, gdy są one akceptowalne.
- Zaplanuj przyszłą migrację usługi Azure DevOps Services, aby skorzystać z nowoczesnego uwierzytelniania.
Odpowiedzi na często zadawane pytania
Poniższe sekcje zawierają odpowiedzi na często zadawane pytania.
Czy należy używać Microsoft Entra ID OAuth czy osobistych tokenów dostępu?
Użyj protokołu OAuth identyfikatora Entra firmy Microsoft w następujących scenariuszach:
- Nowe aplikacje i integracje
- Obciążenia produkcyjne wymagające niezawodnych zabezpieczeń
- Aplikacje wymagające integracji tożsamości przedsiębiorstwa
- Długoterminowe projekty z wymaganiami dotyczącymi zgodności
Używaj tylko osobistych tokenów dostępu w następujących scenariuszach:
- Osobiste skrypty i zadania ad hoc
- Starsze aplikacje podczas planowania migracji
- Scenariusze usługi Azure DevOps Server, w których nowoczesne uwierzytelnianie nie jest dostępne
Czy do uwierzytelniania należy używać zasad usługi lub delegowania użytkowników?
W następujących scenariuszach użyj jednostek usługi lub tożsamości zarządzanych:
- Twórz aplikacje, które działają niezależnie (usługi w tle, automatyzacja).
- Tworzenie aplikacji, które nie wymagają interakcji z użytkownikiem.
- Implementowanie komunikacji między usługami.
- Twórz potoki ciągłej integracji i ciągłego dostarczania (CI/CD) lub zautomatyzowane przepływy pracy.
W następujących scenariuszach użyj delegowania użytkownika (OAuth z zgodą użytkownika):
- Tworzenie aplikacji, które działają dla użytkowników ludzkich.
- Tworzenie aplikacji interaktywnych, w których użytkownicy logują się przy użyciu własnych poświadczeń.
- Implementowanie funkcji wymagających uprawnień specyficznych dla użytkownika.
- Twórz aplikacje, które przestrzegają indywidualnych praw dostępu użytkowników.
Jak mogę uwierzytelnić się zarówno za pomocą usług Azure DevOps Services, jak i usługi Azure DevOps Server?
Najlepszym rozwiązaniem jest utworzenie oddzielnych ścieżek uwierzytelniania:
- Azure DevOps Services: użyj protokołu OAuth Microsoft Entra ID.
- Azure DevOps Server: użyj bibliotek klienckich platformy .NET z uwierzytelnianiem systemu Windows lub osobistymi tokenami dostępu.
requestContext Użyj metody , aby wykryć typ usługi i zastosować odpowiednią metodę uwierzytelniania.
Dlaczego moje konto usługi nie może uzyskać dostępu do interfejsów API usługi Azure DevOps?
Poniżej przedstawiono niektóre typowe problemy, które mogą mieć wpływ na dostęp do konta usługi:
- Konto usługi nie jest "zmaterializowane": użyj poprawnej metody logowania. Konta usług wymagają uprawnień logowania interakcyjnego lub właściwej rejestracji identyfikatora Entra firmy Microsoft.
- Niewystarczające uprawnienia: upewnij się, że konto usługi ma odpowiednie uprawnienia usługi Azure DevOps.
- Metoda uwierzytelniania: Zamiast próbować uwierzytelniać się jako konto usługi, używaj podmiotów usługi lub tożsamości zarządzanych.
Jak przeprowadzić migrację z osobistych tokenów dostępu do nowoczesnego uwierzytelniania?
Wykonaj te kroki:
Zidentyfikuj bieżące użycie osobistego tokenu dostępu w aplikacjach.
Wybierz alternatywną metodę uwierzytelniania:
- Microsoft Entra ID OAuth dla scenariuszy delegowania przez użytkownika
- Jednostki usługi dla scenariuszy typu service-to-service
Zaktualizuj kod uwierzytelniania przy użyciu przykładów uwierzytelniania migracji usługi Azure DevOps.
Dokładnie przetestuj zmiany przed usunięciem wszelkich zależności osobistego tokenu dostępu.
Monitoruj i zweryfikuj nową metodę uwierzytelniania.
Procedury implementacji
Po wybraniu metody uwierzytelniania dla danego scenariusza zakończ implementację:
- Nowe aplikacje: tworzenie integracji usługi Azure DevOps z aplikacjami Microsoft Entra OAuth
- Aplikacje serwisowe: Używanie podmiotów usługi i zarządzanych tożsamości w usłudze Azure DevOps
- Skrypty osobiste: używanie osobistych tokenów dostępu