Öffentliche und vertrauliche Clientanwendungen

Artikel
08/13/2024

Die Microsoft-Authentifizierungsbibliothek (Microsoft Authentication Library, MSAL) definiert zwei Arten von Clients: öffentliche und vertrauliche Clients. Ein Client ist eine Softwareentität, die über einen eindeutigen Bezeichner verfügt, der von einem Identitätsanbieter zugewiesen wird. Die Clienttypen unterscheiden sich durch ihre Fähigkeit, sich sicher beim Autorisierungsserver zu authentifizieren und vertrauliche, identitätsbezogene Informationen zu speichern, sodass der Zugriff auf einen Benutzer im Rahmen seines Zugriffs nicht möglich ist oder bekannt ist.

Öffentliche Client-Apps	Vertrauliche Client-Apps
Desktop-App	Web-App
API ohne Browser	Web-API
Mobile App	Dienst/Daemon

Autorisierung von öffentlichen und vertraulichen Clients

Bei der Prüfung der öffentlichen oder vertraulichen Art eines bestimmten Clients bewerten wir die Fähigkeit dieses Clients, seine Identität gegenüber dem Autorisierungsserver zu beweisen. Dies ist wichtig, da der Autorisierungsserver der Identität des Clients vertrauen können muss, um Zugriffstoken auszugeben.

Öffentliche Clientanwendungen werden auf Geräten ausgeführt, z. B. auf Desktops, browserlosen APIs, mobilen oder clientseitigen Browser-Apps. Sie sind in Bezug auf eine sichere Speicherung von Anwendungsgeheimnissen nicht vertrauenswürdig und können daher nur im Namen eines Benutzers auf Web-APIs zugreifen. Wenn die Quelle oder der kompilierte Bytecode einer bestimmten App irgendwohin übertragen wird, wo er/sie von nicht vertrauenswürdigen Parteien gelesen, disassembliert oder anderweitig inspiziert werden kann, handelt es sich um einen öffentlichen Client. Da sie auch nur Flows für öffentliche Clients unterstützen und keine Konfigurationszeitgeheimnisse enthalten können, können sie nicht über geheime Clientschlüssel verfügen.
Vertrauliche Clientanwendungen werden auf Servern ausgeführt, wie z. B. Web-Apps, Web-API-Apps oder Dienst-/Daemon-Apps. Sie gelten als für Benutzer oder Angreifer schwer zugänglich und können daher Konfigurationszeitgeheimnisse angemessen verwahren, um den Nachweis ihrer Identität zu bestätigen. Die Client-ID wird über den Webbrowser verfügbar gemacht, aber der geheime Schlüssel wird nur im Rückkanal übergeben und niemals direkt verfügbar gemacht.

Wann sollten Sie das Zulassen eines öffentlichen Clientflows in Ihrer App-Registrierung aktivieren?

Nachdem Sie den Typ der Clientanwendung bestimmt haben, die Sie erstellen, können Sie entscheiden, ob der öffentliche Clientflow in Ihrer App-Registrierung aktiviert werden soll. Standardmäßig sollte der öffentliche Clientflow in Ihrer App-Registrierung deaktiviert sein, es sei denn, Sie oder Ihre Entwickelnden erstellen eine öffentliche Clientanwendung und verwenden das folgende OAuth-Autorisierungsprotokoll bzw. die folgenden Features:

OAuth-Autorisierungsprotokoll/-Feature	Typ einer öffentlichen Clientanwendung	Beispiele/Hinweise
Native Authentifizierung	Microsoft Entra External ID-Anwendung, die eine vollständige Anpassung der Benutzeroberfläche erfordert, einschließlich Designelemente, Logoplatzierung und Layout, damit ein einheitliches, markenspezifisches Aussehen sichergestellt ist	Hinweis: Die native Authentifizierung ist nur für App-Registrierungen in Microsoft Entra External ID-Mandanten verfügbar. Weitere Informationen finden Sie hier
Gerätecodeflow	Anwendungen, die auf Geräten mit eingeschränkter Eingabe ausgeführt werden, z. B. Smart-TV, IoT-Gerät oder Drucker
Ressourcenbesitzende – Kennwortanmeldeinformationen-Flow	Anwendungen, die die von den Benutzenden eingegebenen Kennwörter direkt verarbeiten, anstatt die Benutzenden auf die von Entra gehostete Login-Website umzuleiten und Entra die sichere Verwaltung der Kennwörter der Benutzenden zu überlassen.	Microsoft empfiehlt, dass Sie nicht den ROPC-Flow verwenden. In den meisten Szenarien sind sicherere Alternativen, z. B. der Autorisierungscodeflow, verfügbar und empfehlenswert.
Integrierter Windows-Authentifizierungsflow	Desktop- oder mobile Anwendungen, die unter Windows oder auf einem Computer laufen, der mit einer Windows-Domäne verbunden ist (Microsoft Entra ID oder mit Microsoft Entra verbunden) und den in Windows integrierten Authentifizierungsflow anstelle des Web Account Managers verwendet	Eine Desktop- oder mobile Anwendung, die die Anmeldung automatisch durchführen soll, nachdem sich Benutzende mit Microsoft Entra-Anmeldeinformationen am Windows-PC-System angemeldet haben

