Single Sign-On News

RFC 9700 veröffentlicht: Best Current Practice for OAuth 2.0 Security 🎉

Der wahrscheinlich wichtigste Draft im OAuth-Universum ist fertig und wurde am 30.01.25 als RFC 9700 final veröffentlicht. Die Arbeit an dem Dokument hat im November 2016 (!) ihren Anfang. Seitdem wurde das Dokument stetig um Schutzmaßnahmen gegen neu entdeckte Bedrohungen erweitert. Im Juni letzten Jahres wurde dann Draft 29 von der IESG (einem leitenden Gremium der IETF) als “fertig” akzeptiert und anschließend redaktionell fertiggestellt (siehe “Draft Updates” in Hackletter Q2/24).

RFC 9700 enthält, wie der Name vermuten lässt, eine Reihe von Vorgaben und Empfehlungen für den sicheren Einsatz von OAuth 2.0. Beispielsweise rät der RFC strikt vom Einsatz des OAuth “Implicit Grants” ab, verbietet den “Resource Owner Password Credentials Grant”, und schreibt den Einsatz der PKCE-Erweiterung für Public Clients* vor. Jede Implementierung von OAuth und OpenID Connect sollte grundsätzlich die definierten Best Current Practices einhalten, um Schwachstellen zu vermeiden und einen sicheren Betrieb zu ermöglichen. Wie in der letzten Ausgabe des Hackletters erläutert, werden die Best Current Practices aus RFC 9700 nativ in der zukünftige Version OAuth 2.1 enthalten sein, so dass vereinfacht gesagt gilt:
OAuth 2.0 + RFC 9700 = OAuth 2.1
Das bedeutet für heute existierende oder geplante Implementierungen: Wird RFC 9700 umgesetzt und eingehalten, wie es beispielsweise in unseren SSO-Schulungen besprochen wird, ist die Implementierung (weitestgehend) kompatibel zu OAuth 2.1.

Interessante Randnotiz: Zusammen mit RFC 9700 wurde unter RFC 9701 “JSON Web Token (JWT) Response for OAuth Token Introspection” veröffentlicht. Dieser RFC definiert, dass die Antwort der “OAuth 2.0 Token Introspection” (RFC 7662), die Informationen über die Gültigkeit eines Access oder Refresh Tokens enthält, in Form eines signierten JWTs ausgestellt wird. Der Empfänger kann sich somit sicher sein, dass die Informationen in der Antwort von dem Authorization Server stammen und nicht manipuliert wurden. Obwohl die RFCs inhaltlich nicht direkt zusammenhängen und RFC 9701 seit 2021 auch redaktionell abgeschlossen war, konnte der RFC nicht veröffentlicht werden, bevor RFC 9700 veröffentlicht wurde. Der Grund hierfür war, dass RFC 9701 eine einzige “normative” Referenz auf RFC 9700 enthält. Normative Referenzen in einem RFC dürfen ausschließlich auf final veröffentlichte Dokumente und nicht auf Drafts verweisen, so dass die Veröffentlichung von RFC 9701 erst nach (bzw. zusammen mit) RFC 9700 geschehen konnte.

Zukünftige Änderungen an “private_key_jwt” aufgrund möglicher Schwachstellen

OpenID Connect spezifiziert als Alternative zu Client ID und Client Secret den Mechanismus “private_key_jwt” zur Client-Authentifizierung. Hierbei signiert der Client ein JWT mit seinem Private-Key und sendet dieses JWT an den Identity Provider (IdP). Dem IdP wird der Public-Key des Clients im Rahmen der Client Registrierung mitgeteilt, so dass der IdP die Signatur des JWTs verifizieren kann. OIDC verweist auf RFC 7523, der einen ähnlichen Mechanismus über JWTs, die als “client_assertion” zur Client-Authentifizierung gesendet werden, definiert.

In diesem Mechanismus wurden nun mögliche Schwachstellen entdeckt, die von angreifenden Personen ausgenutzt werden könnten, um unberechtigt in den Besitz von Tokens zu gelangen. Die Details zu diesen Schwachstellen sind noch nicht vollständig publiziert worden, da zunächst an Gegenmaßnahmen gearbeitet werden soll. Betroffen können wohl Szenarien sein, in denen mehrere IdPs verwendet werden. Um die Schwachstellen zu adressieren, soll nach aktuellem Stand eine neue Version von RFC 7523 erscheinen, die bis jetzt nur in sehr frühem Stadium vorliegt (rfc7523bis). Der Draft sieht vor, dass genau spezifiziert wird, wie der Wert des in den JWTs enthaltenen “aud”-Claims gesetzt werden soll. Betroffen sind hiervon nicht nur OIDC und RFC 7523, sondern auch andere Standards, die diese Art der Client-Authentifizierung einsetzen (z. B. PAR und JAR, sowie FAPI 1.0 und 2.0). Mit rfc7523bis sollen auch die weiteren betroffenen IETF-Dokumente aktualisiert werden. Es ist davon auszugehen, dass Libraries und Frameworks, die “private_key_jwt” implementieren, Updates erhalten, um die möglichen Schwachstellen zu beheben. In Szenarien, bei denen statt der Client-Authentifizierung mittels ID und Secret heute JWTs zum Einsatz kommen, sollte erhöhte Vorsicht gelten und ggfs. eine eigenständige Analyse der Sicherheit angestrebt werden.

