Warum Sie von statischen API-Token auf OAuth 2.0 migrieren sollten

Statische API-Token werden seit Langem verwendet, um externe APIs aufzurufen und auf die Ressourcen von Drittanbietern wie Softwareherstellern zuzugreifen. Im Zuge der Weiterentwicklung von API-Standards hat sich OAuth 2.0 als die Option etabliert, die robustere Sicherheit, höhere Flexibilität und eine bessere Entwickler:innenerfahrung bietet. Lassen Sie uns die Vorteile einer Abkehr von statischen Token zugunsten von OAuth 2.0 betrachten.

Statische API-Token-Landschaft

In einem sicheren Softwaresystem müssen alle Aufrufe, die Lese- oder Änderungszugriff auf Ressourcen gewähren, autorisiert sein. Wenn Sie eine geschützte API aufrufen, benötigt die API eine Möglichkeit, die Autorisierung zu validieren. Statische API-Token sind eine Möglichkeit, der API Autorisierungsinformationen mithilfe eines gespeicherten Werts ohne Benutzer:in-Kontext bereitzustellen. Infolgedessen stellten sie einen einfachen (aber eingeschränkten) Ansatz für Entwickler:innen bereit, um einer anderen App API-Zugriff zu gewähren: Ein Token generieren, es einmalig speichern und mit der Aufgabe fortfahren.

Wenn wir uns einen beispielhaften HTTP-Aufruf an Okta ansehen, könnte eine Anfrage mit einem statischen API-Token etwa so aussehen:

Der Aufrufer der API (auch Client genannt) fügt dem Aufruf den Token-Wert hinzu. Je nach aufgerufenem Anbietersystem kann die API den statischen Token-Wert in einen HTTP-Header, wie z. B. Authorization (unter Verwendung eines Standard-Autorisierungsschemas oder eines proprietären Schemas wie dem SSWS-Schema von Okta), oder in einen Abfrageparameter einfügen.

Wechsel von statischen API-Token zu OAuth 2.0 für mehr Sicherheit

Wie bei vielen Technologien geht diese Benutzerfreundlichkeit mit einem entsprechend erhöhten Risiko einher. Im Gegensatz zu kurzlebigen OAuth 2.0-Token haben statische Token in der Regel eine lange Lebensdauer. API-Token, die in Abfrageparametern gesetzt sind, sind besonders gefährlich. Browser speichern URLs im Verlauf, und Protokollierungssysteme zeichnen möglicherweise die gesamte URL auf, wodurch das Token leichter offengelegt wird als bei der Verwendung von HTTP-Headern.

Um die Sicherheitsbedenken im Zusammenhang mit statischen API-Token besser zu verstehen, betrachten wir einige ihrer Eigenschaften im Detail und vergleichen sie mit OAuth 2.0 als Alternative.

Zugriffsrisiken bei der Verwendung statischer API-Token

Statische Token können in die falschen Hände geraten und zu unbefugtem Zugriff führen. Beispielsweise können statische Token versehentlich in Versionskontrollsysteme eingecheckt werden, wodurch das Token unbeabsichtigt für Betrachter:innen des Repositorys und im Versionsverlauf offengelegt wird. Da statische Token langlebig sind, ist das Risiko einer Offenlegung von Token besonders besorgniserregend, denn die Folgen eines gestohlenen Tokens sind schwerwiegend – ein gestohlenes statisches Token bleibt aktiv, bis es manuell deaktiviert wird oder schließlich abläuft, was unbefugten Zugriff ermöglicht.

Probleme bei der Token-Rotation

Die Rotation statischer Token kann eine anspruchsvolle Aufgabe sein. Da Token-Werte in der Umgebung oder den Softwaresystemen der aufrufenden Instanz erhalten bleiben, kann die zeitliche Abstimmung der Rotation – um ein Token schnell freizugeben, ein neues zu generieren und das Token zu speichern, während die Produktionsumgebungen weiterlaufen – Herausforderungen mit sich bringen.

Die Einschränkung des Geltungsbereichs ist schwierig.