Geheimnisse und ihre Bedeutung beim Nachweis der Identität

Im Folgenden finden Sie einige Beispiele dafür, wie ein Client seine Identität gegenüber dem Autorisierungsserver nachweisen kann:

Verwaltete Identitäten für Azure-Ressourcen – Für Nur-App-Authentifizierungsszenarien haben Anwendungs- und Dienstentwickler, die auf Azure entwickeln, die Möglichkeit, Verwaltung, Rotation und Schutz von Geheimnissen auf die Plattform selbst auszulagern. Bei verwalteten Identitäten werden Identitäten mit Azure-Ressourcen bereitgestellt und gelöscht, und niemand, einschließlich des globalen Administrators, kann auf die zugrunde liegenden Anmeldeinformationen zugreifen. Mithilfe von verwalteten Identitäten können Sie das Risiko des Verlusts von Geheimnissen verhindern und dem Anbieter die Gewährleistung der Sicherheit überlassen.
Client-ID und -Geheimnis – In diesem Muster wird beim Registrieren eines Clients ein Wertepaar vom Autorisierungsserver generiert. Die Client-ID ist ein öffentlicher Wert, der die Anwendung identifiziert, während das Clientgeheimnis ein vertraulicher Wert ist, der verwendet wird, um die Identität der Anwendung nachzuweisen.
Nachweis des Besitzes eines Zertifikats – Public Key Infrastructure (PKI), die Standards wie X.509umfasst, ist die grundlegende Technologie, die sichere Kommunikation über das Internet ermöglicht und das Rückgrat des Datenschutzes im Internet bildet. PKI wird verwendet, um digitale Zertifikate auszustellen, die die Identität von Beteiligten in der Onlinekommunikation überprüfen, und ist die zugrunde liegende Technologie für Protokolle wie HTTPS, das häufig zum Sichern des Webdatenverkehrs verwendet wird. Ebenso können Zertifikate verwendet werden, um die Kommunikation zwischen Diensten (Service-to-Service, S2S) in Azure zu sichern, indem die gegenseitige Authentifizierung zwischen den Diensten ermöglicht wird. Dazu gehört jeder Dienst, der einem anderen ein Zertifikat als Nachweis seiner Identität präsentiert.
Vorlage einer signierten Assertion – Signierte Assertionen, die im Workload-Identitätsverbund verwendet werden, ermöglichen den Austausch eines vertrauenswürdigen Identitätsanbietertokens eines Drittanbieters mit der Microsoft-Identitätsplattform, um Zugriffstoken zum Aufrufen von durch Microsoft Entra geschützten Ressourcen zu erhalten. Der Workload-Identitätsverbund kann verwendet werden, um verschiedene Verbundszenarien zu ermöglichen, einschließlich Azure Kubernetes Service, Amazon Web Services EKS, GitHub Actions und viele weitere.

Wann spielt der Nachweis der Clientidentität eine Rolle?

Der Nachweis der Clientidentität ist wichtig, wenn sowohl die Authentizität als auch die Autorisierung einer Clientanwendung überprüft werden müssen, bevor Zugriff auf vertrauliche Daten oder Ressourcen gewährt wird. Beispiele hierfür sind:

Steuern des API-Zugriffs – Wenn Sie über eine API verfügen, die getaktet ist (z. B. für die Abrechnung), oder vertrauliche Daten oder Ressourcen verfügbar macht, überprüfen Sie die Identität des Clients, bevor Sie Zugriff gewähren. Dies ist beispielsweise wichtig, wenn sichergestellt wird, dass nur autorisierte Anwendungen Zugriff auf die API haben und dass die gemessene API-Nutzung dem richtigen Kunden in Rechnung gestellt wird.
Schützen von Benutzern vor App-Identitätswechseln – Wenn Sie über eine vom Dienst bereitgestellte, benutzerorientierte Anwendung (z. B. eine Back-End-gesteuerte Web-App) verfügen, die auf vertrauliche Daten oder Dienste zugreift, kann die Verwendung von geheimen Clientschlüsseln, um die von dieser Anwendung verwendeten Ressourcen zu schützen, verhindern, dass böswillige Akteure sich als einen legitimen Client ausgeben, um Benutzer zu phishen und Daten zu exfiltrieren oder den Zugriff zu missbrauchen.
S2S-Kommunikation – Wenn Sie über mehrere Back-End-Dienste (z. B. Downstream-APIs) verfügen, die miteinander kommunizieren müssen, können Sie die Identität der einzelnen Dienste überprüfen, um sicherzustellen, dass sie berechtigt sind, nur auf erforderliche Ressourcen zuzugreifen, um ihre Funktion auszuführen.

