Sicherheitsmodell und OAuth-Standards

Dieser Abschnitt erklärt, wie Weldall Zugriffe auf Unternehmenssysteme absichert. Im Kern gilt dabei eine einfache Regel: Der Agent bekommt niemals Zugangsdaten zu sehen. Alle Tokens werden in der CLI verwaltet, sind kurzlebig und an ein Gerät gebunden.

Das Sicherheitsmodell haben wir nicht selbst ausgedacht, sondern baut auf etablierten und aktuellen OAuth-Standards auf. Konkret kombiniert es einen Identity Assertion JWT Authorization Grant (ID-JAG) mit einem DPoP-gebundenen JWT Authorization Grant.

Das Problem: langlebige Zugangsdaten

Wer ohne besondere Vorgaben eine Applikation baut, der für Agenten verfügbar sein soll, könnte darauf kommen, API-Tokens oder vergleichbare Passwörter zu vergeben. Wer solche Zugangsdaten einmal besitzt, kann sie beliebig oft verwenden – auch von einem anderen Gerät aus. Verlorene oder kompromittierte Schlüssel müssen zurückgerufen werden, und Berechtigungen lassen sich kaum nachvollziehen, weil sie nicht nutzergebunden sind.

Weldall vermeidet das, indem es Zugriffe nach dem Prinzip kurzlebig, sendergebunden und zentral steuerbar gestaltet.

Die Vertrauenskette im Überblick

Das Diagramm oben zeigt den vollständigen Ablauf zwischen Mitarbeiter, Weldall CLI, Weldall Authorization Server (AS), dem Unternehmens-IdP und dem Downstream-Service. Im Detail:

1. Geräteschlüssel erzeugen – Beim ersten Start erzeugt die CLI ein Schlüsselpaar und speichert es im geschützten Betriebssystemspeicher.
2. Anmeldung über das Unternehmens-SSO – Die CLI öffnet die Anmeldung im Browser. Der Mitarbeiter meldet sich mit seiner bestehenden Unternehmensidentität an.
3. Autorisierungscode austauschen – Die CLI tauscht den Code per PKCE und DPoP gegen Access-, ID- und Refresh-Token ein. Die Tokens sind an den Geräteschlüssel gebunden.
4. Refresh-Token rotieren – Bei jeder Verlängerung sendet die CLI den Refresh-Token zusammen mit einem DPoP-Proof und erhält einen neuen Access-Token sowie einen rotierten Refresh-Token. Ein bereits verwendeter Refresh-Token wird damit wertlos.
5. Service ermitteln – Die CLI fragt beim AS die Resource Registry ab und erfährt, welche Ressourcen und Scopes für diesen Mitarbeiter freigegeben sind.
6. Identität weiterreichen (ID-JAG) – Für den gewünschten Service tauscht die CLI den Refresh-Token in einen signierten ID-JAG um.
7. Downstream-Token beschaffen – Der Downstream AS tauscht den ID-JAG per DPoP gegen einen Access-Token für genau diesen Service.
8. Request senden – Die CLI sendet den Request mit Token und DPoP-Proof direkt an den Service und gibt nur die fachliche Antwort an den Agenten zurück.

Warum der Agent kein Token sieht

Der Agent ruft weldall request auf und erhält ausschließlich die Antwort des Services. Er kennt weder die verwendeten Tokens noch den Geräteschlüssel. Das schließt zwei Wege aus, auf denen Zugangsdaten sonst verloren gehen:

• Kein Leak über den Kontext. Käme ein Token in den Kontext des Agenten, könnte es dort durch Logs, Übertragung oder einen Prompt-Token-Dump nach außen gelangen. Weil der Agent das Token nie sieht, kann es auch nicht in seinen Kontext geraten.
• Kein Weiterreichen über den Chat. Ein Agent kann ein Token nicht in einer Chat-Antwort versenden, weil er es gar nicht besitzt. Selbst ein anderweitig abgegriffenes Access-Token wäre wertlos: Es ist per DPoP an den Geräteschlüssel der CLI gebunden und lässt sich auf einem anderen Gerät nicht verwenden.

Selbst wenn doch etwas verloren ginge, hielte es nicht lange: Tokens sind kurzlebig, und DPoP-Replay-Schutz macht sie nur für genau einen Request gültig. Ein abgefangenes Token verliert damit rasch jeden Wert.

Zugriff zentral kontrollieren

Ob und wofür ein Mitarbeiter berechtigt ist, entscheidet der Authorization Server. Die CLI prüft vor jedem Request:

1. ob die Ziel-URL zu einem registrierten Service gehört,
2. ob der angeforderte Scope für diesen Service unterstützt und dem Mitarbeiter zugewiesen ist.

Weldall protokolliert erteilte und abgelehnte Zugriffe. Administratoren können nachvollziehen, wer welchen Zugriff auf welche Ressource angefordert hat – und können Berechtigungen zentral anpassen.

Verwendete OAuth-Standards

Standard	Zweck
Identity Assertion JWT Authorization Grant (ID-JAG, Draft-04)	Identität über die Vertrauenskette bis zum Downstream-Service weiterreichen
JWT Authorization Grant mit DPoP (Draft-01)	Refresh-Token sicher gegen einen Access-Token eintauschen
Native OAuth-Clients (RFC 8252)	Anmeldung über den Browser mit Loopback-Rückruf
PKCE (RFC 7636)	Autorisierungscode gegen einen Client-seitig verifizierten Code tauschen
OAuth-Sicherheitsempfehlungen (RFC 9700)	Aktuelle Best Practices für sichere OAuth-Flows
Sendergebundene Tokens mit DPoP (RFC 9449)	Access- und Refresh-Tokens an den Geräteschlüssel binden

Weitere Themen

• Wie die Komponenten zusammenarbeiten, zeigt Ein vollständiger Agentenlauf.
• Backend-Services mit eigenen Identitäten sichern Sie unter Machine-to-Machine-Authentifizierung.
• Metadaten und Signaturschlüssel über einen vertrauenswürdigen Proxy abrufen: Discovery-Proxy.