Die Zuweisung eingeschränkter Scopes an statische Tokens ist nicht einfach. Statische Token gewähren in der Regel Zugriff auf die gesamte aufgerufene API – eine Alles-oder-nichts-Zugriffsebene. Die Definition von Zugriffen für einen begrenzten Umfang, wie z. B. reiner Lesezugriff im Vergleich zu Schreibzugriff, sowie andere feingranulare Maßnahmen zur Zugriffskontrolle stehen über statische API-Token möglicherweise nicht zur Verfügung oder sind schwer zu verwalten.

Vererbte Berechtigungen in von Benutzer:innen generierten Token

Von Benutzer:innen generierte Access Token übernehmen in der Regel die Berechtigungen des Benutzer-Accounts, der sie generiert hat. Wenn ein:e Administrator:in das Token generiert, hat es vollen Zugriff auf alle Ressourcen und Aktionen, die diese:r Administrator:in ausführen kann. Um diese Bedenken auszuräumen, richten Unternehmen manchmal Servicekonten mit eingeschränkten Scopes ein, um das Token zu generieren. Dies führt jedoch zu einem Mehraufwand bei der Benutzerverwaltung und beansprucht möglicherweise einen Lizenzplatz.

Herausforderungen bei Audits

Es ist schwierig, die Nutzung statischer Token nachzuverfolgen. Eine zentrale Anforderung für das Audit ist die Nachverfolgung der Interaktion einer Benutzer:in mit einer API. Statische API-Token verfügen jedoch in der Regel über keinen Benutzerkontext, und alle Aufrufe der API verwenden dasselbe statische Token. Daher kann es unmöglich sein, die Aktion bestimmter Benutzer:innen über eine API zu identifizieren.

Statische Token sind fragil

Token, die mit Benutzerkonten verknüpft sind, werden ungültig, wenn der Benutzer:in die Organisation verlässt. Einige Organisationen nutzen Service-Accounts, um dieser Maßnahme entgegenzuwirken, was Zugriffsrisiken und Verwaltungsaufwand mit sich bringt.

Es gibt eine bessere und sicherere Methode für den Zugriff auf APIs, die die mit statischen API-Tokens verbundenen Risiken mindert: die Verwendung von branchenübliche Standard OAuth 2.0-Flows.

Nutzen Sie OAuth 2.0 zur Verbesserung der Sicherheit.

OAuth 2.0 deckt anstelle von statischen Token wie den SSWS-Token von Okta fast jedes Szenario ab. Aber im Gegensatz zu statischen Token enthalten die OAuth-Spezifikationen Definitionen und Sicherheitspraktiken für erforderliche Funktionen wie die Token-Rotation, grundlegende Autorisierungsentscheidung und mehr für alltägliche Anwendungsfälle wie

• Automatisierte Service-to-Service-Interaktion zur Verarbeitung von API-Aufrufen im Hintergrund ohne Benutzerkontext
• Aufgabenbasierte Automatisierung durch Ihre Befehlszeilenoperationen
• Beschränkung von Anwendungsdaten und -aktionen auf die Zugriffsebenen der Benutzer:innen zur Wahrung der Autorisierungssicherheit

OAuth 2.0 unterstützt jeden der oben aufgeführten alltäglichen Anwendungsfälle durch Konfigurationseigenschaften, die in einer Anfrage an einen zentralen Autorisierungsserver gesendet werden. Die allgemeine Interaktion ist ein mehrstufiger Prozess, der wie folgt abläuft:

1. Der Aufrufer fordert ein Access Token vom Autorisierungsserver an und übergibt dabei die für den Anwendungsfall erforderlichen Konfigurationseigenschaften. Der Autorisierungsserver gibt ein kurzlebiges Access Token zurück. Die Lebensdauer des Tokens hängt vom Anwendungsfall ab. Einige Anwendungsfälle sind von Natur aus sicherer, sodass die Lebensdauer variieren kann. Die unten stehende HTTP-Anfrage zeigt eine Beispielanfrage zum Abrufen eines Tokens, enthält jedoch nicht die erforderlichen Konfigurationseigenschaften. In den folgenden Beispielen sehen Sie die erforderlichen Konfigurationseigenschaften.

2. Aufrufer:innen verwenden den Token-Wert in der API-Anfrage als Wert im Authorization-Header der HTTP-Anfrage unter Verwendung des Bearer-Schemas. Die HTTP-Anfrage könnte in etwa so aussehen:

OAuth 2.0 ist ein sehr umfangreiches Thema. Sehen Sie sich daher für tiefere Einblicke die Ressourcen am Ende dieses Beitrags an. Wir werden in diesem Beitrag nicht auf alle Details eingehen, sondern die Informationen speziell auf die genannten Anwendungsfälle zuschneiden und jeweils eine allgemeine Zusammenfassung bereitstellen.

Betrachten wir jeden Anwendungsfall, um zu sehen, wie OAuth 2.0 ihn unterstützt.

Service-zu-Service-Interaktion

Möglicherweise haben Sie Backend-Prozesse, die andere APIs aufrufen, um Daten abzurufen oder Aktionen auszuführen. OAuth 2.0 unterstützt Service-to-Service- oder Machine-to-Machine-Anfragen ohne einen mit dem Aufruf verbundenen Benutzer:innenkontext durch einen Autorisierungs-Flow namens Client-Anmeldedaten.

Vorteile der Verwendung von Client-Anmeldedaten gegenüber API-Tokens

Die Verwendung von OAuth 2.0 für die Service-to-Service-Interaktion bietet enorme Vorteile gegenüber statischen API-Schlüsseln, insbesondere im Hinblick auf Zugriffsebenen, die sogenannten Scopes. In OAuth 2.0 geben Sie die Scopes, die Ihr Access Token erhält, als Teil der Konfigurationseigenschaften in einem Aufruf zum Abrufen Ihres Tokens an. Sie sollten sicherstellen, dass die von Ihnen aufgerufene API Scope-basierten Zugriff unterstützt und dass Sie den Zugriff auf die benötigten Scopes gewährt haben. Beispielsweise haben Okta-APIs mehrere Scopes für Ressourcen-APIs definiert, wie etwa okta.users.read und okta.users.write. Sie können Zugriff auf einen oder beide dieser Scopes gewähren.

Der Client-Anmeldedaten-Flow ist nicht dasselbe wie die Verwendung von Service-Accounts für die API-Autorisierung. OAuth 2.0 unterstützt die Maschine-zu-Maschine-Interaktion in einem Standardformat, ohne einen Benutzerplatz zu belegen, um eine:n Automatisierungsbenutzer:in zu emulieren. Bitte beachten Sie, dass Sie Scopes in der Konfiguration der Service-Anwendung und innerhalb des Autorisierungsservers definieren, nicht auf Benutzer:innenebene. Der Vorteil besteht darin, dass Sie den Ressourcenzugriff für die gesamte Service-Anwendung steuern und nicht über eine:n Benutzer:in innerhalb der Anwendung. Sie brauchen sich keine Gedanken mehr über die Verwaltung von Service-Accounts zu machen und können darauf vertrauen, dass die Anwendung nicht auf mehr Scopes zugreifen kann, als Sie zugelassen haben.

Ein Access Token mithilfe von Client-Anmeldedaten abrufen

Um ein Access Token für diesen Flow abzurufen, sollten Sie Eigenschaften übermitteln, die den Typ des Autorisierungs-Flows, die Anmeldedaten und die Scopes des Access Tokens angeben. Der OAuth 2.0-Begriff zur Definition des Autorisierungs-Flows lautet grant_type; für den Client-Anmeldedaten-Flow übergeben Sie den Wert client_credentials.

Die Anmeldedaten können entweder ein kryptografisch sicheres JSON Web Token (JWT) sein, das mit dem privaten Schlüssel des Clients signiert ist, oder ein geheimer Wert, der von Ihrem Autorisierungsserver generiert wird. Ein Private-Key-JWT ist sicherer, da Sie nicht riskieren, den geheimen Wert offenzulegen, was versehentlich zu ähnlichen Zugriffsproblemen wie bei einem statischen API-Token führen könnte. Sie generieren ein öffentliches/privates Schlüsselpaar und registrieren den öffentlichen Schlüssel in einem JSON Web Key Set (JWKS) oder laden ihn auf den Autorisierungsserver hoch, damit dieser über den öffentlichen Schlüssel verfügt, um die JWT-Signatur zu validieren. Weitere Informationen zu diesem Prozess finden Sie in der Dokumentation OAuth by Okta mit einer Service-App implementieren.

Ein beispielhafter HTTP-Aufruf zum Abrufen des Access Tokens könnte wie folgt aussehen:

Sobald Sie das Access Token erhalten haben, sollten Sie es den API-Aufrufen als Header hinzufügen: Authorization: Bearer access_token.

Lesen Sie mehr über Service-zu-Service-API-Aufrufe mit .NET und die Erstellung privater JWTs in Python in Sichern Sie Ihre .NET 6-Web-API und Richten Sie den Private-Key-JWT-Flow mit drei Python-Befehlen ein.

Aufgabenbasierte Automatisierung

Befehlszeilenterminals wie Bash und PowerShell sind browserlose Prozesse, mit denen Sie einzelne Befehle oder Skripte in Ihrem Terminalfenster ausführen können. Im Gegensatz zur vorherigen Service-to-Service-Interaktion beinhaltet dieser Flow den Benutzerkontext. Sie möchten die Befehlszeilenoperationen mit Ihrem Autorisierungskontext ausführen, was bedeutet, dass Sie nur Zugriff auf die API-Ressourcen haben, für die Sie berechtigt sind. OAuth 2.0 unterstützt diesen Anwendungsfall mit einem Flow namens Geräte-Flow.

Das Abrufen von Access Token ist bei diesem Flow ein mehrstufiger Prozess. Bevor Sie das Access Token wie beim Service-to-Service-Anwendungsfall direkt anfordern, erhalten Sie zunächst eindeutige Verifizierungscodes, indem Sie die Client-ID an einen speziellen Endpoint auf Ihrem Autorisierungsserver senden:

Die Antwort des Aufrufs /device/authorize gibt zwei eindeutige Codes – einen Gerätecode und einen Benutzer:in-Code – sowie eine Verifizierungs-URI zurück. Sie können die Autorisierungsanfrage bestätigen, indem Sie in Ihrem Browser zur Verifizierungs-URI navigieren und den Benutzercode eingeben.

Um das Access Token abzurufen, sollten Sie die Eigenschaft grant_type zur Angabe des OAuth 2.0-Flows für den Anwendungsfall sowie den Gerätecode als Konfigurationseigenschaften im Aufruf hinzufügen:

Sie sollten den Access Token aus der Antwort im Header „Authorization: Bearer access_token“ verwenden.

Weitere Informationen zum Gerätecode-Flow für Befehlszeilen finden Sie unter Authentifizierung über die Befehlszeile mit Java.

Benutzerzugriff über eine Webanwendung

Der letzte Anwendungsfall stellt sicher, dass die Autorisierung der Benutzer:in für den API-Zugriff bei der Nutzung einer Webanwendung gilt. OAuth 2.0 unterstützt die Beschränkung der Aktionen einer Anwendung auf eine Teilmenge dessen, was die Benutzer:innen tun können und welche Daten sie sehen. In diesem Flow verfügen Sie über den Benutzerkontext, um eine Ressourcenautorisierung zu beantragen. Darüber hinaus erleichtert der Benutzerkontext das Auditing und die Nachverfolgung von Aufrufen durch einzelne Benutzer:innen. Der OAuth 2.0-Flow für diesen Anwendungsfall kombiniert einen Standard-Flow, den Authorization Code Flow, und eine Erweiterung für eine zusätzliche Sicherheitsebene namens Proof Key for Code Exchange (PKCE).

Der Authorization Code Flow mit PKCE erfordert mehrere Schritte, um ein Access Token abzurufen, und beinhaltet die Interaktion der Benutzer:innen durch Zustimmung und Verifizierung, was eine Multi-Faktor-Authentifizierung ermöglicht. In diesem Flow leiten Sie den Benutzer:in an einen Autorisierungsserver weiter, um den Autorisierungscode zu erhalten, bevor Sie ein Access Token anfordern.

Die Weiterleitungs-URL enthält anfragespezifische Eigenschaften, damit sie die Anmeldung abschließen können, darunter neben anderen Eigenschaften die Angabe des Anfragetyps über eine response_type-Eigenschaft sowie die Client-ID.

Wenn die Benutzer:in die Anmeldung erfolgreich abgeschlossen hat, leitet der Identity-Anbieter mit einem Autorisierungscode in der Autorisierungsantwort zur Anwendung zurück. Um das Access Token abzurufen, übergeben Sie den Grant-Typ für diesen Flow, den Autorisierungscode und weitere anfragespezifische Metadaten.

