Der Schutz persönlicher und geschäftlicher Informationen ist wichtiger denn je, da die digitale Technologie immer weiter verbreitet ist. Identity dient als primäre Sicherheitsgrenze für Unternehmens- und Verbraucheranwendungen. Da Cyberangriffe und Datenschutzverletzungen weiterhin zunehmen, ist der Schutz sensibler Daten zu einer Priorität für Einzelpersonen und Organisationen geworden.
Laut dem Data Breach Investigations Report (2024) von Verizon werden 86 % der Verstöße auf gestohlene Anmeldedaten zurückgeführt, darunter Passwörter, OAuth/OpenID Connect-Token und API-Schlüssel. Diese Token werden typischerweise verwendet, um Benutzer zu authentifizieren und zu autorisieren, sich bei mehreren Websites anzumelden, Benutzern zu ermöglichen, für einen längeren Zeitraum angemeldet zu bleiben, und Profilinformationen über den Benutzer abzurufen, die die Website verwenden kann, um ihre Erfahrung zu personalisieren. Anwendungen können diese Token verwenden, um auf geschützte Ressourcen wie APIs und sensible Informationen zuzugreifen.
Die Sicherung dieser privilegierten Artefakte (Token) ist zu einer unternehmenskritischen Anforderung geworden. Im Folgenden finden Sie Best Practices, die Sie implementieren können, um Ihre OAuth- und OpenID Connect-Token zu sichern.
Kurze Einführung in OAuth/OpenID Connect-Token und Anwendungstypen
Lassen Sie uns zunächst die verschiedenen OAuth- und OpenID Connect-Token- und Anwendungstypen durchgehen.
Token-Typen
Token sind sichere digitale Anmeldedaten, die verwendet werden, um die Identität eines Benutzers zu überprüfen und den Zugriff auf geschützte Ressourcen zu gewähren. Die Payload des Tokens enthält normalerweise Informationen über das Benutzerprofil, Berechtigungen und Metadaten, die kryptografisch signiert sind, um Authentizität und Integrität zu gewährleisten.
ID-Token: Wie der Name schon sagt, werden ID-Token verwendet, um den Principal (d. h. den Endbenutzer) zu identifizieren. Sie enthalten Informationen über den Benutzer und beweisen, dass der OpenID-Provider den Benutzer erfolgreich authentifiziert hat. Die Zielgruppe für dieses Token ist der OpenID-Client, d. h. die Anwendung selbst.
Access Tokens: OpenID Connect arbeitet zusammen mit OAuth 2.0 für Autorisierungszwecke. OAuth 2.0 Access Tokens delegieren Berechtigungen an die Anwendung, um die Backend-APIs im Namen des Benutzers aufzurufen. Die Zielgruppe des Tokens ist die Backend-API (d. h. der Ressourcenserver).
Refresh Tokens: Access und ID-Token sind kurzlebig und laufen nach einer bestimmten Zeit ab. Refresh Tokens sind langlebige Grants, die die Anwendung verwenden kann, um ein neues Paar von Access- und ID-Token vom Autorisierungsserver anzufordern. Die Zielgruppe des Refresh Tokens ist der Autorisierungsserver selbst.
Anwendungstypen
Gemäß der OAuth-Spezifikation können Anwendungen entweder als vertraulich oder öffentlich eingestuft werden. Der Hauptunterschied besteht darin, ob die Anwendung Anmeldedaten (wie eine Client-ID und ein Secret) sicher speichern kann oder nicht.
Öffentliche Anwendungen: Diese Anwendungen können Client Secrets oder Anmeldedaten, die ein Autorisierungsserver bereitstellt, nicht sicher speichern. Beispiele für öffentliche Anwendungen sind moderne JavaScript-basierte clientseitige Anwendungen, die im Browser ausgeführt werden (Single-Page-Anwendungen), und native Anwendungen, die auf Mobilgeräten und Desktops installiert sind.
Vertrauliche Anwendungen: Andererseits können vertrauliche Anwendungen Client-Anmeldedaten sicher speichern und die Vertraulichkeit wahren. Diese Anwendungen werden auf einem sicheren Server ausgeführt, und daher sind die Anmeldedaten für die Endbenutzer nicht zugänglich. Beispiele für vertrauliche Anwendungen sind traditionelle Webanwendungen und Backend-Server-to-Server-Anwendungen.
5 Best Practices zur Sicherung Ihrer Token
1. Verwenden Sie asymmetrische Kryptografie für die Client-Authentifizierung
Die Client-Authentifizierung ermöglicht es uns, die Identität der Client-Anwendung zu überprüfen, um Client-Impersonierung zu verhindern und einen sicheren Zugriff auf geschützte Ressourcen zu ermöglichen. So wie Passwörter als schwacher Benutzerauthentifizierungsfaktor gelten, sind Client Secrets eine schwache Client-Authentifizierungsmethode, da das Client Secret im Anforderungstext enthalten ist und auf einem Shared Secret basiert.
Im Gegensatz zu Client Secrets werden asymmetrische kryptografische Techniken wie mTLS oder signierte JSON Web Token (JWTs), bekannt als Private Key JWTs, niemals über das Netzwerk übertragen, wodurch das Risiko von Key-Leaks und Man-in-the-Middle-Angriffen erheblich reduziert wird. Die Client-Authentifizierung gilt nur für vertrauliche Clients. Erwägen Sie daher beim Erstellen Ihrer Anwendung die Verwendung einer robusten Client-Authentifizierungsmethode, insbesondere wenn Sie sensible Informationen verarbeiten. Erfahren Sie mehr über Client-Authentifizierungsmethoden.
2. Verwenden Sie PKCE für öffentliche Clients
Der Aufstieg mobiler und webbasierter Anwendungen hat wahrscheinlich zu einer Zunahme öffentlicher Clients geführt. Da die Client-Authentifizierung nicht mit öffentlichen Client-Anwendungen verwendet werden kann, stellt Proof Key for Code Exchange (PKCE) sicher, dass nur der ursprüngliche Client, der die Autorisierungsanforderung initiiert hat, den Code gegen Token austauschen kann.
PKCE stellt sicher, dass ein Angreifer einen gestohlenen Autorisierungscode nicht am Token-Endpunkt des Autorisierungsservers einlösen kann. Während PKCE ursprünglich für öffentliche Clients entwickelt wurde, empfiehlt OAuth 2.1 PKCE für vertrauliche Clients zusätzlich zur Client-Authentifizierung, da es zusätzlichen Schutz vor Autorisierungscode-Injektions- und Abfangangriffen bietet. Erfahren Sie mehr über PKCE mit Autorisierungscode-Flow.
3. Implementieren Sie Proof of Possession
Proof of Possession ist eine Methode, um die Verwendung von OAuth Access Tokens auf einen autorisierten Client (browserbasierte App) zu beschränken. Dies kann auf zwei Arten erreicht werden: mTLS-basierte Token-Bindung auf Transportebene oder DPoP-basierte Token-Bindung auf Anwendungsebene. Angesichts der Herausforderungen in Bezug auf Skalierbarkeit, Bereitstellbarkeit und Benutzerfreundlichkeit von mTLS ist der Nachweis des Besitzes (DPoP) die empfohlene Methode zur Implementierung von Proof of Possession. DPoP stellt eine bedeutende Verbesserung der OAuth 2.0-Sicherheit dar, da es Angreifer daran hindert, Token zu stehlen und wiederzugeben. Erfahren Sie mehr über OAuth 2.0 DPoP.
4. Berücksichtigen Sie Ihren Token-Lifecycle-Management-Prozess
Wenn kompromittiert, bieten langlebige Token ein größeres Zeitfenster für böswillige Aktivitäten, die zu unbefugtem Zugriff führen können. Daher empfehlen wir, Access Tokens kurze Lebensdauern zuzuweisen und sie bei Bedarf kontinuierlich zu aktualisieren.
Um die Risiken im Zusammenhang mit durchgesickerten Refresh Tokens zu mindern, sollten Sie die Rotation von Refresh Tokens in Betracht ziehen, die dazu beiträgt, den Refresh Token nach jeder Verwendung sicher zu rotieren. Das Rotieren von Refresh Tokens kann helfen, die Wiederverwendung eines Refresh Tokens zu erkennen, woraufhin der Autorisierungsserver den Refresh Token und alle seit der Authentifizierung des Benutzers ausgestellten Access Tokens ungültig machen kann. Dies schützt die Anwendung vor Token-Kompromittierung und Replay-Angriffen. Erfahren Sie mehr über die Rotation von Refresh Tokens.
Es ist auch wichtig, alle Token zu widerrufen, wenn sich ein Benutzer von einer Anwendung abmeldet. Wenn ein Token widerrufen wird, wird es sofort ungültig, wodurch eine weitere Verwendung dieses Tokens für den Zugriff auf geschützte Ressourcen verhindert wird. Der Token-Widerruf kann erfolgen, wenn der Benutzer eine Abmeldung initiiert oder wenn ein unerwartetes Ereignis eintritt, das das Risikoprofil des Benutzers erhöht. Mit der globalen Token-Widerrufung können externe Sicherheits- und Anmeldedatenanbieter anfordern, dass ein Autorisierungsserver alle vorhandenen Token eines Benutzers widerruft. Diese Aktion erfordert, dass sich der Benutzer erneut authentifiziert, bevor neue Token ausgestellt werden. Erfahren Sie mehr über die globale Token-Widerrufung und Universal Logout.
5. Wenden Sie das Prinzip der geringsten Privilegien an
OAuth/OpenID Connect-Anwendungen sollten nach dem Prinzip der geringsten Privilegien entworfen und implementiert werden, um die Sicherheit der Anwendung zu erhöhen und potenzielle Risiken zu minimieren. Anwendungsspezifische Richtlinien können genutzt werden, um sicherzustellen, dass nur die richtigen Personen von einem bestimmten Standort, Gerätetyp, Risikoprofil usw. auf eine bestimmte Anwendung zugreifen können.
OAuth Scopes können verwendet werden, um bestimmte Berechtigungen in einem Access Token zu gewähren. Scopes sollten so granular wie möglich gestaltet werden, um zu verhindern, dass Anwendungen übermäßige Berechtigungen anfordern. Für Anwendungsfälle, die einen feingranularen Zugriff erfordern, der sich dynamisch ändert, empfehlen wir, diese anhand des OAuth-Frameworks zu modellieren. Dies hilft zu verhindern, dass Token mit übermäßigen Scopes und anspruchsbezogenen Informationen überladen werden. Erfahren Sie mehr über Anmelderichtlinien für Anwendungen, Berechtigungen und feingranulare Autorisierung.
Während dieser Blog einige kritische Aspekte zur Verbesserung Ihrer Token-Sicherheit hervorhebt, hat die OAuth-Arbeitsgruppe eine umfassende Liste von Best Practices für die Sicherheit entwickelt. Überprüfen Sie die offiziellen Spezifikationen regelmäßig, um sicherzustellen, dass Ihre Anwendungen den neuesten Sicherheitstrends und Identity-Standards entsprechen.
Haben Sie Fragen zu diesem Blogbeitrag? Kontaktieren Sie uns unter eng_blogs@okta.com.
Entdecken Sie weitere aufschlussreiche Engineering-Blogs von Okta, um Ihr Wissen zu erweitern.
Sind Sie bereit, unserem leidenschaftlichen Team aussergewöhnlicher Ingenieure beizutreten? Besuchen Sie unsere Karriereseite.
Entfesseln Sie das Potenzial eines modernen und ausgeklügelten Identity Managements für Ihr Unternehmen. Kontaktieren Sie den Vertrieb für weitere Informationen.