* Bei ”Public Clients” handelt es sich um Clients, die ihr Client Secret nicht sicher speichern können. Trotz des Namens Client Secret, muss bei diesen Clients davon ausgegangen werden, dass das Client Secret öffentlich bekannt ist. Somit kann ein Public Client nicht sicher authentifiziert werden. Dies hat zur Folge, dass Authorization Codes und Refresh Tokens, welche für den Public Client ausgestellt wurden, von jedem eingelöst werden können. Beispiele für Public Clients sind native Anwendungen, die auf dem Endgerät der benutzenden Person installiert sind oder SPAs, die im Browser der benutzenden Person ausgeführt werden. Client-Anwendungen, die auf einem Backend-Server ausgeführt werden, hingegen werden als “Confidential Clients” bezeichnet und erreichen ein höheres Sicherheitsniveau, weil sie ihr Client Secret, sowie die Tokens sicher speichern können.

Draft Updates

Im vergangenen Quartal wurden eine Vielzahl neuer Drafts oder Draft Versionen rund um das Thema OAuth veröffentlicht. Unter anderem die Folgenden:

• Einen weiteren Schritt zum finalen RFC hat der Draft “OAuth 2.0 for Browser-Based Applications”, der Best Practices für den Einsatz von OAuth bei SPAs definiert, im ersten Quartal 2025 genommen. Nachdem die OAuth Working Group die Bearbeitung des Drafts als abgeschlossen angesehen hat, wurde er von der IESG einem weiteren Review unterzogen. Hierbei wurden Kritikpunkte angemerkt, dessen Umsetzung in drei neuen Draft-Versionen resultiert hat. So wurde ein Abschnitt hinzugefügt, der beschreibt wie bei dem Einsatz der “BFF-Architektur”* die Proxy-Funktionalität des BFFs beschränkt sein muss. Kommt es bei der Implementierung zu Fehlern, kann dies von einer angreifenden Person ausgenutzt werden, um das Access Token aus dem BFF zu stehlen. Des Weiteren wurden an einigen Stellen weiterführende Erläuterungen hinzugefügt, um den Draft verständlicher für eine breitere Zielgruppe zu machen und weniger Kenntnisse von Web- und Browser-Sicherheitsmechanismen vorauszusetzen. Im kommenden Quartal wird voraussichtlich letztes Feedback eingearbeitet werden und eine Veröffentlichung als finaler RFC könnte ebenfalls im nächsten oder übernächsten Quartal erfolgen.
  
  
• Der Draft zu SD-JWT (“Selective Disclosure for JWTs”) in der aktuellsten Version 17 wird von der OAuth Working Group als fertig angesehen und wurde zum finalen Review an die IESG weitergeleitet. Zuvor wurden in Q1 drei neue Versionen des Drafts veröffentlicht, die neben kleinen redaktionellen/sprachlichen Änderungen u. A. den Abschnitt “Privacy Considerations” erweitern. Insbesondere dieser Abschnitt war zuvor von einzelnen Personen der OAuth Working Group kontrovers diskutiert worden.
  
  
• Für den Draft “Token Status List” wurde zu Beginn des Jahres der “Working Group Last Call” (WGLC) gestartet. Hierbei wird die Working Group aufgefordert, letztes Feedback zu geben, bevor ein Draft in die nächste Phase auf dem Weg zum RFC übergeht. Diesem Aufruf sind einige Personen gefolgt. Zudem wurde später ein “Interim”-Meeting der OAuth Working Group abgehalten, um diesen Draft zu diskutieren. Der Draft definiert einen Mechanismus zur Abbildung des Status von Tokens, die mittels JOSE oder COSE abgesichert sind (z. B. JWTs). Insgesamt wurden vier Draft Versionen veröffentlicht, um das Feedback nach und nach zu adressieren. Basierend auf Draft Version 10 wurde daraufhin ein zweiter WGLC gestartet. Interessierte sollten diese letzte Chance nutzen, um den Draft einem Review zu unterziehen und ihre Kommentare und Anmerkungen auf der OAuth Mailinglist zu teilen; bis zum 07. April haben sie dafür noch Zeit. Neben den genannten Änderungen wurde auch diskutiert, ob der Draft eine Erweiterung für X.509 Zertifikate definieren sollte. Dies würde erlauben, die Status Lists auch für die Revocation von X.509 Zertifikaten verwenden zu können. Nach Diskussionen wurde dieser Vorschlag von der Mehrheit jedoch abgelehnt, u. A. weil die beteiligten Personen die OAuth Working Group für den falschen Ort für die Standardisierung von Erweiterungen für X.509-Zertifikate sehen.
  
  