Mit dem erhaltenen Access Token fügt die Web-App das Access Token den ausgehenden API-Aufrufen im Header „Authorization: Bearer access_token“ hinzu.

Weitere Informationen zum Authorization Code Flow finden Sie unter Wie Authentifizierung und Autorisierung für SPAs funktionieren und Verwendung von PKCE mit OAuth 2.0 und Spring Boot für mehr Sicherheit.

Wir empfehlen, statische API-Token schrittweise abzuschaffen und OAuth 2.0 zu verwenden.

Softwaremigrationen erfordern Zeit und Planung, und eine gute Strategie ist dabei hilfreich. Wir empfehlen, die Umstellung auf OAuth 2.0 in kleinen, inkrementellen Schritten vorzunehmen.

Der erste Schritt bei der Migration von statischen API-Token besteht darin, sicherzustellen, dass die von Ihnen verwendeten APIs OAuth 2.0 unterstützen. Sie sollten sich bei Ihrem Anbieter erkundigen, wenn Sie Drittanbieter-APIs aufrufen. Wenn Ihre API intern ist, sollten Sie OAuth-Support hinzufügen. Sobald Sie überprüft haben, dass die von Ihnen aufgerufenen APIs OAuth unterstützen, benötigen Sie die Client-ID für die OAuth-Anwendung und sollten Zugriffsmaßnahmen wie Scopes aktivieren.

Wenn Sie sich als Administrator:in bei Ihrer Okta Admin-Konsole anmelden, können Sie ermitteln, ob Sie in einer Okta-Umgebung statische API-Token verwenden. Sie können in der Seitenleiste zu Sicherheit > API navigieren und die Registerkarte Tokens auswählen, um alle für die Okta-Organisation erstellten Tokens anzuzeigen. Diese Ansicht bietet Einblicke in die Nutzung, die Anwendungsfälle und die Zugriffsebene von API-Token (so verfügt beispielsweise ein von einem Super Administrator erstelltes Token über Vollzugriff). Sie sollten jeden davon prüfen und auf die Nutzung von OAuth umstellen.

Konzentrieren wir uns auf den Anwendungsfall eines automatisierten Service-to-Service-Aufrufs. Die Integration von OAuth 2.0 in Ihre APIs in einem einzigen Schritt kann eine große Herausforderung darstellen. Sehen wir uns daher an, wie sich dies schrittweise umsetzen lässt. Bevor Sie Codeänderungen vornehmen, können Sie die Schritte lokal manuell ausprobieren und Ihren bevorzugten HTTP-Client verwenden, um ein Token anzufordern und eine API über OAuth 2.0 aufzurufen. In diesem Fall wird der Client-Anmeldedaten-Flow mit einem Private-Key-JWT verwendet. Die Schritte lauten:

1. Generieren Sie das öffentliche/private Schlüsselpaar
2. Verwenden Sie das öffentliche/private Schlüsselpaar, um das Private-Key-JWT zu generieren.
3. Fordern Sie das Access Token an.
4. Sie sollten das Access Token zu Ihrer API-Anfrage hinzufügen.
5. Integrieren Sie OAuth in Ihr Anwendungssystem.

1. Öffentliches/privates Schlüsselpaar generieren

Sie können ein öffentliches/privates Schlüsselpaar generieren, indem Sie dieser Anleitung folgen. Die Admin-Konsole von Okta kann zu Testzwecken ein öffentliches/privates Schlüsselpaar generieren, wenn Sie es nicht selbst generieren möchten.

2. Private Key JWT generieren

Um das Private-Key-JWT zu erstellen, sollten Sie das Public/Private-Key-Paar verwenden und den Anweisungen in der Dokumentation OAuth by Okta mit einer Service-App implementieren folgen. In diesem Schritt ist es wichtiger zu verstehen, wie das alles funktioniert, anstatt die Schritte zu automatisieren. So können Sie das öffentliche/private Schlüsselpaar lokal speichern, auf Ihrem Computer installierte Tools verwenden und den JWKS mit Ihrem öffentlichen Schlüssel vorerst in eine Test-Website zur JWT-Generierung einfügen.

3. Access Token anfordern

