Die Aufgabe vor dem Werkzeug wählen
Ein OAuth-Zugriffstoken kann undurchsichtig sein oder JWT verwenden. JWT-Dekodierung prüft keine Echtheit; ein signiertes JWT verschlüsselt nicht automatisch den Inhalt. Ein Gateway ersetzt keine fachliche Autorisierung innerhalb der Dienste.
| Element | Aufgabe | Sichtbare Grenze |
|---|---|---|
| OAuth 2.0 | Delegierte Autorisierung. | Allein kein Protokoll zur Nutzeranmeldung. |
| OpenID Connect | Authentifizierung auf OAuth 2.0. | Erfordert Profil- und Tokenprüfung. |
| JWT | Format für Aussagen. | Dekodierung, Signatur und Verschlüsselung sind verschieden. |
| API-Gateway | Gemeinsame Eingangskontrollen. | Ersetzt keine Objektberechtigungen. |
Protokoll und jeden Zugriff prüfen
- Wählen Sie einen zum Client passenden Ablauf. Folgen Sie bei Nutzerabläufen aktuellen Empfehlungen zu Authorization Code und PKCE, mit gepflegter Bibliothek und streng kontrollierten Weiterleitungen.
- Prüfen Sie bei akzeptierten JWTs Signatur, erlaubte Algorithmen, Aussteller, Zielgruppe und zeitliche Profilvorgaben. Lehnen Sie Tokens für andere Verwendungen ab.
- Prüfen Sie jedes Objekt, jede Aktion und Organisation. Testen Sie kontenübergreifende Zugriffe mit fiktiven Daten; eine allgemeine Rolle oder Berechtigung reicht nicht immer.
Ablauf, Widerruf und Vorfälle einplanen
Dokumentieren Sie Erneuerung, Schlüsselrotation, Geheimnisverlust und Widerrufsstrategie. Lokale Tokenprüfung erfährt nicht automatisch von einem entfernten Widerruf. Begrenzen Sie Tokendaten und Protokolle; JWT und Quoten allein garantieren weder Sicherheit noch Konformität.
Primärquellen
- IETF RFC 9700 — OAuth 2.0 Security Best Current Practice [EN]
- IETF RFC 8725 — JWT Best Current Practices [EN]
- OpenID Foundation — OpenID Connect Core 1.0 [EN]
- OWASP — Authorization Cheat Sheet [EN]
Ein Gateway ersetzt nicht die Objektautorisierung.
Eine API sollte überprüfen, ob ein Token für sie bestimmt ist und ob der Aufrufer die Operation am Objekt ausführen darf. Eine gültige JWT-Signatur oder eine erfolgreiche OAuth-Anmeldung begründen diese Berechtigungen nicht. Testen Sie benachbarte Identitäten und privilegierte Funktionen.
- Weisen Sie ein gültiges Token zurück, das für eine andere Zielgruppe bestimmt ist.
- Testen Sie kontoübergreifenden Zugriff, private Felder und administrative Operationen.
- Testen Sie Ablauf und Rollenwechsel, ohne Token in Protokolle zu schreiben.
Primärquelle: IETF — RFC 9700, OAuth 2.0 Security Best Current Practice. Verwandte Methode: den praktischen Leitfaden lesen.
Passkeys: Domain- und RP-ID-Wechsel vorbereiten
Konto, Web-Origin und RP ID unterscheiden, damit Zugangsdaten nicht stillschweigend neu zugeordnet werden.
- Notiere alte und neue Origins, RP IDs und zugehörige Konten. Ein gleicher Kontoname macht einen Passkey nicht für eine andere RP ID gültig. Prüfe erlaubte WebAuthn-Kombinationen und verfügbare Zugangswege während des Wechsels.
- Prüfe in einer autorisierten Testumgebung Challenge, Origin, RP ID und Kontobindung mit einer geeigneten Bibliothek. Teste unerwartete Origins und wiederholte Challenges. Bei neuer RP ID ist eine authentifizierte Neuregistrierung nötig; eine kopierte Datenbankzeile migriert keinen Schlüssel.
- Teste Nutzer mit nur altem Credential, Wiederherstellung und offene Sitzungen. Lege Öffnung und Stilllegung der Wege mit geprüftem Rückweg fest. Eine erfolgreiche Registrierung auf der neuen Domain beweist nicht den Widerruf aller alten Sitzungen.
Nachvollziehbarer Abnahmefall
Fiktives Beispiel: Diese Daten beschreiben keine Kunden oder beobachteten Ergebnisse.
Falldaten anzeigen
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}Erwartete Entscheidung
Fiktives Beispiel: Das Konto bleibt gleich, aber old.example wird new.example mit anderer RP ID. Das alte Credential darf nicht still neu zugeordnet werden; die neue Registrierung folgt dem vorgesehenen authentifizierten Ablauf.
Kann eine Datenbankänderung die RP ID eines Passkeys ändern?
Nein. Die RP ID gehört zum geprüften Geltungsbereich des Credentials. Bereite eine gültige Registrierung für den neuen Bereich und eine authentifizierte Kontozuordnung vor.
Primärquelle: W3C — Web Authentication Level 2. Verwandte Methode: den praktischen Leitfaden lesen.
TLS-Erneuerung: das tatsächlich ausgelieferte Zertifikat prüfen
Erneuerung bis zu Endpunkten und Clients verfolgen, bevor der Wechsel abgeschlossen wird.
- Erfasse Namen, CDN, Lastverteiler, Proxys und interne Verbindungen mit Zertifikaten. Notiere ausgeliefertes Zertifikat, Kette, Ablauf und Zuständigkeit. Ausstellung beweist keine Installation auf allen Knoten. Schütze private Schlüssel und halte sie aus dem Register heraus.
- Teste Automatisierung in der Testumgebung des Anbieters, falls vorhanden. Prüfe Challenges, SAN-Namen, geschützten Speicher und Neuladen. Vermeide Ausstellung bei jedem Instanzstart, wenn nach Schlüsselrichtlinie ein nutzbares Zertifikat vorliegt.
- Prüfe Namen, Gültigkeit und Vertrauenskette mit unterstützten Clients über relevante Wege. TLS-Prüfung bleibt aktiv. Überwache Ablauf des ausgelieferten Zertifikats statt nur Schedulerstatus. Rückkehr braucht gültiges Zertifikat und unkompromittierten Schlüssel; sonst Endpunkt korrigieren oder isolieren.
Nachvollziehbarer Abnahmefall
Fiktives Beispiel: Diese Daten beschreiben keine Kunden oder beobachteten Ergebnisse.
Falldaten anzeigen
{
"issuance_succeeded": true,
"proxy_count": 2,
"proxies_serving_expected_certificate": 1,
"other_proxy_certificate_expired": true,
"tls_verification_enabled": true,
"expected": "change_incomplete_fix_and_verify_client_paths"
}Erwartete Entscheidung
Fiktives Beispiel: Erneuerung erfolgreich, aber einer von zwei Proxys liefert ein abgelaufenes Zertifikat. Der Wechsel bleibt offen; korrigiere den Proxy und prüfe Clientwege ohne Abschalten der TLS-Prüfung.
Primärquelle: Let’s Encrypt — Integration Guide. Verwandte Methode: den praktischen Leitfaden lesen.
CISA-KEV-Katalog durchsuchen
Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.
One identifier can span several technical layers
An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.
- Connect the CVE, component supplier and final-product supplier.
- Check version, configuration and execution path in the authorised environment.
- Do not infer remediation from an empty search result.
CISA KEV · 2026.10.21 · Documentary review : 2026-10-22
Erweiterungen: Berechtigungen und Zugriff
Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.
Robust authentication does not describe extension access
Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.
- Test approved extensions in a profile dedicated to sensitive operations.
- For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
- Distinguish session revocation, token revocation, extension disablement and native-component removal.
Read the permission directory and manifest examples →
Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent