Ankündigungen

OAuth Security Workshop 2025 – 26.-28.02.2025, Reykjavik, Island

Der nächste Workshop wurde für Februar 2025 angekündigt und findet dieses Mal in Reykjavik 🇮🇸 statt. Bis zum 24.11.2024 oder 12.01.2025 können Interessierte Talks/Session/Tutorial etc. einreichen und so das Programm mitgestalten. Details hierzu sowie alle weiteren Informationen zum OSW 2025 finden Sie hier.

Auf dem jährlichen "OAuth Security Workshop" treffen sich Expert:innen aus der Industrie, den Arbeitsgruppen, in denen Standards geschrieben werden, sowie dem akademischen Umfeld. Ziel ist es, die Sicherheit von OAuth, OpenID Connect und verwandten Protokollen zu stärken, Erfahrungen aus dem Einsatz und der Entwicklung der Standards auszutauschen und die zukünftige Entwicklung neuer Standards voranzutreiben.

Single Sign-On News

Update: Kein Ende von Third-Party Cookies in Chrome in Sicht?

Zu Beginn des Jahres hat Google damit begonnen Third-Party Cookies für 1% der globalen Chrome Benutzer:innen zu deaktivieren. Bis Q3 sollte der Prozentsatz stetig bis auf 100% erhöht werden (siehe Hackletter Q1/2024). Dies hätte für Iframe-basierte Single Sign-On Flows Probleme bedeutet. In der letzten Ausgabe des Hackletters berichteten wir von Googles angepasstem Zeitplan. Dieser sah vor bis Ende 2024 bei 1% zu verweilen und erst ab 2025 den Prozentsatz schrittweise zu erhöhen bis Third-Party Cookies vollständig deaktiviert sind. Ende Juli folgte nun die gänzliche Abkehr von dem ursprünglichen Plan, Third-Party Cookies vollständig in Chrome zu deaktivieren. Google gab seinen neuen Plan bekannt, dass Benutzer:innen selber eine "informierte Entscheidung" treffen sollen, ob Third-Party Cookies in ihrem Browser deaktiviert werden. Begründet wird dieser Rückzug vom "Ende der Third-Party Cookies" mit anhaltenden Bedenken der Aufsichtsbehörden und Feedback zu "Herausforderungen" der Werbebranche. Der neue Plan soll ebenfalls mit Einbezug von Feedback und unter Absprache mit den Aufsichtsbehörden umgesetzt werden.

Draft Updates

Im vergangenen Quartal wurden eine Vielzahl neuer Drafts oder Draft Versionen in der Sphäre von OAuth veröffentlicht. Unter anderem die Folgenden:

• Den wahrscheinlich größten Fortschritt auf dem Weg zum RFC hat es im vergangenen Quartal bei dem Draft "OAuth 2.0 Protected Resource Metadata" gegeben. Nachdem in Q2 der WGLC* für den Draft erfolgreich abgeschlossen wurde, folgten in Q3 Reviews der IESG (einem leitenden Gremium der IETF). Es wurde begonnen, dieses Feedback einzuarbeiten; insgesamt wurden in Q3 fünf neue Versionen des Drafts veröffentlicht. Unter anderem wurde die Liste der Metadaten-Felder, die der Draft definiert, um Felder für die Unterstützung von mTLS und DPoP erweitert. Es ist davon auszugehen, dass die letzten offenen Punkte aus dem Feedback der IESG in Q4 geklärt werden und der Inhalt des Drafts dann (bis auf redaktionelle Details) final ist.
  
  
• Der Draft zu SD-JWT ("Selective Disclosure for JWTs") wurde in Q3 in drei neuen Versionen aktualisiert. Unter anderem wurden Erklärungen zu "recursive Disclosures" und den Risiken im Rahmen von "Unlinkability" zwischen Ausstellern und Verifizieren von SD-JWTs hinzugefügt. Außerdem wurden die in dem Draft enthaltenen Beispiele durch zusätzlichen Kontext verbessert. Auf Basis der zuletzt veröffentlichten Draft Version #12 wurde bis zum 17. September der WGLC* gestartet. Im Zuge des WGLC sind einige längere Diskussionen entstanden, die wahrscheinlich auch nach Erscheinen dieses Hackletters weitergeführt werden. Unter anderem wird erneut das Thema Unlinkability sowie der grundsätzliche Aufbau der SD-JWTs diskutiert. Es bleibt abzuwarten, ob die Diskussionen zu weiteren (substanziellen) Änderungen an dem Draft führen.
  
  
• Zusätzlich wurden auch zwei neue Versionen für den verwandten Draft zu SD-JWT VC ("SD-JWT-based Verifiable Credentials") veröffentlicht. Diese erweitern den Draft um die Definition von Metadaten zum Typ eines VC und der entsprechenden Darstellung, und verbessern/erweitern die erläuternden Beispiele.

*  "Working Group Last Call" bezeichnet den letzten Aufruf für Interessierte den Draft einem Review zu unterziehen und ihre Kommentare und Anmerkungen zu geben. Nach Abschluss eines "WGLC" geht ein Draft üblicherweise in die nächste Phase auf dem Weg zum RFC über.

Fragen, Ausblick und Diskussionen

