Sicherheitsempfehlungen

Um Ihre Anwendungen mit OAuth sicher in Identitätsdomains zu integrieren, müssen Sie die vom Standard empfohlenen Sicherheitskontrollen implementieren.

Die Sicherheitskontrollen können je nach den Anforderungen an die Vertraulichkeit, Integrität und Verfügbarkeit Ihrer Anwendung als obligatorisch oder optional betrachtet werden.

Eine sichere OAuth-Integration erfordert:

Sicherheitskontrollen, die für alle OAuth-Teilnehmer implementiert sind, einschließlich Autorisierungsserver (IAM), Ressourceneigentümer (Benutzer), Client und Ressourcenserveranwendungen
Vertraulichkeit der Schlüsselinformationen: Code, access_token, refresh_token, Clientzugangsdaten und Benutzerzugangsdaten
Serverauthentifizierung zwischen OAuth-Teilnehmern eingerichtet (um Identitätswechselangriffe zu vermeiden)
Richtige Informationsvalidierung für jede Anforderung (insbesondere für JSON Web Token-(JWT-)Zugriffstoken)
Verwendung von Token mit minimalen Geltungsbereichen und Timeout (um das Risiko im Falle einer Offenlegung zu reduzieren und den Token-Widerruf zu unterstützen)
Verwendung typischer Grundsätze der Informationssicherheit, wie geringste Berechtigungen

Ressourcen

Weitere Informationen zur OAuth-Sicherheit finden Sie unter den folgenden Links:

Hinweis

Es wird empfohlen, die Sicherheit proaktiv zu überwachen, damit Sie neue Sicherheitsbedrohungen schnell identifizieren können.

Checkliste für Sicherheitsempfehlungen

Auf dieser Seite werden die relevantesten Sicherheitsempfehlungen als Checkliste aufgeführt, damit Sie die Anwendungssicherheit validieren und die Sicherheitselemente entsprechend Ihren Erwartungen bearbeiten können.

Verschlüsselung

TLS in Client- und Ressourcenserveranwendungen verwenden

Die Verwendung von TLS bei allen Anwendungen bietet Vertraulichkeit bei der Kommunikation zwischen Identitätsdomain, Ressourceneigentümern, Clientanwendungen und Ressourcenserveranwendungen. Dadurch wird das Abhören während der Übertragung des Autorisierungscodes, der Zugriffstoken, der Aktualisierungstoken, der Clientzugangsdaten und der Benutzerzugangsdaten verhindert und Wiedergabeangriffe verhindert.
Serverauthentifizierung einrichten (HTTPS mit Trusted CA-Validierung)

Mit der Serverauthentifizierung können Clients, Ressourcenserver und Ressourceneigentümer die Kommunikation zwischen sich und einer Identitätsdomain herstellen, nachdem das öffentliche Zertifikat mit der vertrauenswürdigen CA geprüft wurde.

Wenn der Server kein vertrauenswürdiges Zertifikat bereitstellt (das von einer vertrauenswürdigen CA mit einem übereinstimmenden Hostnamen bereitgestellt wird), wird die Kommunikation als Man-in-the-Middle-Angriff betrachtet.

Die Serverauthentifizierung verhindert Spoofing-, Proxying-, Man-in-the-Middle- und Phishing-Angriffe, um Autorisierungscodes, Zugriffstoken, Clientzugangsdaten und Benutzerzugangsdaten zu erfassen.
Verwendung einer vertrauenswürdigen Assertion mit Identitätsdomains in Erwägung ziehen

Clients mit kritischer Sicherheit können eine Client Assertion mit Schlüsselkryptografie (anstelle eines Client Secrets) zur Authentifizierung verwenden.
Umleitungs-URI mit HTTPS und Trusted CA-Validierung schützen

HTTPS und die Verwendung einer vertrauenswürdigen CA-Validierung verhindern die Authentifizierung von "Code"-Phishing und die Impersonierung von Benutzersessions.

Administration

Anwendungen nach dem Prinzip der geringsten Rechte konfigurieren

Anwendungen sollten in einer Identitätsdomain mit nur den Mindestrechten konfiguriert werden, die für ihren Betrieb erforderlich sind.

Die Einschränkung von Geltungsbereich, Abläufen, Berechtigungstypen und Vorgängen verbessert die Sicherheitslage und reduziert die Auswirkungen einer kompromittierten Anwendung.
Geben Sie einen Namen und eine Beschreibung für Anwendungen an

Die Anwendungsinformationen werden für Benutzer unter "Meine Apps" und auf den Einwilligungsseiten angezeigt.

