Mit unserem "Hackletter" erhalten Sie quartalsweise News und Ankündigungen rund um Themen, Standards und Entwicklungen im Bereich Single Sign-On. Abonnieren Sie den Newsletter um keine Neuigkeiten zu Single Sign-On mehr zu verpassen.

Auf dem neuesten Stand – Die wichtigsten Single Sign-On Updates von Q2 | Hackletter Q2/2024

Auf dem neuesten Stand – Die wichtigsten Single Sign-On Updates von Q2 | Hackletter Q2/2024
Hackletter Q2/2024 Banner


Single Sign-On News

Update: Verschiebung des Endes von Third-Party Cookies in Chrome

Anders als in der letzten Ausgabe des Hackletters beschrieben, wird Google die Third-Party Cookies in Chrome nicht bis Q3 dieses Jahres vollständig deaktivieren. Bereits seit dem 4. Januar ist dies bei 1% der Benutzer:innen der Fall. Statt diesen Anteil in 2024 schrittweise zu erhöhen, soll der Anteil bis Ende 2024 bei 1% bleiben. Der neue Zeitplan sieht vor, den Anteil in 2025 schrittweise zu erhöhen, bis die Third-Party Cookies in Chrome vollständig deaktiviert sind, wie Google Ende April bekannt gegeben hat. Hintergrund dieser Verschiebung sind laut Google Feedback zu anhaltenden Herausforderungen bei der Umsetzung neuer Lösungen aus der Branche und Entwickler:innen sowie der Wettbewerbs- und Marktbehörde des Vereinigten Königreichs.

Für Provider von Single Sign-On Implementierungen bedeutet das mehr Zeit zu überprüfen, ob die eigene SSO-Implementierung betroffen ist. Third-Party Cookies kommen bei SSO zum Einsatz, insb. wenn ein seamless Login über ein Iframe umgesetzt oder das SSO Session Management implementiert wurde.


FedCM: Ein neuer Ansatz für Single Sign-On im Browser

Mit "Federated Credential Management" (FedCM) befindet sich zur Zeit eine neue Browser-API in der frühen Entwicklung, die in Chrome schon getestet werden kann. Durch den Einsatz von FedCM sollen Single Sign-On Flows im Browser ohne Techniken wie Third-Party Cookies ermöglicht werden und dabei die Privatsphäre und Sicherheit der Benutzer:innen geschützt werden.