• In der letzten Ausgabe des Hackletters hatten wir von dem "Call for Adoption" für den "individual Draft"* "Proof of Issuer Key Authority (PIKA)", der ohne eindeutig Ergebnis geendet hat, berichtet. Im September wurde ein erneuter Call for Adoption gestartet. Auch dieses Mal wurden unterschiedliche Meinungen geteilt. Während einige Personen die Adoption durch die OAuth Working Group unterstützen, kritisieren Andere, dass die Bedenken aus dem ersten Call for Adoption nicht ausreichend adressiert wurden. Weiterhin wird als diskussionswürdig gesehen, ob TLS-Zertifikate für einen weiteren Zweck, wie PIKA, wiederverwendet werden sollten, ob dies nicht sogar im Konflikt mit Policies von CAs steht und ob PIKA in der Praxis überhaupt umsetzbar ist. Wie bei dem ersten Call for Adoption ist nicht abzusehen, wie es mit dem Draft weitergeht und ob er von der OAuth Working Group adoptiert und weiterentwickelt wird.
  
  
• Im September hat auch für den "individual Draft"* "OAuth 2.0 for First-Party Applications" der Call for Adoption stattgefunden. Der Draft definiert einen neuen Endpoint, der es einem First-Party Client erlaubt, einen alternativen OAuth Flow ohne Weiterleitungen in einem Browser durchzuführen. Ziel soll es sein, für native und mobile Applikationen eine bessere Nutzbarkeit zu erreichen, als es mit Flows, wie dem Code Flow, der Fall ist. Der Draft weist daraufhin, dass Flows, wie der Code Flow, allgemein bevorzugt werden sollten und der neue Flow nur dann verwendet werden soll, wenn ein "hohes" Level an Vertrauen zwischen dem Authorization Server und dem Client besteht – wie es bei First-Party Applikationen der Fall ist. Im Call for Adoption haben einige Personen ihre Unterstützung gezeigt und angemerkt, dass der Draft eine standardisierte Lösung bietet für etwas, das First-Party Apps bereits in proprietären Verfahren einsetzen. Auf der anderen Seite werfen Personen die Frage auf, ob der beschriebene Flow nicht dem "Resource Owner Password Credentials Grant" (ROPCG) ähnelt, dessen Einsatz (aus gutem Grund) in den OAuth 2.0 Security Best Current Practice verboten wird. Der neue Flow könnte die gleichen Schwachstellen bieten wie der ROPCG. Außerdem wird in Frage gestellt, wie dafür Sorge getragen werden kann, dass der neue Flow nur von First-Party Apps verwendet wird. Wie bei PIKA ist auch hier noch nicht abschließend klar, ob der Draft im Namen der OAuth Working Group weiterentwickelt wird oder ein "individual Draft" bleibt.
  
  
• Anfang des Quartals wurde von einer Person auf ein Sicherheitsproblem mit dem Handling des state-Parameters aufmerksam gemacht. Einige Clients verwenden den Wert des state-Parameters für eine (interne) Weiterleitung nach Abschluss des OAuth/OpenID Connect Flows. Diese Weiterleitung kann von einer angreifenden Person verwendet werden, um ein Opfer von dem Client auf eine bösartige Webseite weiterleiten zu lassen – eine sogenannte "Open Redirect"-Schwachstelle. Hierbei handelt es sich nicht um ein neues Problem. Als Beispiel wurde in dem Thread von zwei Clients gesprochen, die Google als Authorization Server verwenden und den Wert des state-Parameters ungeprüft für die Weiterleitung in den Location-Header einfügen. Die beteiligten Experten in dem Thread waren sich einig, dass dies keine Schwachstelle auf Seiten des Authorization Servers ist. Die Validierung des state-Parameters liegt in der Verantwortung des Clients. Dieser muss den Wert bei Erhalt mit dem erwarteten Wert abgleichen und muss sicherstellen, dass es zu keinem Open Redirect kommt.
  Dennoch können auch Authorization Server anfällig für Open Redirect-Schwachstellen sein, wenn die Validierung der Redirect URI fehlerhaft ist. So eine Schwachstelle konnte beispielsweise vor Kurzem von Hackmanit in "Keycloak" identifiziert werden (CVE-2024-8883).
  
  
• Eine Frage zum Einsatz von "Refresh Token Rotation" kam auf. Hintergrund war, ob der Einsatz von Refresh Token Rotation abhängig vom verwendeten Grant Type (z. B. Authorization Code oder Refresh Token) und der Struktur der Tokens (JWTs oder zufällige Strings) ist. Die Antworten mehrerer Mitglieder der OAuth Working Group stimmten übereinander ein, dass der Einsatz von Refresh Token Rotation weder von dem verwendeten Grant Type, noch der Struktur der Tokens abhängt. Es obliegt dem Authorization Server zu entscheiden, ob Refresh Token Rotation eingesetzt wird – global für alle Clients oder individuell für bestimmte Clients.
  "Refresh Token Rotation" beschreibt das Ausstellen eines neues Refresh Tokens zusammen mit dem neuen Access Token, wenn ein Client ein Refresh Token bei dem Authorization Server einlöst.
  
  
• Kurz diskutiert wurde ein neuer "individual Draft"*. Dieser Draft ("OAuth Client ID Metadata Document") definiert einen Mechanismus mit Hilfe dessen ein Client sich gegenüber Authorization Servern identifizieren kann – ohne vorherige (dynamische oder manuelle) Registrierung. Erreicht wird dies indem der Client unter einer URL Metadaten bereitstellt und diese URL in dem client_id-Parameter an den Authorization Server sendet.
  
  

* Die meisten Drafts beginnen als "individual Draft". Das bedeutet, sie werden von den Autoren veröffentlicht und bearbeitet, ohne eine Verbindung zu einer Working Group zu haben. Individual Drafts können von einer Working Group "adoptiert" werden ("Call for Adoption") und anschließend im Namen der Working Group weiterbearbeitet und später als RFC veröffentlicht werden.

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