Die Verwendung aussagekräftiger Anwendungsnamen und Beschreibungen kann verhindern, dass Benutzer Fehler bei der Zustimmungsautorisierung machen, und trägt auch zu einer besseren Auditberichterstattung bei.
Geben Sie eine sinnvolle Beschreibung für Geltungsbereiche an

Die Beschreibung des Geltungsbereichs wird auf der Einwilligungsseite angezeigt. Die verständliche Erläuterung des Geltungsbereichs, den der Benutzer im Begriff ist, verhindert, dass Benutzer bei der Autorisierung Fehler machen, und trägt zu besseren Auditberichten bei.
Ohne Zustimmung bereitgestellte Geltungsbereiche vermeiden

Um Transparenz zu nutzen und sich auf den Ressourceneigentümer zu verlassen, stellen Sie Geltungsbereiche ohne Genehmigung nur bereit, wenn ein Geltungsbereich obligatorisch ist, und der Benutzer darf ihn nicht ablehnen können.
Zeitüberschreitung für Zugriffstoken reduzieren und Aktualisierungstoken verwenden

Identitätsdomains unterstützen JWT, ein Zugriffstoken, das in Ressourcenservern validiert werden kann, ohne das Token in der Identitätsdomain zu prüfen. Aus diesem Grund können Zugriffstoken mit langer Dauer nicht einfach widerrufen werden.

Um einen zeitnahen Widerruf zu implementieren, können Sie das Zugriffstoken mit einer kurzen Lebensdauer konfigurieren und dann das Aktualisierungstoken zum Anfordern neuer Zugriffstoken verwenden. Um einen zeitnahen Widerruf durchzuführen, müssen Sie das Aktualisierungstoken entziehen.
Client Secrets der Anwendung rotieren

Implementieren Sie für sicherheitskritische Implementierungen eine Client Secret-Rotation. Dies reduziert das Risiko, ein kompromittiertes Client Secret zu untersuchen.

Ressourceneigentümer (Benutzer)

Informieren Sie den Ressourceneigentümer

Die Verwendung des Umfangs mit Zustimmung bietet dem Ressourceneigentümer Transparenz und verhindert, dass Anwendungen Geltungsbereiche anfordern, die nicht erforderlich sind.
Benutzerbewusstsein

Bringen Sie Benutzern bei, wie sie ihre Zugangsdaten schützen und die Legitimität von Client, Ressourcenserveranwendung und Identitätsdomain identifizieren können (insbesondere wenn Authentifizierungs- und Einwilligungsseiten angezeigt werden). Dies reduziert das Risiko von Phishing-Angriffen und die Gefährdung der Benutzerzugangsdaten.

Anwendungsentwicklung

Codes, Zugriffstoken, Aktualisierungstoken und Clientzugangsdaten schützen

Anwendungen müssen die Vertraulichkeit von Codes, Zugriffstoken, Aktualisierungstoken und Clientzugangsdaten wahren. Berücksichtigen Sie bei der Entwicklung der Anwendung die folgenden Maßnahmen (unter anderem die Anwendungssicherheitsmaßnahmen):
- Codes nicht speichern (verwenden Sie den Code nur zur Laufzeit, um das Zugriffstoken abzurufen)
- Zugriffstoken im transienten Speicher behalten und ihre Berechtigungen begrenzen
- Speichern Sie Aktualisierungstoken und Clientzugangsdaten an sicheren Orten, auf die nur von der Anwendung zugegriffen werden kann
Umleitungs-URL schützen

Die Umleitungs-URL (von der die Identitätsdomain den Autorisierungscode abruft) wird als Schlüsselkomponente für die OAuth-Sicherheit betrachtet. Seien Sie vorsichtig, wenn Sie diese URL definieren, um Bedrohungen wie Cross-Site-Anforderungsfälschung und Denial-of-Service zu vermeiden.
Token aus dem Dateisystem der nativen Apps lesen

Angreifer können versuchen, Dateisystemzugriff auf dem Gerät zu erhalten und die Aktualisierungstoken mit einer böswilligen Anwendung zu lesen. Um dieses Risiko zu reduzieren, speichern Sie Geheimnisse in einem sicheren Speicher und verwenden Sie eine Gerätesperre, um unbefugten Gerätezugriff zu verhindern.
Kontrollen für geklonte und gestohlene Geräte mit nativen Apps implementieren

Um Risiken zu reduzieren, wenn ein Gerät mit Native Apps geklont oder gestohlen wird, verwenden Sie die Gerätesperre, um unbefugten Zugriff zu verhindern und Aktualisierungstoken zu widerrufen.
Anwendungssicherheit vor Veröffentlichung validieren

