Oracle Cloud Infrastructure - Dokumentation

Autorisierung mit der API verwalten

Die REST-API für Identitätsdomains unterstützt sowohl tokenbasierte Autorisierung als auch OCI-Anforderungssignaturen. Aus Sicherheitsgründen ist die REST-API für Identitätsdomains nicht nur mit dem Benutzernamen und Kennwort zugänglich, mit dem Sie sich bei der Identitätsdomain anmelden. Um auf die REST-API für Identitätsdomains zuzugreifen, benötigen Sie ein OAuth2-Zugriffstoken oder einen API-Schlüssel für die Autorisierung.

Die Identitätsdomain-REST-API verwendet das OAuth 2.0-Protokoll zur Authentifizierung und Autorisierung und unterstützt die folgenden allgemeinen Autorisierungsszenarios:

  • Webserver

  • Mobiltelefonnummer

  • JavaScript Anwendungen

Im Abschnitt "Autorisierung" werden die OAuth 2.0-Szenarios erläutert, die von Identitätsdomains unterstützt werden.

In diesem Abschnitt werden folgende Themen behandelt:

Clientanwendungen registrieren

Eine Anwendung muss mit der Identitätsdomain als OAuth 2-Client registriert werden. OAuth-Clients sind HTTP-Clients, die ein Zugriffstoken abrufen und dann verwenden können.

Gehen Sie folgendermaßen vor, um einen OAuth-Client für den Zugriff auf die REST-API für Identitätsdomains zu verwenden:

  1. Melden Sie sich mit dem Benutzernamen und Kennwort in Ihrer Willkommens-E-Mail bei der Identitätsdomain an.

  2. Erstellen Sie eine Clientanwendung OAuth, und notieren Sie sich die Client-ID und das Client Secret.

    Hinweis

    Wenn Sie die Clientanwendung OAuth konfigurieren, wählen Sie die Anwendungsrollen aus, die Sie der Anwendung zuweisen möchten. So kann Ihre Anwendung auf die REST-APIs zugreifen, die jede der zugewiesenen Anwendungsrollen aufrufen kann. Jeder Anwendungsrolle sind Geltungsbereiche zugewiesen, die eine noch feinere Zugriffsebene auf API-Vorgänge definieren. Beispiel: Wählen Sie die Option Identitätsdomainadministrator in der Liste aus. Alle für den Identitätsdomainadministrator verfügbaren REST-API-Vorgänge sind dann auch für die Anwendung zugänglich.

  3. Verwenden Sie die Client-ID und das Client Secret, um ein Zugriffstoken vom IAM-Service OAuth anzufordern.

  4. Nehmen Sie das Zugriffstoken in den entsprechenden HTTP-Header auf, wenn Sie REST-API-Aufrufe ausführen.

Weitere Informationen

Sicherheitsempfehlungen

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

Je nach Vertraulichkeits-, Integritäts- und Verfügbarkeitsanforderungen Ihrer Anwendung können die Sicherheitskontrollen 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 Impersonierungsangriffe zu vermeiden)

  • Richtige Informationsvalidierung für alle Anforderungen (insbesondere für JSON Web Token-(JWT-)Zugriffstoken)

  • Verwendung von Token mit minimalem Geltungsbereich und Timeout (um die Exposition im Falle einer Offenlegung zu reduzieren und den Token-Widerruf zu unterstützen)

  • Verwendung typischer Informationssicherheitsgrundsätze wie Least-Privilege

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 Ihre Anwendungssicherheit validieren und die Sicherheitselemente Ihren Erwartungen entsprechend bearbeiten können.

Verschlüsselung

  • TLS in Client- und Ressourcenserveranwendungen verwenden

    Die Verwendung von TLS mit 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 Replay-Angriffe werden verhindert.

  • Serverauthentifizierung einrichten (HTTPS mit Trusted CA Validation)

    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 und 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.

  • Verwenden einer vertrauenswürdigen Assertion mit Identitätsdomains

    Kritische Sicherheitsclients können eine Client-Assertion mit Schlüsselkryptografie (anstelle eines Client Secret) zur Authentifizierung verwenden.

  • Umleitungs-URI mit HTTPS und vertrauenswürdiger CA-Validierung schützen

    HTTPS und die Verwendung der vertrauenswürdigen CA-Validierung verhindern das "Code"-Phishing der Autorisierung und die Imitation von Benutzersessions.

