API-Authentifizierung mit Zugriffstokens aus OAuth 2.1
API-Authentifizierung ist die Art, wie Ihre API entscheidet, welcher Aufrufer eine Anfrage gesendet hat und was dieser Aufrufer tun darf. Üblich ist heute, dass Aufrufer ein kurzlebiges Zugriffstoken vorlegen, das über OpenID Connect und OAuth 2.1 ausgestellt wurde, und dass Ihre API dieses Token bei jeder Anfrage prüft. Die Skycloak Platform ist dafür gebaut, der Server zu sein, der diese Tokens ausstellt, sodass Ihre API sie nur noch prüfen muss.
Wie Zugriffstokens Ihre API schützen
Ein Zugriffstoken ist eine signierte Aussage Ihres Anmeldeservers darüber, an wen es ausgestellt wurde, für welche API es bestimmt ist und bis wann es gilt. Ihre Web-App, Ihre mobile App oder ein anderer Dienst erhält es über einen OAuth 2.1-Ablauf: den Authorization Code Flow, wenn sich eine Person anmeldet, oder den Client Credentials Grant, wenn einer Ihrer Dienste einen anderen ohne Benutzer aufruft. OAuth 2.1 schreibt für den Authorization Code Flow PKCE (Proof Key for Code Exchange) vor, wodurch ein gestohlener Autorisierungscode von niemand anderem gegen ein Token eingetauscht werden kann. Der Aufrufer sendet das Token dann im Authorization-Header jeder Anfrage an Ihre API.
Zugriffstokens sind meist JSON Web Tokens, kurz JWTs, die Ihre API lokal prüfen kann, ohne bei jeder Anfrage den Anmeldeserver aufzurufen. Sie laufen nach Minuten statt nach Monaten ab, sodass ein abgeflossenes Token bald nicht mehr funktioniert, und mit einem Refresh-Token holt sich der Client ein neues, ohne den Benutzer erneut anzumelden. Die Scopes im Token legen fest, was der Aufrufer tun darf, etwa Rechnungen lesen, aber nicht löschen, sodass Ihre API eine Aktion ablehnen kann, die das Token nie erlaubt hat. Die Entscheidung, wer was aufrufen darf, liegt damit an einer Stelle, statt über Ihre Endpunkte verteilt zu sein.
Was Ihre API bei jeder Anfrage prüft
Ein JWT zu validieren bedeutet vier Prüfungen am Token selbst und danach eine Prüfung seiner Scopes, und wer eine davon auslässt, hinterlässt eine Lücke. Ihre API prüft die Signatur mit den öffentlichen Schlüsseln, die Ihr Anmeldeserver veröffentlicht, damit ein Token, das niemand signiert hat, abgelehnt wird. Sie prüft, dass der Aussteller die Anmeldeadresse Ihres Mandanten ist und die Zielgruppe (Audience) Ihre API, damit ein Token für eine andere Anwendung oder einen anderen Mandanten nicht akzeptiert wird. Danach prüft sie die Ablaufzeit und zuletzt, ob die Scopes die angefragte Aktion abdecken.
Jeder Mandant auf der Plattform hat eine eigene Anmeldeadresse und eigene Signaturschlüssel, sodass Ihre Produktions-API nie ein Token Ihres Staging-Mandanten akzeptiert. Standard-JWT-Bibliotheken in den meisten Sprachen können die veröffentlichten Schlüssel abrufen, zwischenspeichern und bei einer Schlüsselrotation die neuen übernehmen, sodass Sie davon kaum Code selbst schreiben. An den Absender gebundene Tokens fügen einen weiteren Schutz hinzu. Mit DPoP (Demonstrating Proof of Possession), geplant für die erste Version der Plattform, beweist der Client mit seinem eigenen privaten Schlüssel, dass er das Token besitzt, sodass ein aus einem Log oder einem Proxy kopiertes Token für den Kopierenden nutzlos ist.
Wie sich Zugriffstokens von statischen API-Keys unterscheiden
Ein statischer API-Key ist ein langlebiges Geheimnis, das ein Aufrufer mit jeder Anfrage sendet und das Ihre API nachschlägt, um zu entscheiden, wer aufruft. Keys sind einfach zu verteilen, laufen aber meist nie ab, sagen nichts über den Benutzer hinter der Anfrage aus, und ein abgeflossener Key funktioniert weiter, bis jemand es bemerkt und ihn widerruft. Jede Prüfung braucht außerdem eine Abfrage in Ihrer eigenen Datenbank, und einen Key auszutauschen bedeutet Abstimmung mit dem, der ihn hat.
Zugriffstokens vermeiden das meiste davon, weil sie schnell ablaufen, die Anwendung und, falls vorhanden, den Benutzer nennen und Scopes tragen, die Ihre API ohne Abfrage durchsetzen kann. API-Keys haben bei einfachen Integrationen weiter ihren Platz, und die Management-API der Plattform selbst nutzt Keys mit Lese- und Schreib-Scopes pro Ressource. Für die API Ihres Produkts ist die Plattform dafür gebaut, die Tokens über OpenID Connect und OAuth 2.1 auszustellen, ohne dass Ihr Team diesen Server betreibt, und in einer Demo sehen Sie, welche dieser Bausteine Sie heute nutzen können.
Häufige Fragen
Brauche ich einen Benutzer, um ein Zugriffstoken zu bekommen?
Nein. Mit dem Client Credentials Grant authentifiziert sich einer Ihrer Dienste als er selbst und erhält ein Token, um einen anderen Dienst aufzurufen, ganz ohne Benutzer. Das ist Standard-OAuth, und das Token trägt die Identität und die Scopes des aufrufenden Dienstes statt die eines Benutzers.
Kann meine API Tokens prüfen, ohne bei jeder Anfrage die Plattform aufzurufen?
Ja. Die Plattform ist darauf ausgelegt, Zugriffstokens als signierte JWTs auszustellen, also kann Ihre API die Signatur mit den öffentlichen Schlüsseln prüfen, die Ihr Mandant veröffentlicht, und Aussteller, Zielgruppe und Ablaufzeit lokal kontrollieren. Die Schlüssel muss sie nur nach einer Rotation erneut abrufen.
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.