OAuth-Entwicklungen im Fokus: Neue Drafts und spannende Diskussionen

Von finalisierten Drafts über kontroverse Diskussionen bis hin zu neuen Konzepten für KI-Agents: Hier finden Sie einen Überblick über die spannendsten Entwicklungen des letzten Quartals.

Single Sign-On News

Whitepaper veröffentlicht: “Identity Management for Agentic AI”

Die voranschreitende Verbreitung von KI macht auch vor dem OAuth- und OpenID Connect-Universum nicht halt. Die OpenID Foundation (von der der OpenID Connect-Standard stammt) hat kurz vor “Redaktionsschluss” des Hackletters ein Whitepaper veröffentlicht, das sich mit Autorisierung und Authentifizierung im Kontext von “AI Agents” beschäftigt. “AI Agents” werden dabei als KI-basierte Systeme definiert, die autonom Aktionen ausführen, um damit bestimmte Ziele zu erreichen. In dem Whitepaper werden zum einen bereits verfügbare Lösungen für die Autorisierung und Authentifizierung in heute bereits existierenden “simplen” Szenarien im AI Agent-Kontext beschrieben. Zum anderen richtet das Whitepaper einen Blick auf Probleme bzgl. Autorisierung und Authentifizierung zukünftiger AI Agent-Generationen und Strategien, wie passende Lösungen für diese erarbeitet werden können.

Die OpenID Foundation endet mit einem Call-to-Action an Entwickler:innen, Architekt:innen, Standard-Gremien und Unternehmen zusammenzuarbeiten, um zügig Lösungen für die sich rasant-entwickelnde Welt der AI Agents zu entwickeln.

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:

• Der Draft “OAuth 2.0 for Browser-Based Applications”, in dem Best Practices beim Einsatz von OAuth in Single-Page-Applications (SPAs) zusammengestellt sind, steht nun kurz vor der fertigen Veröffentlichung. Nachdem die Autor:innen mit Draft #25 das Feedback der IESG (einem leitenden Gremium der IETF) eingearbeitet hatten, wurde der Draft im Juli von der IESG akzeptiert. Der Draft ist somit inhaltlich final und befindet sich in einem abschließenden redaktionellen Prozess durch den “RFC Editor", bevor er mit einer RFC Nummer veröffentlicht wird.
  
  
• “Selective Disclosure for JWTs (SD-JWT)”, die es ermöglichen, alle Claims innerhalb eines JWTs geheim zu halten und nur ausgewählte zu offenbaren, befinden sich seit Q2 in der finalen redaktionellen Überarbeitung. Der Draft “SD-JWT-based Verifiable Credentials (SD-JWT VC)”, der daran anknüpft und das Format für “Verifiable Credentials” verwendet, hat in Q3 die zwei neuen Draft-Versionen #10 und #11 erhalten. Hierbei wurde u. a. ein Mechanismus zur Verifikation des Keys, mit dem das JWT signiert wurde, entfernt. Das Entfernen dieses Mechanismus, der auf “Decentralized Identifiers (DIDs)” basierte, war bereits bei früheren Drafts ein Thema von kontroversen Diskussionen. Die Entscheidung nach erneuter Diskussion stützt sich nun darauf, dass die Definition des DID-Mechanismus in einer Erweiterung detaillierter erfolgen soll.
  
  
• Ein Draft, der es bis jetzt nicht in den Hackletter geschafft hatte, “OAuth Identity and Authorization Chaining Across Domains”, wurde in Q3 mit zwei Versionen aktualisiert. In dem Draft wird ein Mechanismus beschrieben, wie Informationen zur Identität und Autorisierung über verschiedene “Trust Domains” hinweg erhalten bleiben und verwendet werden können. Bspw. kann so ein Client, der bei Authorization Server A registriert ist (Trust Domain A), auf eine Ressource zugreifen, deren Zugriff über Authorization Server B geregelt wird (Trust Domain B). Hierfür verwendet der Mechanismus eine Kombination der RFCs “OAuth 2.0 Token Exchange” (RFC 8693) und “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants” (RFC 7523). Nachdem in Draft-Version #05 kleinere inhaltliche Änderungen vorgenommen wurden, diente #06 dazu das Feedback aus dem “Working Group Last Call” (WGLC), welcher im September stattgefunden hat, einzuarbeiten. Nun befindet sich der Draft im Review Prozess eines der Working Group Chairs.
  
  
• Auch in Q3 wurde weiter an dem Draft “Updates to Audience Values for OAuth 2.0 Authorization Servers” (Arbeitstitel, rfc7523bis) gearbeitet. Ab der neuen Draft-Version #02 fokussiert sich das Dokument auf den Use-Case eines JWTs zur Client-Authentifizierung. Den Einsatz von SAML Assertions zur Client-Authentifizierung hingegen verbietet der neue Draft. Außerdem wird die Definition des Wertes für den “aud” Claim innerhalb des Tokens gelockert: Zuvor schrieb der Draft vor, dass es sich bei dem Claim um den “Issuer Identifier” des Ausstellers handeln muss. Dies hätte in verschiedenen Szenarien zu einem “breaking change” geführt und wurde daher abgeändert. Nun ist der Client dafür verantwortlich einen Wert für den “aud” Claim zu wählen “specific to the authorization server being used”.
  Kurz vor Veröffentlichung dieses Hackletters ist Draft-Version #03 erschienen. In dieser Version wurde die Fokussierung des Drafts auf JWTs für Client-Authentifizierung weiter gestärkt.
  
  