FedCM ist im Kontext von OAuth eine sehr interessante Chance, eine sichere und datenschutzfreundliche Lösung für Single Sign-On direkt in den Browser zu integrieren. Durch diese direkte Integration können Implementierungsfehler auf ein Minimum reduziert werden. Daher besteht in der OAuth Community reges Interesse daran, zur Entwicklung und Standardisierung von FedCM mit Erfahrungen und Anforderungen aus dem Einsatz von OAuth und OpenID Connect beizutragen. Zur FedCM gab es mehrere Sessions auf dem OAuth Security Workshop, der im April in Rom stattgefunden hat. Im Mai gab es ein weiteres virtuelles Meeting der OAuth Working Group zu diesem Thema (Video, Slides) und anschließend weitergehende Diskussionen auf der Mailinglist. Die Autoren des FedCM Drafts laden Interessierte dazu ein, Feedback zu geben und zur Entwicklung von FedCM beizutragen. Es bleibt spannend zu sehen, wie sich FedCM weiterentwickelt und ob die gesteckten Ziele erreicht werden können. Im Hackletter werden wir Sie auf dem Laufenden halten!

 

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:

  • Für den zur Zeit wahrscheinlich wichtigsten Draft im OAuth-Universum – die "OAuth 2.0 Security Best Current Practice[s]" – sind im letzten Quartal gleich vier neue Versionen erschienen. Auch wenn das vermuten lässt, dass es viele Änderungen gab, ist dies nicht der Fall. In den neuen Drafts wurde nach und nach das Feedback aus Reviews der IESG (einem leitenden Gremium der IETF) eingearbeitet. Der letzte Draft (#29) wurde anschließend von der IESG akzeptiert und wird nun redaktionell fertiggestellt. Vor der finalen Veröffentlichung als RFC wird es somit lediglich kleinere sprachliche, jedoch keine inhaltlichen, Anpassungen geben. Daher sollten die im aktuellen Draft beschriebenen Best Practices bei der Verwendung und Implementierung von OAuth und OpenID Connect schon heute umgesetzt und eingehalten werden. Wie lange der Prozess bis zur Vergabe einer RFC Nummer nun dauert, lässt sich schwer abschätzen, da es sich um ein umfangreiches Dokument handelt. Wenn es so weit ist und welche RFC-Nummer das Dokument erhalten hat, erfahren Sie in einem der nächsten Newsletter.

  • An der zukünftigen Version 2.1 von OAuth wurden einige kleinere Änderungen im Rahmen einer neuen Draft Version vorgenommen. Unter anderem wurden die Voraussetzungen, in welcher Form ein Authorization Server die Client Credentials zur Client Authentifizierung akzeptieren muss bzw. kann gegenüber OAuth 2.0 angepasst: In 2.1 muss ein AS die Client Credentials als POST-Parameter akzeptieren und kann sie per HTTP Basic Authentication akzeptieren. Im OAuth 2.0 Standard ist dies noch umgekehrt: HTTP Basic Authentication muss akzeptiert werden, POST-Parameter können akzeptiert werden.

  • Am ersten Mai ist Version 18 des Drafts "OAuth 2.0 for Browser-Based Applications" erschienen. Neben kleinen sprachlichen Änderungen wurden einzelne Abschnitte in der Reihenfolge getauscht, um die Lesbarkeit des Dokumentes zu verbessern. Inhaltlich wurden Details zu der Implementierung und den Auswirkungen auf die Privatsphäre der User beim Einsatz der "Backend For Frontend" (BFF) Architektur hinzugefügt.

  • Zum Ende des ersten Quartals wurde für den Draft "OAuth 2.0 Protected Resource Metadata", der ein Format für die Metadaten von OAuth Ressourcen definiert, der "Working Group Last Call" gestartet. Hierbei sollte letztes Feedback von der OAuth Working Group gesammelt werden, bevor das Dokument in die nächste Phase des Standardisierungsprozesses eintritt. Im April wurden über die Mailinglist einige Vorschläge zur Verbesserung gemacht und anschließend in zwei neuen Draft Versionen umgesetzt. U. a. wurde ein Diagramm hinzugefügt, um den Protokollablauf leichter verständlich zu machen. Im Mai wurde dann ein zweiter "Working Group Last Call" gestartet, woraufhin es keine weiteren Anmerkungen mehr gab; somit ist der Draft aus Sicht der Working Group "fertig" und wartet nun auf Reviews anderer Gremien innerhalb der IETF.

  • Auch für den Draft "Cross-Device Flows: Security Best Current Practice" gab es im letzten Quartal den "Working Group Last Call". Anschließend wurde eine neue Draft Version veröffentlicht, in der durch kleinere Anpassungen (u. A. zu FIDO) das Feedback umgesetzt wurde. Der Draft beschreibt Bedrohungen und entsprechende Gegenmaßnahmen für Cross-Device Flows. Gemeint sind damit Flows, die über mehrere Geräte hinweg ablaufen: Eine Person initiiert den Flow auf einem Gerät (z. B. Smart TV) und führt die Autorisierung bzw. Authentifizierung anschließend auf einem anderen Gerät, dem sie persönlich vertraut, durch (z. B. Smartphone). Beispiele für Cross-Device Flows sind der "OAuth 2.0 Device Authorization Grant" oder der "OpenID Connect Client-Initiated Backchannel Authentication Flow". Auch hier gilt nun: Aus Sicht der Working Group ist der Draft "fertig" und wartet nun auf Reviews anderer Gremien innerhalb der IETF.

 

Fragen, Ausblick und Diskussionen

  • Für den "individual Draft"* "Proof of Issuer Key Authority (PIKA)" wurde im Juni ein "Call for Adoption" auf der OAuth Mailinglist gestartet. PIKA soll es ermöglichen, offline zu validieren, ob ein Public Key vertrauenswürdig ist. Dies soll als Alternative zum Abrufen des Public Keys über HTTPS bei dem Eigentümer sein und könnte bspw. bei der Validierung eines JWT zum Einsatz kommen. In der Diskussion wurde von verschiedenen Mitgliedern der OAuth Working Group grundsätzliches Interesse an dem Draft gezeigt. Allerdings wurden auch viele Fragen über den Umfang des Drafts, die beschriebene Methodik und die Beziehung zu bestehenden Standards aufgeworfen. Bis zum Ablauf des "Call for Adoption" am 24. Juni konnte kein eindeutiges Ergebnis gefunden werden, ob der Draft von der Working Group in der aktuellen Form "adoptiert" wird.

  • Auf der Mailinglist wurde ein weiterer "individual Draft" * mit dem Titel "OAuth Profile for Open Public Clients" vorgestellt und diskutiert. Dieser Draft stammt aus dem Umfeld von E-Mail-Providern, soll aber allgemein Interoperabilität zwischen Clients und Servern ermöglichen, die Protokolle wie  JMAP, IMAP, SMTP, POP, CalDAV oder CardDAV verwenden.

  • Über den "Tellerrand" der OAuth Working Group hinausgeschaut, wurde auf der Mailinglist ein Vorschlag dazu diskutiert, ein IETF "Internet Terminology Glossary" zu erstellen. Somit würde eine zentrale Anlaufstelle für Begriffe geschaffen, die in verschiedenen Dokumenten innerhalb der IETF definiert wurden. Diese Idee befindet sich aktuell noch in einem frühen Stadium und die Zukunft wird zeigen, ob mehr daraus wird.

* 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