* Bei der BFF-Architektur (“Backend For Frontend”) handelt es sich um die sicherste (und daher empfohlene) Architektur für SPAs, die OAuth einsetzen. Das Frontend stellt keine Requests direkt an die Ressource (z. B. eine API), sondern verfügt über einen dynamischen Backend-Server, der als Proxy agiert. Dies erlaubt es, die Access Tokens sicher auf dem Backend-Server, statt in dem Frontend im Browser zu speichern. Für die Kommunikation des Frontends mit seinem Backend wird ein Cookie verwendet. Da der OAuth-Client bei dieser Architektur der Backend-Server und nicht das Frontend der SPA ist, handelt es sich um einen Confidential Client. “Klassische” SPAs, die komplett im Browser agieren, hingegen sind Public Clients und erreichen damit ein niedrigeres Sicherheitsniveau.

Fragen, Ausblick und Diskussionen

• Für die zukünftige neue Version von OAuth – OAuth 2.1 – wurden von einer Person einige inhaltliche Änderungsvorschläge gemacht. Diese Vorschläge in OAuth 2.1 umzusetzen wurde jedoch direkt abgelehnt. Hintergrund ist, dass OAuth 2.1 selbst keine Neuerungen definieren soll, sondern “lediglich” OAuth 2.0 mit Ergänzungen und Verbesserungen aus anderen RFCs in einem einzelnen Standard kombinieren soll. Dies dient dazu, die Übersichtlichkeit zu erhöhen und den Einstieg in OAuth zu erleichtern. Der Person wurde nahegelegt die Änderungsvorschläge unabhängig von OAuth 2.1 zu diskutieren und ggfs. einen eigenen Draft zu erstellen, in dem die Änderungen definiert werden. Würde dieser Draft dann von der OAuth Working Group angenommen und finalisiert, könnten die Änderungen potenziell auch in OAuth 2.1 übernommen werden.
  
  
• Ein Vorschlag, der auf der OAuth-Mailingliste diskutiert wurde, sieht es vor als User Identifier im OAuth-Kontext “DNS Handles” (z. B. @user.server.example) zu verwenden, so wie sie bspw. Bluesky einsetzt. Dem Vorschlag bringen einige Personen entgegen, dass es zuvor ähnliche Bestrebungen mit ID4me (Penetrationstest von “DENIC ID”, die auf ID4me basiert) gab, die sich nicht durchsetzen konnten. Von dem Initiator wurde im Anschluss ein Individual Draft zu DNS Handles veröffentlicht. Darauf gab es bis jetzt keine weiteren Antworten.
  
  
• Cloudflare hat im März “OpenPubkey SSH” (OPKSSH) veröffentlicht. In einem Blogpost beschreiben sie, wie mithilfe von OpenID Connect ein Login per SSH auf Servern ermöglicht wird. Hierzu müssen sich Nutzende bei Ihrem SSO Anbieter authentifizieren. Anschließend stellt dieser ihnen ein “PK Token” aus, der die Identität und den temporären öffentlichen SSH Schlüssel enthält. Laut dem Blogpost erfordert die Integration von OPKSSH lediglich einen Download und die Anpassung von zwei Zeilen in der Konfigurationsdatei des SSH-Servers. Eine alternative Lösung für SSH-Zugriff mittels OpenID Connect ist die von WAYF entwickelte “SSHCA”, zu der Hackmanit vor kurzem eine Sicherheitsanalyse veröffentlicht hat.
  
  

Immer informiert – Abonnieren Sie jetzt den Hackletter!

Melden Sie sich noch heute für den Hackletter an und verpassen Sie keine spannenden Ausgaben.
Erhalten Sie exklusive Insights zu neuesten Entwicklungen und Updates rund um Single Sign-On einmal
im Quartal direkt in Ihr Postfach. 

>> Anmeldung zum Hackletter

Unsere Experten entwickeln die optimale Lösung für Sie

Single Sign-On – OAuth – FAPI

Stehen Sie vor der Entscheidung, wie Sie Ihr IAM-Szenario und Ihre Kundendaten optimal schützen können? Oder verwenden Sie OAuth/OpenID Connect bereits und fragen sich, ob Ihre Single Sign-On Implementierung sicher ist?

Wir beraten Sie gerne; kontaktieren Sie uns für eine unverbindliche Erstberatung. So stehen wir Ihnen mit folgenden Services und Lösungen zur Seite:

IT-Sicherheitsberatung  |  Schulungen   |  Penetrationstests

Zögern Sie nicht und finden Sie mit uns Ihren Weg zu sicherem Single Sign-On. Wir freuen uns darauf Sie bei Ihren Projekten zu unterstützen.

Ihr Ansprechpartner für Single Sign-On und sichere API

Karsten Meyer zu Selhausen
karsten.meyerzuselhausen@hackmanit.de