• Im August wurde der zuvor individuelle Draft “JSON Web Token Best Current Practices”, der den aktuellen RFC 8725 als (kleines) Update ersetzen soll, nach einem erfolgreichen “Call for Adoption” von der OAuth Working Group “adoptiert”. Nun soll im Kontext der Working Group weiter daran gearbeitet werden Angriffe auf JWTs, die seit der Veröffentlichung von RFC 8725 im Februar 2020 bekannt geworden sind (z. B. Encryption-Signature-Confusion, JWE Decompression Bomb), in den Draft aufzunehmen und Gegenmaßnahmen zu empfehlen.
  
  
• Ende Juli wurde für den Draft “Transaction Tokens” eine neue Version veröffentlicht. In Draft-Version #06 wurden kleine sprachliche Änderungen vorgenommen, sowie ein Paragraph hinzugefügt, um zu unterstreichen, dass Transaction Tokens keine Credentials für Authentifizierungen sind. Anschließend wurde basierend auf dieser Version ein WGLC gestartet. Im Rahmen des WGLC wurde von mehreren Personen ausführliches Feedback gegeben. Ein Hauptaugenmerk lag dabei darauf, den Scope des Drafts zu schärfen, um klarzustellen, dass Transaction Tokens strikt innerhalb einer einzigen “Trust Domain” verwendet werden soll. Die Autor:innen des Drafts haben begonnen das Feedback einzuarbeiten; eine aktualisierte Draft-Version ist in Q3 jedoch noch nicht erschienen.
  
  

Fragen, Ausblick und Diskussionen