Sie können das Access Token mit Ihrem Private Key JWT anfordern, ohne Scopes hinzuzufügen, indem Sie die HTTP-Anfrage in Ihrem bevorzugten HTTP-Client stellen. Sie sollten einen Fehler erhalten, wenn Sie das Access Token ohne den richtigen Scope verwenden. Es ist jedoch empfehlenswert, sowohl auf Fehler als auch auf Happy Paths zu testen. Das Access Token läuft zu einem bestimmten Zeitpunkt ab, und Sie sehen die Ablaufzeit in der Access-Token-Antwort. Das Access Token ist Teil der Antwort. Sie verwenden die gesamte Zeichenfolge als Access Token.

4. Fügen Sie das Access Token zu Ihrer API-Anfrage hinzu.

Sie sollten Ihre API über Ihren HTTP-Client mit dem Access Token aufrufen. Sie fügen einen Authorization-Header hinzu und verwenden das Bearer-Schema, sodass Ihr API-Aufruf den folgenden Header aufweist, der dem unten gezeigten Format entspricht:

Wenn Sie den API-Aufruf ausführen, sollten Sie einen Fehler mit dem HTTP-Status 403 erhalten. Juhu! Erfolg? Nun ja, ein erfolgreicher Fehlerfalltest. Jetzt wissen Sie, welchen Fehler Sie erwarten können, wenn bei der Konfiguration von Scopes ein Fehler auftritt. Fügen wir die Scopes zur Anforderung des Access Tokens hinzu und versuchen es erneut.

Sie sollten dieses Mal Ihr Access Token mithilfe des Private Key JWT anfordern und die Scopes für den API-Aufruf hinzufügen. Sie sollten das Access Token im API-Aufruf verwenden. Der Moment der Wahrheit! Sie sollten eine erfolgreiche Antwort sehen. Sie wissen, dass ein Konfigurationsfehler vorliegt, wenn Sie erneut einen 403-Fehler erhalten. Wenn dies der Fall ist, sollten Sie die Scopes der Anfrage überprüfen und sicherstellen, dass die von Ihnen angeforderten Scopes in der OAuth 2.0-Anwendung aktiviert sind.

5. Fügen Sie OAuth 2.0-Autorisierung in Ihrem System hinzu

Nachdem Sie nun die OAuth 2.0-Autorisierung für einen Server-zu-Service-Aufruf erfolgreich manuell durchlaufen haben, können Sie Aspekte dieser Schritte in Ihr System übernehmen. Sie sollten versuchen, das Access Token in einer Entwicklungs- oder Testumgebung zu verwenden. Sie sollten Ihre APIs so ändern, dass sie den Authorization-Header im Bearer-Schema-Format verwenden, und Ihr bestehendes statisches API-Token durch das manuell generierte Access Token ersetzen. So stellen Sie sicher, dass Ihre API-Aufrufe funktionieren, ohne die Schritte zur Anforderung des Access Tokens zu automatisieren.

Wenn Sie sicher sind, dass Ihr API-System das Access Token erfolgreich verarbeitet, ist es an der Zeit, die Schritte hinzuzufügen, um es aus Ihrem Code heraus anzufordern. Ihr Tech-Stack verfügt möglicherweise über SDKs, die Sie bei zumindest einem Teil (oder allen) der Anfrageschritte unterstützen. Oktas Management-SDKs können den OAuth-2.0-Handshake für Sie übernehmen. Java-Spring-Nutzer:innen können sich beispielsweise die Spring Security-Dokumentation ansehen und .NET-Core-Nutzer:innen Microsoft.AspNetCore.Authentication. Wir empfehlen Ihnen, Ihre Arbeit fortlaufend zu testen und dabei sowohl den Happy Path und Fehlerfälle als auch Szenarien wie den korrekten Umgang mit dem Ablauf von Access Tokens zu berücksichtigen.

Bevor Sie Änderungen in Ihrer Produktionsumgebung bereitstellen, sollten Sie Tools in Produktionsqualität für die interne Generierung des JWKS verwenden und Ihren privaten Schlüssel sicher verwalten.

Best Practices bei Migrationen der API-Autorisierung

Ein sofortiger Verzicht auf statische Token ist nicht immer machbar, insbesondere in großen Organisationen oder wenn viele APIs zu aktualisieren sind. Wenn Sie weiterhin SSWS-Token mit Okta verwenden, sollten Sie die Risiken minimieren, bis Sie auf OAuth 2.0 umstellen können. Zu den Best Practices gehören:

• Sie sollten neue API-Aufrufe oder Code mit OAuth 2.0 implementieren.
• Sie sollten das Least-Privilege-Prinzip befolgen. Zum Beispiel:
  • Sie sollten keine persönlichen Accounts verwenden, um Service-Accounts einzurichten.
  • Sie sollten für Service-Accounts eine benutzerdefinierte Administratorrolle verwenden, die nur die wesentlichen Berechtigungen gewährt.
  • Wir empfehlen die Verwendung von Gruppen und Globalen Session-Richtlinien, um interaktive Anmeldungen für Service-Accounts zu verhindern.

Sichern Sie API-Aufrufe mit OAuth 2.0

Beim Wechsel von statischen Token zu OAuth 2.0 geht es nicht nur um die Einführung neuer Technologie, sondern auch um die Ausrichtung auf ein sichereres, flexibleres und entwicklerfreundlicheres Ökosystem. Während statische Token ihre Zeit und Berechtigung hatten, steht fest, dass die Zukunft in dynamischen, benutzerzentrierten und sicheren OAuth 2.0-Lösungen liegt.

Denken Sie daran: Mit dem Fortschritt der Technologie ist es nicht nur vorteilhaft, auf dem neuesten Stand zu bleiben und sich an bessere Praktiken anzupassen – es ist unerlässlich. Migrieren Sie zu OAuth 2.0 und profitieren Sie von einer sichereren, optimierten und effizienteren Entwickler:innen-Erfahrung.

Nächste Schritte mit OAuth 2.0

Wenn Sie diesen Beitrag interessant finden, könnten Ihnen diese Beiträge gefallen.

• Auswahl der besten Autorisierung für Ihre API-Integrationen
• Fügen Sie jeder App mit OAuth2 Proxy Authentifizierung hinzu
• OAuth für Java-Entwickler:innen

Sehen Sie sich Oktas Leitfäden für Entwickler:innen zur API-Sicherheit an, um mit Ihrer Migration zu OAuth 2.0 zu beginnen:

Demonstrating Proof-of-Possession konfigurieren

• Dieser Leitfaden erläutert die Erstellung absenderbeschränkter Access Token, die einen Mechanismus auf Anwendungsebene darstellen, um Token-Replays an verschiedenen Endpoints zu verhindern.

Konfigurieren Sie OAuth by Okta

• Dieser Leitfaden erklärt, wie Sie mithilfe von bereichsbezogenen OAuth 2.0-Access Tokens mit Okta-APIs interagieren. Konfigurieren Sie OAuth by Okta: Service-App
• Dieser Leitfaden beschreibt die Interaktion mit Okta-APIs mithilfe von bereichsbezogenen OAuth 2.0-Access Tokens für eine Service-App.

Schützen Sie Ihre API-Endpunkte

• Fügen Sie Autorisierung über Okta hinzu, um Ihre APIs zu schützen. Wenn Sie fertig sind, verfügen Sie über eine sichere REST-API-Anwendung, die eingehende Anfragen validiert.

Integrieren Sie Drittanbieter-Risiken

• Dieser Leitfaden erläutert die Konfiguration einer Okta Org für den Empfang von Risikoereignissen von einem Drittanbieter. Sichere API-Verbindung zwischen Organisationen mit OAuth 2.0
• Dieser Leitfaden beschreibt die sichere Einrichtung von Okta-Hub- und Spoke-Organisationen, um Benutzer:innen und Gruppen mithilfe von OAuth 2.0 in einer Multi-tenant-Lösung zu synchronisieren. Sie können den Okta Org-API-Zugriff auf bereichsbezogene Daten über den OAuth 2.0-Client-Credential-Flow für die App Org2Org-Integration verbinden.

Richten Sie die Step-up-Authentifizierung mit ACR-Werten ein

• Dieser Leitfaden erklärt, wie Sie den Parameter acr_values in Ihre Autorisierungsanfragen einbinden, um das Vertrauensniveau der Endbenutzer zu erhöhen.

Für weitere spannende Inhalte folgen Sie @oktadev auf X, finden Sie uns auf LinkedIn und abonnieren Sie unseren YouTube-Kanal.