Ankündigungen

OAuth Security Workshop 2024 – 10.-12.04.2024, Rom, Italien

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.

Der diesjährige Workshop findet in der kommenden Woche in Rom 🇮🇹 statt. Alle Informationen zum Programm und zur Last-Minute-Registrierung finden Sie hier. Hackmanit können Sie auch vor Ort antreffen.

Single Sign-On News

OAuth 2.0 Security Best Current Practices – Auf der Zielgeraden zum RFC

Die "Security Best Current Practices" für OAuth 2.0 sind im vergangenen Quartal auf die Zielgerade des Weges zum RFC eingebogen. Nachdem die Arbeit an dem Dokument vor beinahe acht (!) Jahren begonnen hat, wurden mit dem "Shepherd Review" und "Area Director Review" zwei weitere Hürden auf dem Weg zur Veröffentlichung genommen. Neben sprachlichen Verbesserungen wurden nur Kleinigkeiten geändert; bspw. sollen Authorization Server nun "mit vertretbarem Aufwand" versuchen zu verhindern, dass Clients statische Werte als PKCE Code Challenge oder OpenID Connect "nonce" verwenden. Im letzten Schritt müssen die Autoren nun noch Feedback aus Reviews der IESG (einem leitenden Gremium der IETF) einarbeiten und zum Abschluss redaktionelle Korrekturen vornehmen. Anschließend wird die IETF das Dokument final als RFC veröffentlichen. Wenn es so weit ist und welche RFC-Nummer das Dokument erhält, erfahren Sie es in einem der nächsten Newsletter.

Auch heute sollten die in dem aktuellen Draft (#25) beschriebenen Best Practices bei der Verwendung und Implementierung von OAuth und OpenID Connect umgesetzt und eingehalten werden. Im jetzigen Stadium des Drafts sind keine (großen) inhaltlichen Änderungen mehr vor der Veröffentlichung als RFC zu erwarten.

Der Anfang vom Ende der Third-Party Cookies

Nach Firefox und Safari hat auch Google Chrome damit begonnen, Third-Party Cookies zu blockieren. Am 4. Januar hat Google für 1% der globalen Chrome Benutzer:innen Third-Party Cookies deaktiviert. Google will diesen Anteil schrittweise bis Q3 auf 100% erhöhen.

Single Sign-On Implementierungen sind von dem grundsätzlichen Blockieren von Third-Party Cookies stark betroffen. Da Client und Identity Provider üblicherweise nicht unter der gleichen Domain gehostet sind, kommen bei einem Login Third-Party Cookies zum Einsatz. Ohne Third-Party Cookies treten hierbei Probleme auf. Iframe-basierte Login Flows funktionieren beispielsweise nicht mehr. Es empfiehlt sich daher zu überprüfen, ob die eigene SSO-Implementierung betroffen ist.

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:

• OAuth 2.0 for Browser-Based Apps: Nachdem im letzten Quartal von 2023 eine große Überarbeitung des Drafts veröffentlicht wurde, sind die Änderungen in diesem Quartal kleiner ausgefallen. So enthält die neueste Draft Version (#17) unter anderem weitere Empfehlungen zu CORS, Schutzmaßnahmen gegen CSRF-Angriffe und der Sicherheit von Flows, die In-Browser Kommunikation (z. B. postMessage-API) verwenden.
  
  
• OAuth 2.0 Web Message Response Mode for Popup- and Iframe-based Authorization Flows: Im Rahmen der ersten Version unseres individuellen Drafts wurde diskutiert, wo die Unterschiede und Gemeinsamkeiten zu dem älteren Draft "OAuth 2.0 Web Message Response Mode" liegen. Wir von Hackmanit versuchen, unseren Draft über weiteres Feedback zu verbessern  und voranzutreiben. Wir erhoffen uns eine einheitliche und sichere Lösung, um die Authorization Response mit Code und/oder Tokens über die postMessage-API innerhalb von Browser-Fenstern zu übertragen. Dies ist z. B. sehr relevant beim Einsatz von OAuth/OIDC in Single-Page Applications (SPAs).
  
  
• Selective Disclosure for JWTs (SD-JWT): Bei unverschlüsselten JWTs kann ein Empfänger alle Claims lesen. Enthält ein JWT persönliche Daten des Besitzers, ist es nicht wünschenswert, alle Claims zu teilen, wenn diese für den speziellen Einsatzzweck nicht benötigt werden. Mittels SD-JWTs können einzelne Claims in einem Token "versteckt" werden, so dass der Besitzer entscheiden kann, welche Claims dem Empfänger offengelegt werden. Diese Möglichkeit hat keinen Einfluss auf den Schutz vor Manipulationen durch die Signatur des Tokens. Von dem Draft zu SD-JWTs wurden mehrere neue Versionen veröffentlicht. Ebenfalls sind neue Versionen des darauf aufbauenden Drafts zu "SD-JWT-based Verifiable Credentials (SD-JWT VC)" erschienen.

Fragen, Ausblick und Diskussionen

• In einem weiteren Thread wurde die Frage diskutiert, wie der "scope" Parameter im Kontext von Refresh Tokens zu behandeln ist. Nach dem Klären unterschiedlicher Interpretationen der Standards ergab sich das Fazit: Mit einem Refresh Token kann ein Access Token mit weniger Scopes, als ursprünglich genehmigt wurden, ausgestellt werden. Hierbei wird der Scope des Refresh Tokens selbst jedoch nicht verändert, so dass, solange das Refresh Token gültig ist, neue Access Tokens mit den ursprünglich genehmigten Scopes ausgestellt werden können. Auch beim Einsatz von Refresh Token Rotation verändern sich die Scopes des neuen Refresh Tokens nicht.
  
  
• Eine kurze Diskussion behandelte die Frage, wie die Grundlage, auf dessen ein JWT Access Token ausgestellt wurde, in das Token selbst geschrieben werden kann. Als Lösung wurde auf den "acr" Claim verwiesen. Dieser Claim ist definiert als Referenz für die "Authentication Context Class", zu der die Authentifizierung im Rahmen des Flows gezählt werden kann.
  
  
• Eine Frage auf der OAuth Mailinglist (Archiv, Registrierung) hat sich damit beschäftigt, wie der Wert des "x5t#S256" Parameters kryptografisch korrekt berechnet wird und welche Kodierung dabei verwendet werden muss.
  
  
• Eine lebhafte Diskussion ist zu dem individuellen Draft "OAuth Status Attestations" entstanden. Es wurde unter anderem die Definition verschiedener Begrifflichkeiten wie "Attestation" und "(digital/verifiable) Proof" diskutiert. Es hat sich herausgestellt, dass zwischen verschiedenen Gremien und Standards Uneinigkeit zu herrschen scheint und keine einheitlichen Definitionen existieren.
  
  
• Für den Draft "OAuth 2.0 Protected Resource Metadata", der ein Format für Metadaten von OAuth Ressourcen definiert, wurde der WGLC* gestartet. Nach Abschluss des WGLC wird der Draft in die nächste Phase auf dem Weg zum RFC übergehen. 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 12. April haben sie dafür noch Zeit.

*  "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.

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