Testen Sie die Sicherheit der Anwendung und ihrer Hostingumgebung, bevor Sie die Anwendung veröffentlichen, um Sicherheitslücken zu reduzieren. Bedrohungen im Zusammenhang mit Anwendungshosting und -entwicklung werden nicht von Identitätsdomains behoben. Zu diesen Bedrohungen gehören unter anderem indirekter Zugriff auf Anwendungsdatenbanken und -speicher, Click-Jacking, Cross-Site-Scripting, Skript-/SQL-Injection und Informationsvertraulichkeitsflüsse in der Anwendung.
Geringste Berechtigung während Geltungsbereichanforderung anwenden

Clientanwendungen sollten Token anfordern, die nur Geltungsbereiche enthalten, die sie möglicherweise oder tatsächlich verwenden.

Die Verwendung von urn:opc:idm:__myscopes__ scope, obwohl praktisch, kann mehr Token abrufen, als von der Clientanwendung benötigt werden.

Ein Token mit umfangreichen Geltungsbereichen kann die Sicherheitsauswirkungen erhöhen, wenn ein Token kompromittiert wird.

Informationen zur Verwendung des Geltungsbereichsparameters und eines Zugriffstokens zum Erteilen verschiedener Zugriffsebenen für Identitätsdomains finden Sie unter Geltungsbereiche.
JWT-Token validieren

Wenn Sie ein Zugriffstoken (JWT) von einer beliebigen Partei empfangen (mit Ausnahme des Identitätsdomain-Servers in einer direkten Anforderung Ihrer Anwendung), validieren Sie das JWT gemäß dem JWT-Profil für OAuth 2.0 Clientauthentifizierungs- und Autorisierungsberechtigungen und den JWT-RFCs.

Weitere Informationen zum Validieren des Tokens finden Sie unter Tokenvalidierung.

Hinweis

Ressourcenserver müssen Informationen erst verarbeiten, nachdem die gesamte JWT-Validierung ausgeführt wurde.
JWT-Token richtig empfangen

Ressourcenserveranwendungen müssen das Zugriffstoken nur mit dem Authorization: bearer <token>-Header empfangen, um Bedrohungen im Zusammenhang mit dem Parameter-Caching zu vermeiden.
2-Wege-TLS zwischen Client- und Ressourcenserveranwendungen implementieren

Bei sicherheitskritischen Anwendungen können Sie eine 2-Wege-TLS zwischen Client- und Ressourcenserveranwendungen implementieren, um das Risiko von Denial-of-Service-(DoS-) und Impersonierungsangriffen zu reduzieren.

Schreiben Sie keine Anwendungen, die Authentifizierungsinformationen direkt von Benutzern erfassen.
Click-Jacking verhindern

Vermeiden Sie bei neueren Browsern iFrames während der Autorisierung, indem Sie die Verwendung des X-FRAME-OPTIONS-Headers erzwingen.

Bei älteren Browsern können JavaScript Frame-Busting-Techniken verwendet werden, sind jedoch möglicherweise nicht in allen Browsern wirksam.
Vermeiden Sie die Verwendung von Kennwortzugangsdaten für Ressourceneigentümer
Mit dem Ablauf des Ressourceneigentümers kann ein Client ein Zugriffstoken mit der ID, dem Kennwort und den eigenen Zugangsdaten eines Endbenutzers anfordern. Dieser Fördermitteltyp stellt ein höheres Risiko dar, da:
- Es ist für die Erfassung der Benutzerzugangsdaten in der Clientanwendung verantwortlich (verwaltet die UID/das Kennwort-Antimuster).
- Zeigt keinen Einwilligungsbildschirm für Geltungsbereichsanforderungen an.
Vermeiden Sie die Verwendung dieses Berechtigungstyps, außer aus Migrationsgründen.
Cache-Control="no-store"-Header verwenden

Dieser Header minimiert das Risiko, authentifizierte Inhalte nicht zu schützen und vertrauliche Daten in HTTP-Proxys zu verlieren.
Mit URL-Parametern gesendete Anforderungen mit sensiblen Informationen vermeiden

Die URL-Parameter (die bei GET-Anforderungen verwendet werden) können in jeder Komponente zwischen Anwendungen wie Anwendungslogs, Proxyservern, Firewalls und Netzwerk-Edge-Komponenten protokolliert werden.

Identitätsdomains implementieren alternative Such-REST-Endpunkte mit POST, die dieses Risiko beheben. Weitere Informationen finden Sie auf der Seite Abfrageparameter.