Eine Schritt-für-Schritt-Anleitung aus der Praxis zur Absicherung der Unternehmens-zu-Unternehmens-API-Kommunikation mit OAuth 2.0

Die meisten System-zu-System-Integrationen setzen immer noch auf geteilte API-Keys oder langlebige Secrets in Konfigurationsdateien — einfach, aber ein dauerhaftes Sicherheitsrisiko: kein Ablauf, keine Rotation, keine granulare Kontrolle. Ich habe eine vollständige Anleitung geschrieben, wie man das durch den Client-Credentials-Flow von OAuth 2.0 ersetzt, anhand von zwei unabhängigen Spring-Boot-Services — Unternehmen A und Unternehmen B —, die jeweils eigene Tokens ausstellen und die des anderen validieren. Das hier ist die Kurzfassung; der vollständige Artikel auf Medium enthält die komplette Spring-Konfiguration und den funktionierenden Quellcode.

Zwei Unternehmen, zwei Authorization Server

Die Regel, die zirkuläres Vertrauen vermeidet: Der Aufrufer holt sich sein Token immer vom eigenen Authorization Server, niemals vom Partner. Unternehmen A stellt Tokens aus und schützt /api/articles; Unternehmen B stellt eigene Tokens aus und schützt /api/employees. Jede Seite agiert gleichzeitig als OAuth-Client, Resource Server und — für die eigene Domäne — als Authorization Server, wobei Scopes wie articles.read und employees.read das Prinzip der geringsten Rechte durchsetzen statt pauschalem Zugriff.

Wo es in der Praxis wehtut

• Scope-Mismatch — ein Token mit articles.read, das auf einen Endpunkt trifft, der employees.read erwartet, scheitert mit einem stillen 403 — selbst wenn die Signatur einwandfrei ist.
• Falscher Token-Aussteller — wer Tokens von jemand anderem als dem eigenen Authorization Server akzeptiert, untergräbt das gesamte Modell.
• Fehlende JWT-Validierung — Signatur- und Audience-Prüfungen müssen explizit konfiguriert werden, sonst werden auch gültige Tokens abgelehnt.
• Vermischte Rollen — Client, Resource Server und Token-Aussteller sind drei verschiedene Aufgaben; sie in der Konfiguration zu vermischen kostet in der Praxis die meiste Debugging-Zeit.

Der vollständige Artikel geht durch das Setup des Spring Authorization Servers, den RestClient-Interceptor, der Tokens automatisch an ausgehende Aufrufe anhängt, und die genaue 403-Falle, in die die meisten Teams beim ersten Versuch tappen — plus den kompletten funktionierenden Quellcode. Weiterlesen: der vollständige Artikel auf Medium →