Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Dieser Artikel konzentriert sich auf Integrationsauthentifizierungsmuster für Apps, Skripts und Pipelines, die Azure DevOps aufrufen. Verwenden Sie moderne Microsoft Entra ID-basierte Authentifizierung für neue Integrationen, da sie eine stärkere Sicherheit und eine bessere langfristige Kompatibilität bietet.
Wenn Sie eine Übersicht auf Organisationsebene benötigen, die Benutzeranmeldungen, Governance-Steuerelemente und Sicherheitsstatus auf Plattformebene abdeckt, lesen Sie den Authentifizierungsleitfaden für Azure DevOps.
Verwenden Sie Microsoft Entra ID Authentifizierung für neue Anwendungen, die in Azure DevOps Services integriert sind. Verwenden Sie persönliche Zugriffstoken sparsam und nur, wenn Microsoft Entra ID nicht verfügbar ist.
Von Bedeutung
Erwägen Sie die Verwendung der sichereren Microsoft Entra Token gegenüber höherer Gefahr personalen Zugriffstoken. Weitere Informationen finden Sie unter Reduzieren der PAT-Verwendung. Überprüfen Sie die Authentifizierungsanleitungen , um den richtigen Authentifizierungsmechanismus für Ihre Anforderungen auszuwählen.
OAuth 2.0 und Microsoft Entra ID Authentifizierung sind nur für Azure DevOps Dienste verfügbar, nicht für Azure DevOps Server.
Verwenden Sie für lokale Szenarien .NET Clientbibliotheken, Windows-Authentifizierung oder personale Zugriffstoken.
Tipp
Sie können KI verwenden, um diese Aufgabe zu unterstützen weiter unten in diesem Artikel, oder lesen Sie Enable AI-Unterstützung bei Azure DevOps MCP Server, um zu beginnen.
Vergleich allgemeiner Authentifizierungsoptionen
Verwenden Sie die folgende Tabelle, um die am häufigsten verwendeten Authentifizierungsoptionen für Apps, Skripts und Pipelines zu vergleichen.
| Method | Am besten geeignet für: | Sicherheitsstatus | Verwaltung von Anmeldeinformationen | Funktioniert mit | Vermeiden, wenn |
|---|---|---|---|---|---|
| Verwaltete Identität | Azure gehostete Automatisierung, z. B. Azure Functions, App Service oder virtuelle Computer | Stärkste Option für Azure gehostete Workloads, da Token kurzlebig sind und Azure den Identitätslebenszyklus verwalten | Kein geheimer Clientschlüssel zum Speichern oder Drehen; Azure verwaltet die Identitäts- und Tokenakquisition | Azure DevOps Dienste; Azure gehosteten Workloads im selben Microsoft Entra Mandanten, nachdem Sie die Identität zu Azure DevOps hinzugefügt haben | Die Workload wird nicht auf Azure ausgeführt, oder Sie benötigen eine tragbare Identität, die nicht an eine Azure Ressource gebunden ist. |
| Service Principal | Automatisierung, die außerhalb Azure, über mehrere Umgebungen oder in externen CI/CD-Systemen ausgeführt wird | Starke Option, wenn Sie zertifikatbasierte Authentifizierungs- oder Verbundansätze verwenden und die geringsten Berechtigungen anwenden | Sie verwalten die Anwendungsidentität und alle geheimen Clientschlüssel oder Zertifikate, es sei denn, ein Verbundfluss entfernt den geheimen Schlüssel. | Azure DevOps Dienste; Apps, Skripts und Dienste, die eine Microsoft Entra Anwendungsidentität benötigen | Sie können stattdessen eine verwaltete Identität für denselben Azure gehosteten Workload verwenden, oder das Tool unterstützt nur PAT-basierte Authentifizierung. |
| Azure DevOps Dienstverbindung | Azure Pipelines Zugriff auf Azure DevOps Ressourcen | Starke Option für die Pipelineautomatisierung, da sie Microsoft Entra Workload-Identitätsverbund anstelle von langlebigen Token verwendet | Azure DevOps verwaltet die Dienstverbindung, und Pipelines müssen KEINE PATs in Variablen speichern. | Azure DevOps Dienste; Pipelines, die auf Repositorys, Feeds oder REST-APIs in allen Organisationen zugreifen | Das Szenario wird nicht durch Azure Pipelines |
| Persönliches Zugriffstoken (Personal Access Token, PAT) | Kurzlebige persönliche Skripts, einmalige Tests oder Legacyszenarien, die noch nicht Microsoft Entra-basierte Authentifizierung verwenden können | Höchstes Risiko für die allgemeinen Auswahlmöglichkeiten, da das Token ein langlebiges Bearergeheimnis ist, das an ein Benutzerkonto gebunden ist | Sie müssen das Token manuell erstellen, speichern, drehen und widerrufen. | Azure DevOps Dienste und Azure DevOps Server; CLI-, REST-Aufrufe und Legacyintegrationen, die PATs unterstützen | Die Integration ist ein Produktionsdienst, eine gemeinsame Automatisierung oder ein beliebiges Szenario, in dem ein Dienstprinzipal, eine verwaltete Identität oder eine Dienstverbindung verfügbar ist. |
Schnelle Empfehlungen
- Wählen Sie zuerst verwaltete Identität aus, wenn die Workload auf Azure ausgeführt wird und Azure den Identitätslebenszyklus besitzen können.
- Wählen Sie einen Dienstprinzipal aus, wenn Sie eine Anwendungsidentität benötigen, die Workload jedoch nicht auf Azure ausgeführt wird oder sich über Umgebungen hinweg bewegen muss.
- Wählen Sie eine Azure DevOps Dienstverbindung aus, wenn Azure Pipelines ohne PAT auf Azure DevOps Ressourcen zugreifen muss.
- Wählen Sie einen PAT nur für persönliche, temporäre, ältere oder Azure DevOps Server Szenarien aus, in denen die sichereren Optionen nicht gelten.
Authentifizierungsmethoden nach Szenario
Wählen Sie die entsprechende Authentifizierungsmethode basierend auf Dem Anwendungstyp und den Anforderungen aus.
| Anwendungstyp | BESCHREIBUNG | Beispiel | Empfohlene Methode | Codebeispiele |
|---|---|---|---|---|
| Web- und Desktop-Apps | Interaktive Anwendungen mit aktuellen Frameworks | React-App, .NET Desktop-App | Microsoft Entra OAuth mit dem Microsoft Authentication Library (MSAL) (MSAL) | Verwaltete Clientkonsolen-App |
| Dienst-/Hintergrund-Apps | Anwendungen, die ohne Benutzerinteraktion ausgeführt werden | Azure Functions, Hintergrunddienste | Dienstprinzipale und verwaltete Identitäten | Dienstprinzipale |
| Ältere Client-Apps | Vorhandene Anwendungen mit Clientbibliotheken | Konsolen-Apps mit Azure DevOps .NET-Bibliotheken | .NET Clientbibliotheken mit OAuth | Client-Bibliothekskonsolen-App |
| Headless/CLI-Apps | Nichtinteraktive Befehlszeilentools | Erstellen von Skripts, Automatisierungstools | Geräteautorisierungs-Gewährungs-Flow | Geräteprofil |
| Azure DevOps Erweiterungen | In Azure DevOps ausgeführte Erweiterungen | Benutzerdefinierte Dashboard-Widgets und Arbeitsaufgabenformulare | Azure DevOps Weberweiterungs-SDK | Hinzufügen eines Dashboard-Widgets |
| Azure DevOps Server-Anwendungen | Lokale Azure DevOps Server-Integrationen | Benutzerdefinierte Servererweiterungen | .NET Clientbibliotheken oder Windows Auth | Client-Bibliothekskonsolen-App |
| Persönliche/Ad-hoc-Skripts | Schnelle Skripts für die persönliche Nutzung | PowerShell-Skripts, Curl-Befehle | Persönliche Zugriffstoken | Erste Schritte mit den REST-APIs |
| Azure Pipelines | Zugriff auf Azure DevOps von der Pipeline | Verwenden von Artefakten aus verschiedenen Organisationen | Azure DevOps-Dienstverbindung | Fügen Sie eine Azure DevOps Microsoft Entra-Dienstverbindung hinzu |
Vorschläge für erste Schritte
Die folgenden Abschnitte enthalten Empfehlungen für die ersten Schritte in verschiedenen Szenarien.
Neue Anwendungen
- Erstellen Sie die Azure DevOps-Integrationen mit Microsoft Entra OAuth-Apps für die höchste Sicherheit und zukünftige Kompatibilität.
- Verwenden Sie Dienstprinzipale oder verwaltete Identitäten für Dienst-zu-Dienst-Szenarien.
- Vermeiden Sie persönliche Zugriffstoken in Produktionsanwendungen.
Bestehende Anwendungen
- Planen Sie die Migration von persönlichen Zugriffstoken zur Microsoft Entra ID Authentifizierung.
- Berücksichtigen Sie den Zeitplan für die Authentifizierungsmigration zur Verbesserung von Azure DevOps und um die Verwendung persönlicher Zugriffstoken zu reduzieren.
- Überprüfen Sie Ihren aktuellen Authentifizierungsansatz anhand bewährter Sicherheitsmethoden.
Azure DevOps Server
- Verwenden Sie .NET Clientbibliotheken nach Möglichkeit mit Windows Authentifizierung.
- Verwenden Sie persönliche Zugriffstoken für Azure DevOps Server Szenarien, wenn sie akzeptabel sind.
- Planen Sie zukünftige Azure DevOps Services-Migration, um die moderne Authentifizierung zu nutzen.
Häufig gestellte Fragen (FAQ)
Sollte ich Microsoft Entra ID OAuth oder persönliche Zugriffstoken verwenden?
Verwenden Sie Microsoft Entra ID OAuth in den folgenden Szenarien:
- Neue Anwendungen und Integrationen.
- Produktionsworkloads, die eine robuste Sicherheit erfordern.
- Anwendungen, die Unternehmensidentitätsintegration benötigen.
- Langfristige Projekte mit Complianceanforderungen.
Verwenden Sie persönliche Zugriffstoken nur in den folgenden Szenarien:
- Persönliche Skripts und Ad-hoc-Aufgaben.
- Legacy-Anwendungen während der Migrationsplanung.
- Azure DevOps Server Szenarien, in denen die moderne Authentifizierung nicht verfügbar ist.
Sollte ich Service Principals oder Benutzerdelegation für die Authentifizierung verwenden?
Verwenden Sie Dienstprinzipale oder verwaltete Identitäten in den folgenden Szenarien:
- Erstellen Sie Anwendungen, die unabhängig ausgeführt werden (Hintergrunddienste, Automatisierung).
- Erstellen Sie Apps, die keine Benutzerinteraktion erfordern.
- Implementieren der Dienst-zu-Dienst-Kommunikation.
- Erstellen Sie kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD)-Pipelines oder automatisierte Workflows.
Verwenden Sie die Benutzerdelegierung (OAuth mit Zustimmung des Benutzers) in den folgenden Szenarien:
- Erstellen Sie Anwendungen, die für menschliche Benutzer fungieren.
- Erstellen Sie interaktive Apps, in denen sich Benutzer mit ihren eigenen Anmeldeinformationen anmelden.
- Implementieren Sie Features, die benutzerspezifische Berechtigungen erfordern.
- Erstellen Sie Apps, die die individuellen Zugriffsrechte der Benutzer respektieren.
Wie kann ich mich bei Azure DevOps Services und Azure DevOps Server authentifizieren?
Erstellen Sie separate Authentifizierungspfade für jeden Dienst:
- Azure DevOps Services: Verwenden Sie Microsoft Entra ID OAuth.
- Azure DevOps Server: Verwenden Sie .NET Clientbibliotheken mit Windows Authentifizierungs- oder persönlichen Zugriffstoken.
Verwenden Sie die requestContext Methode, um den Diensttyp zu erkennen und die entsprechende Authentifizierungsmethode anzuwenden.
Warum kann mein Dienstkonto nicht auf Azure DevOps APIs zugreifen?
Nachfolgend finden Sie einige häufige Probleme, die sich auf den Zugriff auf das Dienstkonto auswirken:
- Dienstkonto nicht "materialisiert": Verwenden Sie die richtige Anmeldemethode. Dienstkonten benötigen interaktive Anmeldeberechtigungen oder ordnungsgemäße Microsoft Entra ID Registrierung.
- Unzureichende Berechtigungen: Stellen Sie sicher, dass das Dienstkonto über die entsprechenden Azure DevOps Berechtigungen verfügt.
- Authentifizierungsmethode: Verwenden Sie Dienstprinzipale oder verwaltete Identitäten, anstatt zu versuchen, sich als Dienstkonto zu authentifizieren.
Wie kann ich von persönlichen Zugriffstoken zur modernen Authentifizierung migrieren?
Folgen Sie diesen Schritten:
Identifizieren Sie die aktuelle Verwendung des persönlichen Zugriffstokens in Ihren Anwendungen.
Wählen Sie eine alternative Authentifizierungsmethode aus:
- Microsoft Entra ID OAuth für benutzerdelegierte Szenarien
- Dienstprinzipale für Dienst-zu-Dienst-Szenarien
- Azure DevOps Dienstverbindung
Aktualisieren Sie den Authentifizierungscode mithilfe der Azure DevOps Migrationsauthentifizierungsbeispiele.
Testen Sie die Änderungen gründlich, bevor Sie persönliche Zugriffstokenabhängigkeiten entfernen.
Überwachen und Überprüfen der neuen Authentifizierungsmethode.
Warum sollte ich Ansprüche von Authentifizierungstoken nicht decodieren oder lesen?
Authentifizierungstoken sind ausschließlich vorhanden, um zu beweisen, wer der Aufrufer ist und was er ausführen darf. Sie sind keine stabile Datenschnittstelle oder ein Schema, von dem Sie abhängig sein können.
Tokenansprüche werden niemals öffentlich dokumentiert, und Azure DevOps behält sich das Recht vor, sie jederzeit ohne Vorheriges zu ändern, umzubenennen, zu entfernen oder zu verschlüsseln. Ab Sommer 2025 verschlüsselt Azure DevOps Authentifizierungstoken weiter, was bedeutet, dass Clients keine Tokennutzlasten lesen können. Jede Anwendung, die Token decodiert, um Ansprüche zu extrahieren, scheitert.
Anstatt Tokenansprüche zu lesen, befolgen Sie die folgenden Praktiken:
- Behandeln Sie Token als undurchsichtig – übergeben Sie sie in Autorisierungsheadern, decodieren oder prüfen Sie sie jedoch nicht.
- Verwenden Sie unterstützte REST-APIs – Abrufen von Benutzer- oder Organisationsdaten aus den Azure DevOps REST-APIs, die stabile Verträge und Dokumentation bieten.
- Gehen Sie davon aus, dass sich jeder Anspruch ändern kann – wenn Sie tokeninhalte zum Lesen von Werten analysieren, fügen Sie diese Logik stattdessen in einen API-Aufruf ein.
Diese Änderungen wirken sich nicht auf Anwendungen aus, die Token bereits als undurchsichtig behandeln.
Implementierungsverfahren
Nachdem Sie die Authentifizierungsmethode für Ihr Szenario ausgewählt haben, führen Sie die Implementierungsschritte aus:
- Neue Anwendungen: Erstellen Sie Azure DevOps-Integrationen mit Microsoft Entra OAuth-Apps
- Service-Anwendungen: Dienstprinzipale und verwaltete Identitäten in Azure DevOps
- Persönliche Skripts: Verwenden von persönlichen Zugriffstoken
- Azure Pipelines: Zugriff auf Azure DevOps mit der Entra-Workload-Identität
Verwenden von KI zum Auswählen einer Authentifizierungsmethode
Wenn Sie den Azure DevOps MCP Server mit Ihrem KI-Agent im Agentmodus verbinden, können Sie Anweisungen in natürlicher Sprache verwenden, um Authentifizierungsempfehlungen für Ihr Szenario zu erhalten.
| Aufgabe | Beispielaufforderung |
|---|---|
| Wählen Sie die Authentifizierung für einen Hintergrunddienst | Which authentication method should I use for a background Azure Function that needs to access Azure DevOps APIs? |
| Vergleichen von Authentifizierungsoptionen | Help me choose between service principals, managed identities, and personal access tokens for my Azure DevOps integration |
| Authentifizierung für eine Web-App | 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? |
| Migrieren von PATs | Help me plan a migration from personal access tokens to Microsoft Entra ID authentication for my Azure DevOps integrations |
| Authentifizierung für CI/CD | What's the most secure way to authenticate Azure DevOps REST API calls from a GitHub Actions workflow? |
| Fehlerbehebung bei Authentifizierungsfehlern | I'm getting 401 errors when calling the Azure DevOps REST API with my token — help me diagnose the issue |
Hinweis
Der Agentmodus und der MCP-Server verwenden natürliche Sprache, sodass Sie diese Eingabeaufforderungen anpassen oder Nachverfolgungsfragen stellen können, um die Ergebnisse zu verfeinern.