• Für die zukünftige Version OAuth 2.1 ist zwar kein Draft-Update in diesem Quartal erschienen, es gab jedoch eine interessante Diskussion: Die Autoren des Drafts haben vorgeschlagen die Metadaten von Authorization Server und Client um ein Feld zu erweitern, welches den Support für Version OAuth 2.1 angibt. Ziel soll es unter anderem sein, Konformität zu OAuth 2.1 bei der Client Registrierung sicherzustellen. Kritiker:innen des Vorschlags bemängeln, dass die strikte Versionierung eine schlechte Lösung zur Interoperabilität sei. Stattdessen sollen Metadaten-Felder, die den Support für in OAuth 2.1 vorgeschriebene Feature (z. B. PKCE) angeben, verwendet werden. Ein Autor argumentiert dagegen, dass ein AS volle Konformität zu OAuth 2.1 angeben soll, statt einzelne Features herauszupicken. Das Ergebnis der Diskussion ist, dass die Autor:innen des Drafts in Zukunft einen überarbeiteten Vorschlag unterbreiten wollen.
  
  
• In einer weiteren Diskussion wurde auf der OAuth-Mailingliste der individuelle Draft “OAuth 2.0 step-up authorization challenge proto” vorgestellt. Der Draft stellt eine Erweiterung von RFC 9470 dar, die es einem Resource Server erlaubt, detaillierte Fehlermeldungen an den Client zu geben. Diese Fehlermeldungen teilen dem Client mit, warum der Zugriff auf die Ressource abgelehnt wurde und welche “Authorization Requirements” der Client für einen erfolgreichen Zugriff erfüllen muss.
  
  
• Auf der Mailingliste der OAuth Working Group wurde diskutiert, ob der OAuth-Standard sich anpassen sollte an fehlerhaften Quellcode zur Verarbeitung von Tokens im Authorization-Header, wie er von “Coding Agents” produziert wird. Der diskutierte Quellcode der Coding Agents ist zu speziell und erlaubt nicht die Flexibilität, die der HTTP-Standard für HTTP-Header vorsieht. So definiert RFC 9112, dass bei HTTP-Headern die Groß-/Kleinschreibung nicht zu beachten ist und beliebige Leerzeichen enthalten sein können. Der von KI generierte Beispielcode hingegen sieht vor, dass der Authorization-Header immer ein großgeschriebenes “Bearer” gefolgt von genau einem Leerzeichen enthält, bevor das Token folgt. Am Ende der Diskussion wurde sich geeinigt, dass der OAuth-Standard nicht von dem HTTP-Standard abweichen sollte. Dennoch könnte eine nicht-normative Empfehlung eingefügt werden, dass Clients ein großgeschriebenes “Bearer” und nur ein Leerzeichen vor dem Token verwenden sollen.
  
  
• Des Weiteren wurden zwei individuelle Drafts vorgestellt bzw. diskutiert, die sich mit der Autorisierung für “AI Agents” beschäftigen:
  
  
  • Der erste Draft (“AAuth - Agentic Authorization OAuth 2.1 Extension”) stammt aus dem Bereich der “Agent 2 Agent”-Kommunikation. Die Mitglieder der OAuth-Mailingliste kritisieren u. a. den Ansatz, dass ein “AI Agent” sich authentifizieren soll durch die Kenntnis persönlicher Informationen über die Person, in deren Namen der Agent handelt. Diese “Knowledge-Based Authentication” wird als Anti-Pattern und ähnlich dem mittlerweile durch RFC 9700 verbotenen “Resource Owner Password Credentials Grant” (ROPCG) gesehen. Stattdessen wird auch für die Autorisierung eines “AI Agents” ein Flow mit “Human-In-The-Loop”, wie z. B. CIBA, empfohlen.
    
    
  • In dem zweiten Draft (“OAuth2.0 Extention for AI Agent: Authorization on Target“) wird ein neuer Parameter als Erweiterung zu einem OAuth Flow definiert, um anzugeben, welches Modul eines Clients (z. B. ein “AI Agent”) die Autorisierung benötigt. Eine kurze Diskussion spricht mögliche Anknüpfpunkte zu anderen Drafts und zukünftigen Anpassungen an.

Was kommt als Nächstes?

Auch im nächsten Quartal dürfen Sie sich auf spannende Entwicklungen im OAuth-Umfeld freuen. Zahlreiche Drafts stehen kurz vor dem Abschluss, und neue Diskussionen zu KI und Sicherheitsmechanismen versprechen frische Impulse. Verpassen Sie keine Neuigkeiten – der nächste Hackletter fasst alles Wichtige für Sie zusammen.

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:innen 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