Identität und Berechtigung sind zwei Entscheidungen
Authentifizierung prüft einen vorgelegten Zugangsnachweis und ordnet ihn einer Identität zu. Das kann ein Benutzer, ein Dienst oder eine Integration sein. Bei einem gestohlenen Zugangsnachweis erkennt das System möglicherweise weiterhin dessen Inhaber – nicht den tatsächlichen Menschen am anderen Ende. Deshalb gehören Geheimnisschutz, Ablauf und Sperrung zum Verfahren.
Autorisierung entscheidet anschließend über die konkrete Handlung. Ein angemeldeter Benutzer darf beispielsweise seine eigenen Rechnungen lesen, aber keine fremden. Auch ein technisch gültiges Token mit einem allgemeinen Lesescope beantwortet noch nicht, welche einzelne Rechnung zugänglich ist. Diese Prüfung gehört an jeden betroffenen Daten- und Funktionszugriff. Die OWASP REST-Empfehlungen unterscheiden den Zugang zum Dienst und dessen Zugriffskontrollen.
Planen Sie daher zwei Nachweise: einen für den Zugang und einen für die Berechtigung an Objekten. Ein erfolgreicher Login ist nur der erste.
Die passende Ausgangslösung finden
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Situation | Naheliegender Ausgangspunkt | Vor der Entscheidung klären |
|---|---|---|
| Eigenes Browserfrontend mit eigenem Backend | Serverseitig verwaltete Sitzung; häufig lässt sich das Frontend über denselben Origin anbinden | Cookie-, CSRF- und Sitzungsregeln, Login, Logout, Ablauf und Sperrung |
| Dienstintegration ohne angemeldeten Benutzer | Begrenzter API-Key oder OAuth Client Credentials | Geheimnisspeicherung, minimale Dienstrechte, Schlüsselwechsel und Verantwortlicher |
| Anwendung soll mit Zustimmung auf Benutzerdaten zugreifen | OAuth mit geeignetem Autorisierungsablauf | Clienttyp, Freigaben, Ziel-API, Tokenprüfung und Widerruf |
| Benutzer sollen sich über einen Identitätsanbieter anmelden | OpenID Connect für die Anmeldung, bei API-Zugriff zusätzlich passendes Access-Token | Vertrauenswürdiger Aussteller und unterschiedliche Empfänger der Token |
Die Tabelle ist eine Auswahlhilfe, keine Sicherheitsrangliste. Ein vorhandener Identitätsanbieter kann auch Dienstzugänge sinnvoll zentralisieren. Eine kleine interne Integration braucht dagegen nicht allein deshalb einen neuen Autorisierungsserver, weil OAuth verbreitet ist.
OAuth Client Credentials ist für vertrauliche Clients vorgesehen, die ihren eigenen Zugangsnachweis schützen können. Es stellt keine interaktive Benutzeranmeldung dar. Ein Browserprogramm kann ein eingebautes Clientgeheimnis nicht vertraulich halten. Die grundlegenden Clienttypen und den Dienstablauf beschreibt RFC 6749, Abschnitte 2.1 und 4.4.
Beim Browser zuerst die Vertrauensgrenze zeichnen
Bei einer serverseitigen Sitzung hält der Browser typischerweise eine Sitzungskennung in einem Cookie. Der Server ordnet diese einer Sitzung zu. Das erleichtert einen zentralen Widerruf, setzt aber voraus, dass alle relevanten Instanzen den aktuellen Sitzungszustand berücksichtigen. Ein bloß im Browser gelöschtes Cookie beendet nicht zwangsläufig den serverseitigen Zugang.
Eine andere Architektur lässt den Browser OAuth-Token beziehen. Dann müssen Ausgabe, Speicherung und Nutzung für einen öffentlichen Client ausgelegt sein. Eine Anwendung mit eigenem Backend kann Token auch serverseitig verwalten und dem Browser nur eine Sitzung geben. Diese Entscheidung verändert die Angriffsflächen; sie beseitigt weder eingeschleusten Browsercode noch die Notwendigkeit korrekter Rechte.
Schreiben Sie für Ihren Aufbau auf, welche Geheimnisse JavaScript lesen kann und welche Zugangsdaten der Browser automatisch mitsendet. Das führt zur passenden Cookie- und CSRF-Absicherung. Bei unterschiedlichen Origins kommt CORS hinzu. CORS ersetzt dabei keine Anmeldung.
API-Key, Bearer-Token und JWT richtig auseinanderhalten
Ein API-Key wird vom jeweiligen Dienst definiert. Er kann eine Anwendung oder ein Konto zuordnen und mit Rechten, Quoten und Ablauf verbunden sein. Seine Eigenschaften folgen dem Anbieter- oder eigenen API-Vertrag, nicht einer universellen API-Key-Norm. Behandeln Sie einen geheimen Schlüssel wie einen übertragbaren Zugangsnachweis. Die praktische Verwaltung erklärt der API-Key-Leitfaden.
Bei einem Bearer-Token genügt grundsätzlich der Besitz für die Nutzung innerhalb seiner Gültigkeit und Rechte. TLS schützt die Übertragung, verhindert aber nicht die Verwendung einer anderweitig kopierten Zeichenfolge. RFC 6750 beschreibt diese Eigenschaft. Für besondere Anforderungen kommen sendergebundene Verfahren hinzu; sie benötigen ein passendes Gesamtprofil, keine zusätzliche zufällige Headerzeile.
Ein JWT enthält strukturierte Aussagen, sogenannte Claims. Eine signierte Variante ermöglicht die Prüfung von Herkunft und Unverändertheit im vereinbarten Vertrauensmodell. Sie verschlüsselt den Inhalt nicht automatisch. Ein opaque Token ist dagegen für den Client eine nicht zu interpretierende Zeichenfolge. Beide können Access-Token sein. Entscheidend ist, wie der empfangende Dienst sie validiert und was er anschließend erlaubt. Die JWT-Validierung vertieft diesen Schritt.
HTTP Basic überträgt Benutzerkennung und Passwort Base64-kodiert; diese Kodierung ist keine Verschlüsselung. Bestehende Integrationen können es über TLS verwenden, bringen aber wiederholt nutzbare Zugangsdaten in den Requestweg. Eine neue Benutzerdelegation sollte nicht daraus entstehen, dass Drittanwendungen das Hauptpasswort einsammeln. Siehe RFC 7617, Abschnitte 1 und 4.
Die Auswahl an einem kleinen Szenario prüfen
Angenommen, ein Archivdienst soll nachts freigegebene Dokumente abholen. Er braucht keine Benutzeroberfläche und keine Änderung von Dokumenten. Ein eigener Dienstzugang mit begrenztem Leserecht ist nachvollziehbar; ein geteilter Administratorschlüssel wäre es nicht. Später soll eine Partneranwendung von einzelnen Benutzern freigegebene Dokumente abrufen. Nun entsteht eine andere Aufgabe: getrennte Freigaben, deren Umfang und Widerruf müssen abbildbar sein. Dafür ist ein delegierter OAuth-Zugang zu prüfen.
Erstellen Sie vor der Umsetzung eine kurze Entscheidungsvorlage mit Clienttyp, geschützten Ressourcen, Rechteumfang, Ablauf, Sperrweg und Verantwortlichem. Nutzen Sie gepflegte Protokollbibliotheken oder etablierte Anbieterfunktionen. Für OAuth folgt die aktuelle Sicherheitsauswahl RFC 9700: ältere Beispielsammlungen mit Passwortgrant oder ungeschütztem Codeablauf sind keine geeignete Vorlage.
In einer eigenen Testumgebung muss anschließend nicht nur der erlaubte Zugriff funktionieren. Ein abgelaufener oder gesperrter Zugang, ein Token für eine andere API und eine nicht erlaubte Aktion müssen zuverlässig abgewiesen werden. Protokollieren Sie dabei die Entscheidung und eine Korrelationskennung, nicht den vollständigen Zugangsnachweis.
Einführung, Rücknahme und nächster Schritt
Stellen Sie zunächst eine klar abgegrenzte Clientgruppe um. Halten Sie fest, wie neue Zugänge verteilt, alte deaktiviert und Fehler erkannt werden. Ein zeitlich begrenzter Parallelbetrieb ist nur dann sinnvoll, wenn beide Wege denselben gewollten Berechtigungsumfang einhalten. Als Rücknahme dient eine getestete vorherige Konfiguration mit weiterhin vertrauenswürdigen Zugangsdaten. Ein bekannt kompromittierter Schlüssel wird nicht reaktiviert.
Der API Security Check untersucht diesen Anmelde- und Berechtigungsablauf nicht. Dafür brauchen Sie Konfigurations- und Codeprüfung sowie kontrollierte Tests mit eigenen Identitäten. Beginnen Sie nach der Auswahl mit OAuth/OIDC, API-Schlüsseln oder Browsercookies. Quellenstand dieses Ratgebers: 27. September 2026.
Quellen und Stand
Quellenstand: 27. September 2026. Die Links stehen zusätzlich bei den jeweils begründeten Aussagen.