Im Allgemeinen ist der Nachweis der Clientidentität wichtig, wenn ein Kunde unabhängig von oder zusätzlich zu einem Benutzer authentifiziert und autorisiert werden muss.

Vertrauliche Clients: bewährte Methoden zum Verwalten von Geheimnissen

Verwenden Sie verwaltete Identitäten, um die Bereitstellung und Sicherheit zu vereinfachen – Verwaltete Identitäten stellen eine automatisch verwaltete Identität in Microsoft Entra ID für Anwendungen bereit, die beim Herstellen einer Verbindung mit Ressourcen verwendet wird, welche die Microsoft Entra-Authentifizierung unterstützen. Anwendungen können verwaltete Identitäten verwenden, um Microsoft Entra-Token abzurufen, ohne Anmeldeinformationen verwalten zu müssen. Dies kann viele der Komplexitäten im Zusammenhang mit der Geheimnisverwaltung entfernen und gleichzeitig Ihre Sicherheit und Resilienz erhöhen. Wenn Sie verwaltete Identitäten verwenden, sind die meisten, wenn nicht alle der folgenden bewährten Methoden bereits für Sie abgedeckt.

Sichere Speicherung verwenden – Geheime Clientschlüssel an einem sicheren Speicherort speichern, z. B. einem Key Vault oder einer verschlüsselten Konfigurationsdatei. Vermeiden Sie das Speichern von geheimen Clientschlüsseln in Klartext oder als eingecheckte Dateien in Versionskontrollsystemen.

Einschränken des Zugriffs – Beschränken sie den Zugriff auf geheime Clientschlüssel nur auf autorisierte Mitarbeiter. Verwenden Sie die rollenbasierte Zugriffssteuerung, um den Zugriff auf geheime Clientschlüssel nur auf diejenigen einzuschränken, die ihn benötigen, um ihre betrieblichen Aufgaben auszuführen.

Rotieren von geheimen Clientschlüsseln – Das Rotieren geheimer Clientschlüssel nach Bedarf oder auf geplanter Basis kann das Risiko minimieren, dass ein kompromittierter geheimer Schlüssel verwendet wird, um nicht autorisierten Zugriff zu erlangen. Bei Anwendung wird die Zeitspanne, für die die Verwendung eines Geheimnisses empfohlen wird, von der Stärke des verwendeten kryptografischen Algorithmus und/oder der Einhaltung von Standards oder behördlichen Compliancepraktiken beeinflusst.

Verwenden von langen Geheiminissen und starker Verschlüsselung – In engem Zusammenhang mit dem vorigen Punkt steht die Verwendung starker Verschlüsselungsalgorithmen für Daten sowohl bei der Übertragung („on the wire“) als auch im Ruhezustand („on disk“), um sicherzustellen, dass das Brute-Forcing von Geheimnissen mit hoher Entropie unwahrscheinlich bleibt. Algorithmen wie AES-128 (oder höher) können zum Schutz ruhender Daten beitragen, während RSA-2048 (oder höher) den effizienten Schutz von Daten während der Übertragung unterstützen kann. Aufgrund der sich ständig entwickelnden Natur der Cybersicherheit empfiehlt es sich immer, Ihre Sicherheitsexperten zu konsultieren und Ihre Algorithmusauswahl regelmäßig zu überprüfen.

Vermeiden Sie das Hartcodieren von Geheimnissen – Hartcodieren Sie geheime Clientschlüssel nicht im Quellcode. Das Vermeiden geheimer Schlüssel im Quellcode kann den Wert für böswillige Akteure minimieren, die sich Zugriff auf Ihren Quellcode verschaffen. Es kann auch verhindern, dass solche Geheimnisse versehentlich an unsichere Repositorys übertragen oder für Projektmitwirkende, die eventzell Zugriff auf die Quelle, aber keinen Geheimniszugriff haben, verfügbar gemacht werden.

