Skill und Service sind zwei verschiedene Ebenen.
Ein Skill in /skills beschreibt den Ablauf fuer Agenten. Der langlebige Login-Zustand gehoert in einen Broker wie authd, nicht in ein SKILL.md.
Dokumentation
Der belastbare Stand fuer Browser-Login, MCP und A2A.
Diese Seite fasst den verifizierten Architekturstand fuer Codex CLI, OpenCode CLI und eigene Apps zusammen. Fokus ist nicht Meinung, sondern das Setup, das technisch und organisatorisch traegt.
Kurzfassung
Die Zielarchitektur ist Skill plus Broker plus Provider.
Skills steuern den Ablauf. Ein Broker verwaltet Zustand und Tokens. Provider kapseln einzelne Plattformen.
Nicht mehr aktuellReines SSE, pauschales OAuth-Wording und vermischte Protokoll-Ebenen.
Die aktuellen Primarquellen trennen das heute klarer.
ZielbildBrowser-Login mit PKCE, MCP fuer Tools, A2A fuer Delegation.
Die Schichten bleiben getrennt und dadurch robust fuer CLI und App-Kontexte.
6 Tabsgeprueft im Google Doc
7.3.2026gegen Primarquellen abgeglichen
X + MCP + A2Aals Kernprotokolle bereinigt
1 Architekturfuer CLI, Agenten und Apps
Korrigiert
Diese Punkte mussten sauber nachgezogen werden.
Die interne Dokumentation hatte gute Ansätze, aber auch zu harte oder veraltete Aussagen. Diese Seite zieht die technischen Grenzen sauber nach.
Fuer X gilt User-Login ueber OAuth 2.0 + PKCE.
Fuer dauerhafte CLI-Logins sind Systembrowser, PKCE, Loopback-Redirect und offline.access die belastbare Basis. App-only Bearer Tokens reichen nicht fuer Posts im Namen eines Nutzers.
OAuth 2.1 ist Leitlinie, nicht die einzige korrekte Formulierung.
In der Praxis setzt ihr die OAuth-2.1-Sicherheitsregeln meist als OAuth 2.0 Authorization Code + PKCE um. Fuer Native- und CLI-Apps bleibt RFC 8252 die Referenz fuer Browser-Login und Loopback-Redirect.
Client Metadata Documents sind MCP-spezifische Best Practice.
Im aktuellen MCP-Auth-Stand sind Client Metadata Documents mit /.well-known/oauth-client.json fuer neue Clients empfohlen, waehrend Dynamic Client Registration als Rueckfalloption bleibt. Das ist keine universelle Pflicht fuer jedes andere Oekosystem.
Remote MCP sollte nicht mehr mit nacktem SSE beschrieben werden.
Die aktuelle MCP-Spezifikation priorisiert Streamable HTTP. SSE bleibt fuer Rueckwaertskompatibilitaet relevant, ist aber nicht mehr die bevorzugte Ausgangsbasis fuer neue Remote-Server.
A2A ersetzt MCP nicht, sondern ergaenzt es.
A2A ist fuer Agent-zu-Agent-Kommunikation gedacht. MCP bleibt die Werkzeug- und Ressourcenschicht. Die saubere Architektur trennt beide statt einen Sieger auszurufen.
Empfohlen
Die dauerhafte Architektur fuer CLI-Agenten und eigene Apps.
Die belastbare Loesung ist keine Sonderlogik pro Tool, sondern eine gemeinsame Auth-Infrastruktur mit klarer Rollenverteilung.
Skills gehoeren in /skills, weil dort die Arbeitsanweisung fuer Agenten liegt. Der eigentliche Login-Zustand gehoert in einen Broker, der ausserhalb des Modellkontexts lebt.
skills/auth-broker/ services/authd/ services/auth-core/ services/provider-x/
Orchestriert Login-Flows fuer Agenten und CLIs. Hier steht die Bedienlogik, nicht die Token-Quelle.
Als Service-Skelett im Repo angelegt: lokaler Broker fuer Systembrowser, Callback auf 127.0.0.1, Keychain-Zugriff und kurzlebige Token-Ausgabe.
Als Service-Skelett im Repo angelegt: gemeinsame OAuth-, PKCE-, Token-Refresh- und Provider-Abstraktion fuer alle Clients und Apps.
Als Service-Skelett im Repo angelegt: X-spezifischer Adapter fuer Authorization Code + PKCE, User Context, offline.access, whoami und post.
Einheitlichkeit
Diese Muster sollten kuenftig nicht mehr in die Doku rutschen.
Glaubwuerdigkeit entsteht hier durch klare Ebenen, exakte Datierung und belastbare Quellen statt Superlativen.
Vermeide absolute Aussagen wie "A2A ist ueber MCP ueberlegen". Die Primarquellen beschreiben die Protokolle als komplementaer.
Nutze fuer A2A-Agent-Cards die aktuelle Bezeichnung und den aktuellen Well-Known-Pfad statt veralteter agent.json-Sprache.
Entferne Prozentzahlen, Marktanteile und "Goldstandard"-Wertungen, wenn dafuer keine belastbare Primaerquelle im Dokument steht.
Markiere dated Claims mit exaktem Stichtag oder Quelle. Das betrifft vor allem Deprecation-Timelines und Versionsaussagen.
Beschreibe Transport und Auth getrennt. Streamable HTTP, OAuth und Agent-Discovery sind unterschiedliche Ebenen.
Primaerquellen
Diese Referenzen tragen den aktuellen Stand.
Fuer Browser-Login, MCP und A2A sollten kuenftig diese Primarquellen zitiert werden statt unmarkierter Sekundaerbehauptungen.
Quelle
MCP Authorization
Protected resource metadata, dynamic registration und client metadata documents.
QuelleMCP Transport
Streamable HTTP ist der bevorzugte Transport; SSE steht fuer Kompatibilitaet bereit.
QuelleA2A Protocol
A2A ist fuer Agent-zu-Agent-Aufgaben, Status-Updates, Artifacts und Discovery gedacht.
QuelleX OAuth 2.0 PKCE
User-Login fuer X inklusive Authorization Code Flow und PKCE.
QuelleX App-only
App-only Bearer Tokens sind kein Ersatz fuer User Context, wenn ein Nutzerkonto handeln soll.
QuelleRFC 8252
Best Current Practice fuer OAuth 2.0 in nativen Apps mit Systembrowser und Loopback-Redirect.
Naechster Schritt
Damit kann die gemeinsame Auth-Schicht sauber weitergebaut werden.
Die Dokumentation zeigt jetzt dieselbe Architektur wie das Repo: Skill, Broker und Provider mit klarer Trennung.