Administration

  • Anwendungen nach dem Prinzip der geringsten Berechtigungen konfigurieren

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

    Die Beschränkung des Geltungsbereichs, der Abläufe, der Gewährungstypen und der Vorgänge verbessert die Sicherheitslage und reduziert die Auswirkungen einer kompromittierten Anwendung.

  • Geben Sie einen aussagekräftigen 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 Benutzer daran hindern, während der Einwilligungserlaubnis Fehler zu machen, und trägt auch zu einem besseren Audit-Reporting bei.

  • Aussagekräftige Beschreibung für Geltungsbereiche angeben

    Die Beschreibung des Geltungsbereichs wird auf der Seite "Einwilligung" angezeigt. Die Erläuterung des Geltungsbereichs, den der Benutzer erteilen wird, verhindert auf verständliche Weise, dass der Benutzer während der Autorisierung Fehler macht, und trägt zu einem besseren Audit-Reporting bei.

  • Geltungsbereiche ohne Einwilligung vermeiden

    Um Transparenz zu nutzen und sich auf den Ressourceneigentümer zu verlassen, geben Sie Geltungsbereiche ohne Berechtigung nur dann an, wenn ein Geltungsbereich obligatorisch ist und der Benutzer ihn nicht leugnen kann.

  • Timeout für Zugriffstoken reduzieren und Aktualisierungstoken verwenden

    Identitätsdomains unterstützen JWT, ein Zugriffstoken, das auf 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 rechtzeitigen 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 verringert das Risiko, dass ein kompromittiertes Kundengeheimnis erforscht wird.

Ressourceneigentümer (Benutzer)

  • Ressourcenverantwortlichen auf dem Laufenden halten

    Die Verwendung des Geltungsbereichs mit Zustimmung bietet Transparenz für den Ressourceneigentümer und verhindert, dass Anwendungen Bereiche anfordern, die nicht erforderlich sind.

  • Benutzerkenntnis

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

Anwendungsentwicklung

  • Codes, Zugriffstoken, Token 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 Maßnahmen zur Anwendungssicherheit):

    • Codes nicht speichern (den Code nur während der Laufzeit verwenden, um das Zugriffstoken abzurufen)

    • Behalten Sie Zugriffstoken im transienten Speicher bei, und begrenzen Sie deren Berechtigungen

    • Speichern Sie Aktualisierungstoken und Clientzugangsdaten an sicheren Orten, auf die nur die Anwendung zugreifen 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-Request-Fälschung und Denial-of-Service zu vermeiden.

  • Token aus dem nativen Anwendungsdateisystem lesen

    Angreifer können versuchen, Zugriff auf das Dateisystem auf dem Gerät zu erhalten und die Aktualisierungstoken mit einer böswilligen Anwendung zu lesen. Um dieses Risiko zu reduzieren, speichern Sie Secrets im 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 entziehen.

  • Anwendungssicherheit vor Veröffentlichung validieren

    Testen Sie die Sicherheit der Anwendung und der zugehörigen Hostingumgebung, bevor Sie die Anwendung veröffentlichen, um Sicherheitslücken zu reduzieren. Bedrohungen im Zusammenhang mit Anwendungshosting und -entwicklung werden nicht von Identitätsdomains adressiert. Zu diesen Bedrohungen gehören unter anderem der indirekte Zugriff auf Anwendungsdatenbanken und -speicher, Select-Jacking, Cross-Site-Scripting, Script/SQL-Injection und Informationsvertraulichkeitsflüsse in der Anwendung.

  • Geringste Berechtigung während Umfangsanforderung 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 kann, obwohl praktisch, mehr Token abrufen, als von der Clientanwendung benötigt werden.

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

    Informationen zur Verwendung des Scope-Parameters und eines Zugriffstokens, um verschiedene Zugriffsebenen für Identitätsdomains zu erteilen, finden Sie unter Geltungsbereiche.

  • JWT-Token validieren

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

    Weitere Informationen zur Validierung 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

    Für sicherheitskritische 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.

  • Select-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.

  • Verwendung von Kennwortzugangsdaten des Ressourceneigentümers vermeiden

    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 birgt ein höheres Risiko, da:

    • Es ist für die Erfassung der Benutzerzugangsdaten in der Clientanwendung verantwortlich (wartet das UID/Passwort-Anti-Muster).

    • Es wird kein Einwilligungsbildschirm für Umfangsanforderungen angezeigt.

    Vermeiden Sie die Verwendung dieses Zuteilungstyps außer aus Migrationsgründen.

  • Header Cache-Control="no-store" verwenden

    Dieser Header minimiert das Risiko, authentifizierte Inhalte nicht zu schützen und vertrauliche Daten in HTTP-Proxys zu verlieren.

  • Anforderungen mit sensiblen Informationen vermeiden, die mit URL-Parametern gesendet werden

    Die URL-Parameter (in GET-Anforderungen verwendet) können in jeder beliebigen 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 adressieren. Weitere Informationen finden Sie auf der Seite Abfrageparameter.