Zum Inhalt springen
Skycloak
Anwendungsfall

Machine-to-Machine-Authentifizierung für Dienste und Jobs

Machine-to-Machine-Authentifizierung ist der Weg, auf dem ein Dienst, ein geplanter Job oder ein Backend-Skript seine Identität gegenüber einer API nachweist, ohne dass ein Benutzer beteiligt ist. Der Standardweg ist der OAuth Client Credentials Grant, bei dem der Dienst seine eigenen Zugangsdaten gegen ein kurzlebiges Access Token tauscht. Die Skycloak Platform ist dafür gebaut, diese Tokens auszustellen, und private_key_jwt sowie DPoP sind für ihre erste Version geplant.

Wie der Client Credentials Grant funktioniert

Beim Client Credentials Grant wird jeder Dienst als OAuth-Client mit eigener Kennung und eigenen Zugangsdaten registriert. Wenn er eine API aufrufen muss, sendet er diese Zugangsdaten an den Token-Endpunkt und erhält ein Access Token zurück, das er jeder Anfrage beilegt. Die API prüft Signatur, Aussteller, Audience und Scopes des Tokens, bevor sie etwas tut, und sie bekommt die Zugangsdaten des Dienstes nie zu sehen.

Da sich kein Benutzer anmeldet, gibt es in diesem Ablauf keinen Browser, keine Weiterleitung und keinen Zustimmungsdialog. Jeder Dienst sollte einen eigenen Client haben, statt einen zu teilen, damit Sie erkennen, welcher Dienst einen Aufruf gemacht hat, und einen widerrufen können, ohne die anderen zu treffen. Die Scopes im Token begrenzen, was jeder Dienst darf, zum Beispiel Rechnungen lesen, aber nicht ändern.

Gemeinsame Geheimnisse durch private_key_jwt und DPoP ersetzen

Die einfachste Client-Zugangsdatenform ist ein gemeinsames Geheimnis, eine lange Zufallszeichenkette, die sowohl der Dienst als auch der Autorisierungsserver kennen. Das funktioniert, aber das Geheimnis muss in die Konfiguration kopiert werden, es kann über Logs oder Code-Repositorys durchsickern, und wer es besitzt, kann Tokens anfordern. Mit private_key_jwt signiert der Dienst stattdessen eine kurze Assertion mit einem privaten Schlüssel, der ihn nie verlässt, und der Server prüft diese Assertion mit dem passenden öffentlichen Schlüssel.

DPoP, kurz für Demonstrating Proof of Possession, geht einen Schritt weiter und bindet das Access Token an einen Schlüssel, den der Dienst hält. Jede Anfrage trägt einen frischen, mit diesem Schlüssel signierten Nachweis, sodass ein aus einem Log kopiertes oder unterwegs abgefangenes Token von niemand anderem verwendet werden kann. private_key_jwt und DPoP sind beide für die erste Version der Plattform geplant, zusammen mit Pushed Authorization Requests (PAR) für Abläufe, an denen ein Benutzer beteiligt ist.

Kurzlebige Tokens, Scopes und ein Audit-Protokoll

Access Tokens für Dienste sollten kurzlebig sein, eher Minuten als Tage, denn eine kurze Laufzeit begrenzt, wie lange ein geleaktes Token nutzbar bleibt. Ein Dienst kann einfach ein neues Token anfordern, wenn das alte abläuft, daher kosten kurze Laufzeiten ihn sehr wenig. Zusammen mit engen Scopes und einem eigenen Client pro Dienst bleibt die Wirkung eines einzelnen Lecks klein und leicht nachzuverfolgen.

Auf der Skycloak Platform verwalten Sie die Clients Ihrer Dienste über eine einzige öffentliche Verwaltungs-API, die auch die Konsole, eine CLI und ein MCP-Server nutzen. API-Schlüssel für diese API tragen Lese- und Schreib-Scopes pro Ressource, jeder Schreibvorgang wird protokolliert, und Ratenbegrenzungen gelten pro Schlüssel und pro Workspace. Das Anlegen eines Clients, das Ändern seiner Scopes oder das Rotieren seiner Zugangsdaten hinterlässt daher einen Eintrag, wer es wann getan hat.

Häufige Fragen

Ist der Client Credentials Grant dasselbe wie ein API-Schlüssel?

Nein. Ein API-Schlüssel ist meist eine langlebige Zeichenkette, die mit jeder Anfrage mitgeschickt wird, während der Client Credentials Grant die Zugangsdaten des Dienstes gegen ein kurzlebiges Access Token mit Scopes tauscht. Die API sieht dann nur Tokens, die ablaufen, und die Zugangsdaten selbst gehen nur an den Token-Endpunkt.

Funktionieren Machine-to-Machine-Clients mit Standard-OAuth-Bibliotheken?

Ja. Der Client Credentials Grant gehört zum Standard-OAuth, daher kann jede OAuth-Clientbibliothek, die ihn unterstützt, Tokens von der Plattform anfordern. private_key_jwt und DPoP sind ebenfalls offene Standards, und beide sind für die erste Version der Plattform geplant.

Sehen Sie sich die Skycloak Platform selbst an

Buchen Sie eine Demo, und wir zeigen Ihnen die Plattform mit Blick auf Ihre eigenen Anmeldeabläufe.