Überwachen von Repositorys auf offengelegte Geheimnisse – Es ist eine unglückliche Tatsache, dass unerwünschte Check-Ins beim Umgang mit Quellcode vorkommen. Git Pre-Commit-Hooks sind eine vorgeschlagene Möglichkeit, versehentliche Check-Ins zu verhindern, sie sind aber auch kein Ersatz für die Überwachung. Die automatisierte Überwachung von Repositorys kann offengelegte Geheimnisse identifizieren und mit einem Plan zur Rotation kompromittierter Anmeldeinformationen helfen, Sicherheitsvorfälle zu reduzieren.

Überwachen auf verdächtige Aktivitäten – Überwachen Sie Protokolle und Überwachungspfade auf verdächtige Aktivitäten im Zusammenhang mit geheimen Clientschlüsseln. Verwenden Sie nach Möglichkeit automatisierte Warnungen und Reaktionsprozesse, um Mitarbeiter zu benachrichtigen und Notfallpläne für ungewöhnliche Aktivitäten im Zusammenhang mit geheimen Clientschlüsseln zu definieren.

Entwerfen Sie Ihre Anwendungen unter Berücksichtigung von geheimen Clientschlüsseln – Ihr Sicherheitsmodell ist nur so stark wie das schwächste Glied in der Kette. Leiten Sie keine Sicherheitsanmeldeinformationen oder Token von vertraulichen an öffentliche Clients weiter, da dadurch geheime Clientschlüssel-Daten in einen öffentlichen Client verschoben werden können, sodass ein Identitätswechsel des vertraulichen Clients möglich ist.

Verwenden von aktuellen Bibliotheken und SDKs aus vertrauenswürdigen Quellen – Die Microsoft Identity Platform bietet verschiedene Client- und Server-SDKs und Middleware, die ihre Produktivität steigern und gleichzeitig Ihre Anwendungen sicher halten. Bibliotheken wie Microsoft.Identity.Web vereinfachen das Hinzufügen von Authentifizierung und Autorisierung zu Web-Apps und APIs auf der Microsoft Identity Platform. Die Aktualisierung von Abhängigkeiten trägt dazu bei, dass Ihre Anwendungen und Dienste von den neuesten Sicherheitsinnovationen und -updates profitieren.

Vergleichen der Clienttypen und ihrer Funktionen

Im Folgenden finden Sie einige Gemeinsamkeiten und Unterschiede bei öffentlichen und vertraulichen Client-Apps:

Beide App-Typen verwalten einen Benutzertokencache und können ein Token im Hintergrund abrufen (wenn das Token im Cache vorhanden ist). Vertrauliche Client-Apps verfügen zudem über einen App-Token-Cache für Token, die die App selbst erhalten hat.
Beide Arten von Apps verwalten Benutzerkonten und können ein Konto aus dem Benutzertokencache abrufen, ein Konto anhand seines Bezeichners abrufen oder ein Konto entfernen.
Öffentliche Client-Apps verfügen in MSAL über Möglichkeiten, ein Token abzurufen (über vier separate Authentifizierungsflows). Vertrauliche Client-Apps verfügen nur über drei Möglichkeiten, ein Token abzurufen, sowie eine Möglichkeit, die URL des Autorisierungsendpunkts des Identitätsanbieters zu berechnen. Die Client-ID wird einmal beim Erstellen der Anwendung übergeben und muss nicht erneut übergeben werden, wenn die App ein Token abruft. Weitere Informationen finden Sie unter Abrufen von Token.

Öffentliche Clients sind nützlich, um den benutzerdelegierten Zugriff auf geschützte Ressourcen zu ermöglichen, können aber ihre eigene Anwendungsidentität nicht nachweisen. Vertrauliche Clients können andererseits sowohl die Benutzer- als auch die Anwendungsauthentifizierung und -autorisierung ausführen und müssen mit Blick auf die Sicherheit erstellt werden, um sicherzustellen, dass ihre geheimen Schlüssel nicht für öffentliche Clients oder andere Dritte freigegeben werden.

In einigen Fällen, z. B. S2S-Kommunikation, hilft Infrastruktur wie verwaltete Identitäten erheblich bei der Vereinfachung der Entwicklung und Bereitstellung von Diensten und entfernt einen Großteil der Komplexität, die normalerweise mit der Geheimnisverwaltung verbunden ist. Wenn verwaltete Identitäten nicht verwendet werden können, ist es wichtig, dass Richtlinien, präventive Maßnahmen und Notfallpläne vorhanden sind, um geheime Schlüssel zu schützen und auf sicherheitsrelevante Vorfälle zu reagieren.

Siehe auch

Weitere Informationen zur Anwendungskonfiguration und Instanziierung finden Sie unter:

Freigeben über