Ankündigungen
Erinnerung: OAuth Security Workshop 2025 – 26.-28.02.2025, Reykjavik, Island
Nächsten Monat findet der jährliche OAuth Security Workshop in Reykjavik 🇮🇸 statt. Mittlerweile wurden erste Teile des Programms veröffentlicht. 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
Zugriffe auf fremde Accounts wegen falscher Nutzung von Google-Login?
In einem kürzlich erschienenen Artikel bei heise online wird von einer Schwachstelle im Zusammenhang mit Google-Login berichtet. So ist es einer IT-Sicherheitsfirma gelungen, Domains von nicht mehr existierenden Firmen zu erwerben und über diese Domains in Drittanbieter-Accounts (z. B. Slack oder Zoom) von ehemaligen Mitarbeitenden dieser Firmen zu gelangen. Die Firmen hatten die Domains ehemals in Google Workspace verwendet und darüber Google-Login bei Drittanbietern genutzt. Die Schwachstelle liegt nun nicht auf Seiten von Google, sondern bei den Drittanbietern (“Relying Parties”). Bei dem Login mit Google als Identity Provider kommt OpenID Connect zum Einsatz*. Im Zuge des OpenID Connect Flows stellt Google der Relying Party ein ID Token aus, welches die Identität der benutzenden Person enthält. Entgegen der klaren Maßgaben in der OpenID Connect Spezifikation, welche vorschreiben für die Identifikation der benutzenden Person ausschließlich die Claims “sub” und “iss” zusammen zu verwenden, haben die Relying Parties in diesem Fall offenbar den “email” Claim verwendet. Im Gegensatz zu dem einzigartigen Wert des “sub” Claim, ist der “email” Claim jedoch identisch für einen neuen Google Account, wenn dieselbe Domain und derselbe Benutzername, wie von einem alten mittlerweile gelöschten Google Account, verwendet wird.
Die entdeckte Schwachstelle unterstreicht ein weiteres Mal die Wichtigkeit, bei der Implementierung von OAuth und OpenID Connect genau auf die Spezifikationen zu achten. Wird dies nicht gemacht, kann es trotz des Einsatzes der sicheren Protokolle zu schwerwiegenden Schwachstellen kommen. Der konkrete Fall zeigt eindrücklich, warum für die Bestimmung der Identität einer benutzenden Person ausschließlich die Claims “sub” und “iss” aus dem ID Token verwendet werden dürfen – wie es auch Hackmanit seiner Kundschaft in Schulungen und der Beratung empfiehlt.
* In dem heise Artikel wird fälschlicherweise von “OAuth-Login” geschrieben. OAuth wurde jedoch nur zur Autorisierung entwickelt. Für den Login – also die Authentifizierung – einer benutzenden Person muss hingegen das auf OAuth aufbauende OpenID Connect Protokoll verwendet werden. Bei Google-Login kommt korrekterweise OpenID Connect zum Einsatz.
Draft Updates
Im vergangenen Quartal wurden eine Vielzahl neuer Drafts oder Draft Versionen rund um das Thema OAuth veröffentlicht. Unter anderem die Folgenden:
- Für die zukünftige Version OAuth 2.1 wurde im November nach längerer Zeit eine neue Version veröffentlicht. Draft 12 nimmt kleinere Änderungen z. B. an den Formulierungen bzgl. der Client Registrierung vor. Mit OAuth 2.1 soll die (immer noch) aktuelle Version OAuth 2.0 von 2012 ersetzt werden. Dabei werden unsichere und veraltete Bestandteile (z. B. Flows) gegenüber Version 2.0 entfernt und heute etablierte Sicherheitsmechanismen (wie z. B. PKCE) in OAuth 2.1 aufgenommen. Insbesondere werden die Maßnahmen und Vorgaben, die in dem wichtigen Dokument “OAuth 2.0 Security Best Current Practice” beschrieben sind, nativ in OAuth 2.1 integriert.
Vereinfacht gesagt gilt:
OAuth 2.0 + OAuth 2.0 Security Best Current Practice = OAuth 2.1
Das bedeutet für heute existierende oder geplante Implementierungen: Werden die OAuth 2.0 Security Best Current Practice umgesetzt und eingehalten, ist die Implementierung (weitestgehend) kompatibel zu OAuth 2.1. Eine Sorge vor dem Update auf 2.1 ist daher in diesem Fall unbegründet. - Der Draft mit Best Practices für den Einsatz von OAuth in Single Page Applications (“OAuth 2.0 for Browser-Based Applications”) wurde im letzten Quartal in drei neuen Versionen überarbeitet. Während zwei dieser Versionen nur Kleinigkeiten, wie veraltete Referenzen, aktualisiert haben, wurden in Draft Version 20 die Kommentare des “Document Shepherd” aus der Leitung der OAuth Working Group adressiert. Hiermit ist das Dokument der Finalisierung einen weiteren Schritt näher gekommen. Grundlegende Änderungen wurden hierbei nicht vorgenommen; unter anderem wurden die Texte zu der “Backend For Frontend (BFF)”-Architektur um Erläuterungen erweitert. Hierbei handelt es sich um die sicherste (und damit empfohlene) Architektur für SPAs, die OAuth einsetzen. Zudem wurde die Vorgabe eingeführt, dass Authorization Server für SPAs, bei denen es sich um “Public Clients”* handelt, keine Client-Authentifizierung (z. B. mittels eines Clients Secrets) voraussetzen dürfen. Hintergrund dieser Vorgabe ist, dass bei Public Clients das Clients Secret nicht sicher gespeichert werden kann und – entgegen seines Namens – als öffentlich bekannt angenommen werden muss. Daher bietet die Verwendung eines Client Secrets in diesem Fall keinen Mehrwert und könnte stattdessen sogar zu einem falschen Eindruck des vorhandenen Sicherheitsniveaus führen.
- Nachdem im letzten Hackletter von dem großen Schritt des Drafts “OAuth 2.0 Protected Resource Metadata” auf dem Weg zum RFC berichtet wurde, ist die inhaltliche Bearbeitung des Dokuments nun abgeschlossen. Zuvor wurde Feedback der IESG (einem leitenden Gremium der IETF) in vier neuen Draft-Versionen eingearbeitet. Unter anderem wurden dabei an verschiedenen Stellen die Formulierungen überarbeitet, um eine bessere Verständlichkeit zu erreichen. Der letzte Schritt bevor dem Dokument eine RFC Nummer verliehen wird, ist nun eine redaktionelle Überarbeitung der IETF, um letzte sprachliche Details zu verbessern. Das fertige Dokument definiert ein Format für die Metadaten von Ressourcen, deren Zugriff über OAuth geschützt wird und hilft OAuth Clients oder Authorization Servern mit diesen Ressourcen zu interagieren.
- Im Oktober wurde das zuvor als individueller Draft geführte Dokument “OAuth 2.0 for First-Party Applications” von der OAuth Working Group offiziell “adoptiert”. Abgesehen von der initialen Version, welche inhaltlich identisch zu der Version des individuellen Drafts ist, wurde bis jetzt keine neue Version veröffentlicht. Wie in der letzten Ausgabe des Hackletters beschrieben definiert der Draft 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 Code Flow sollte allgemein wann immer möglich bevorzugt werden und der neue Flow nur dann verwendet werden, wenn ein “hohes” Level an Vertrauen zwischen dem Authorization Server und dem Client besteht – wie es bei First-Party-Applikationen der Fall ist.
- Der Draft zu SD-JWT VC (“SD-JWT-based Verifiable Credentials”) hat im letzten Quartal drei Updates erhalten. Insbesondere das Entfernen der Erwähnung von DIDs (“Decentralized Identifiers”) in Version 6 wurde kontrovers diskutiert und in Version 7 wieder rückgängig gemacht. Es deutet sich an, dass in der Weiterentwicklung dieses Drafts zusätzliche (kontroverse) Diskussionen entstehen werden, da innerhalb der Working Group unterschiedliche Auffassungen über den Inhalt und die Ausgestaltung des Drafts zu bestehen scheinen.
* 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.
Fragen, Ausblick und Diskussionen
- Für viele Diskussionen hat im letzten Quartal 2024 der Draft zu SD-JWT (“Selective Disclosure for JWTs”) gesorgt. Dem Aufruf im Rahmen eines zweiten “Working Group Last Call”* noch einmal einen Review des Drafts vorzunehmen und letzte Kommentare und Bedenken zu äußern, sind einige Personen auf der OAuth Mailinglist gefolgt. In drei E-Mail-Threads (#1, #2, #3) wurden die Auswirkungen des Drafts auf die Privatsphäre ausführlich diskutiert. Es wurden unterschiedliche Vorschläge gemacht, den Abschnitt “Privacy Considerations” anzupassen. Auch auf Github hat eine weitere Diskussion zu diesem Thema stattgefunden. Der finale Text für diesen Abschnitt wurde bis zum Erscheinen dieses Hackletters noch nicht gefunden. Zusätzlich hat nach dem zweiten “WGLC” die für OAuth zuständige IETF “Area Director” Anmerkungen zu dem Draft gegeben; diese kleineren Anmerkungen sollen laut Aussage der Autoren in einer bald erscheinenden neuen Draft Version umgesetzt werden.
- Für den Draft “Token Status List”, der einen Mechanismus, sowie Datenstrukturen und Verarbeitungsregeln für die Darstellung des Status von Tokens (z. B. JWT, SD-JWT VC oder CBOR Web Tokens) definiert, wurde der “Working Group Last Call”* gestartet. Bis zum Erscheinen dieses Hackletters wurden nur einzelne kleinere Punkte zur Verbesserung in dem E-Mail-Thread angemerkt. Zuvor waren im vierten Quartal drei neue Draft-Versionen erschienen, in denen das Dokument überarbeitet und erweitert wurde. Nach Abschluss des “WGLC” wird der Draft in die nächste Phase auf dem Weg zum RFC übergehen. Interessierte sollten sich beeilen, wenn sie diese letzte Chance nutzen möchten, um den Draft einem Review zu unterziehen. Bis zum 17. Januar sollten Sie Ihre Kommentare und Anmerkungen zu dem Draft auf der OAuth Mailinglist teilen.
* "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