Tests und Inbetriebnahme

Testen Sie die vollständige Integration in der Testumgebung von Parkour Design, bevor produktive Zugangsdaten ausgegeben werden. Automatisierte Prüfungen weisen das Protokoll- und Vertragsverhalten nach; die manuelle Abnahme bestätigt die User Journey und die betriebliche Wiederherstellung.

Freigaberegel: Ein erfolgreicher Autorisierungs-Callback reicht für die Abnahme nicht aus. Die Inbetriebnahme erfordert die Validierung der Identität, Benutzerisolierung, Token-Rotation, Tests des Ressourcenvertrags, Wiederherstellung nach Fehlern und die Genehmigung beider Teams.

Testvoraussetzungen

Parkour Design und der Partner müssen Folgendes vorbereiten:

• einen registrierten Test-Client und ein sicher übermitteltes Geheimnis;
• eine exakte Test-Redirect-URI;
• den genehmigten Scope-Satz;
• mindestens zwei Testbenutzer von Parkour Design;
• Veranstaltungen und Entwürfe, die jeweils einem der Benutzer gehören;
• ein leeres Konto oder eine leere Veranstaltung, sofern relevant;
• Kontakte für technische Fragen und Vorfälle;
• erwartete Ergebnisse für jeden Abnahmefall.

Verwenden Sie den Test-Issuer:

https://parkour-test.web.app

Verwenden Sie Testzugangsdaten, Callback-URLs, Tokens oder Benutzerdaten nicht in der Produktionsumgebung.

Vorabprüfungen

Discovery

curl --fail-with-body \
  "https://parkour-test.web.app/.well-known/openid-configuration"

Prüfen Sie Folgendes:

• issuer entspricht exakt dem konfigurierten Test-Issuer;
• die Endpunkte für Autorisierung, Token, UserInfo und JWKS verwenden HTTPS;
• code, authorization_code, refresh_token, RS256 und S256 sind vorhanden;
• im Discovery Document erscheint weder ein Client Secret noch ein umgebungsspezifischer privater Wert.

Signaturschlüssel

Rufen Sie jwks_uri aus dem Discovery Document ab und prüfen Sie, ob jeder verwendbare Schlüssel über kid, kty, eine Verwendung zum Signieren und einen genehmigten Algorithmus verfügt. Bei einem unbekannten kid muss der Client JWKS einmal aktualisieren, bevor er das Token ablehnt.

Nicht authentifizierte Ressourcenanfrage

curl --include "https://parkour-test.web.app/api/events"

Erwartetes Ergebnis:

HTTP/2 401
Content-Type: application/json

{"error":"invalid_token"}

Automatisierte OAuth-Tests

Automatisieren Sie diese Fälle an der Systemgrenze des Partners. Verwenden Sie kontrollierte Test-Fixtures und simulieren Sie nur den externen Browserschritt, wenn ein vollständiger Browsertest nicht praktikabel ist.

Autorisierungsanfrage

• enthält die exakte Client-ID, Redirect-URI und genehmigten Scopes;
• erzeugt eindeutige state-, nonce- und PKCE-Verifier-Werte mit hoher Entropie;
• sendet code_challenge_method=S256;
• nimmt weder das Client Secret noch den Verifier in die URL auf;
• lehnt in einem negativen Umgebungstest eine nicht registrierte oder geringfügig abweichende Redirect-URI ab.

Callback

• akzeptiert den korrekten State genau einmal;
• lehnt einen fehlenden, abweichenden, abgelaufenen und wiederverwendeten State ab;
• verarbeitet access_denied, ohne einen Code auszutauschen;
• lehnt einen fehlenden Code bei einem ansonsten erfolgreichen Callback ab;
• behält ausschließlich einen validierten lokalen Rückkehrpfad bei;
• legt im Browser weder Protokolldiagnosen noch personenbezogene Daten offen.

Code-Austausch

• authentifiziert mit client_secret_basic;
• verwendet dieselbe Redirect-URI wie die Autorisierungsanfrage;
• sendet den ursprünglichen PKCE-Verifier;
• lehnt abgelaufene, wiederverwendete, für einen falschen Client ausgestellte und mit einem falschen Verifier verknüpfte Codes ab;
• behandelt Token-Antworten als nicht cachefähig und hält sie serverseitig.

Validierung des ID-Tokens

Lehnen Sie Tokens mit folgenden Merkmalen ab:

• eine ungültige Signatur;
• ein unbekannter Signaturschlüssel nach einer einmaligen JWKS-Aktualisierung;
• der falsche Issuer;
• die falsche Audience;
• ein anderer Algorithmus als RS256;
• eine fehlende oder falsche Nonce;
• abgelaufene oder unplausible zeitbezogene Claims;
• ein fehlendes Subject.

Prüfen Sie, ob die Kontoverknüpfung das Paar iss und sub und nicht nur die E-Mail-Adresse verwendet.

Rotation von Refresh-Tokens

• ein gültiges Refresh-Token gibt ein neues Zugriffstoken und ein Ersatz-Refresh-Token zurück;
• das Ersatz-Token wird atomar gespeichert;
• Refresh-Vorgänge werden für jede Benutzer- und Client-Sitzung serialisiert;
• die Wiederverwendung des alten Refresh-Tokens wird abgelehnt;
• ein für einen anderen Client ausgestelltes Token wird abgelehnt;
• ein abgelaufenes Token erfordert einen neuen Autorisierungsablauf;
• ein Timeout oder eine verlorene Refresh-Antwort mit unbekanntem Ergebnis löscht den lokalen Token-Zustand und startet einen neuen Autorisierungsablauf, statt das alte Token erneut zu verwenden;
• gleichzeitige Refresh-Versuche können nicht mit demselben Token konkurrieren;
• das lokale Trennen löscht das aktive Refresh-Token und die Sitzungsdaten.

Parkour Design verfügt derzeit über keinen öffentlichen Widerrufsendpunkt. Tests dürfen eine lokale Löschung nicht als serverseitigen Widerruf ausweisen.

Automatisierte Ressourcentests

Authentifizierung und Isolierung

• eine Anfrage ohne Token gibt 401 invalid_token zurück;
• ein abgelaufenes oder fehlerhaftes Token gibt 401 invalid_token zurück;
• ein als Bearer-Token für die API verwendetes ID-Token wird abgelehnt;
• Benutzer A sieht ausschließlich die Veranstaltungen und Entwürfe von Benutzer A;
• Benutzer B kann die Veranstaltung von Benutzer A nicht durch Kopieren ihrer ID abrufen;
• sowohl unzugängliche als auch nicht vorhandene Veranstaltungen geben 404 not_found zurück.

Schemavertrag

Validieren Sie jede Antwort anhand eines partnerspezifischen Schema-Fixtures:

• erforderliche Eigenschaften sind vorhanden;
• nullfähige Eigenschaften akzeptieren null;
• Datumsangaben werden als ISO-8601-Werte geparst;
• unbekannte zusätzliche Eigenschaften beeinträchtigen den Client nicht;
• leere Sammlungen geben ein leeres items-Array zurück;
• Identifikatoren werden als opake Zeichenfolgen behandelt;
• Text unterstützt Unicode und wird sicher dargestellt.

Leiten Sie aus dem Zusammenfassungsschema keinen vollständigen Parcoursentwurf ab.

Limits und Fehler

• der Client verarbeitet die größte genehmigte Veranstaltungsliste;
• das aktuelle Limit von 500 Entwürfen in der Detailansicht ist in der Risikobewertung für die Inbetriebnahme berücksichtigt;
• Antworten mit 401, 404, 405, 429 und 5xx folgen der vereinbarten Wiederholungsrichtlinie;
• Timeouts lösen keine unbegrenzten Wiederholungsversuche aus;
• fehlerhaftes JSON führt zu einem sicheren Abbruch und zeichnet eine bereinigte Diagnose auf;
• wiederholte idempotente GET-Anfragen verändern den Zustand des Partners nicht.

Tests für Exporte von Parkour Design zum Partner

Wenn Parkour Design Daten an einen Partner sendet, ergänzen Sie bilaterale Vertragstests für:

• die Auflistung von Zielen und Validierung von Identifikatoren;
• die ausschließliche Übermittlung einer Datei;
• die ausschließliche Übermittlung strukturierter Daten;
• die erfolgreiche Übermittlung aller Bestandteile;
• jede mögliche Kombination eines Teilerfolgs;
• fehlerhafte strukturierte Daten;
• leere und übergroße Dateien;
• Partnerantworten mit 401, 403, 404, 409, 413, 429 und 5xx;
• Verbindungs- und Antwort-Timeouts;
• doppelte Übermittlung und Idempotenzverhalten;
• Trennen, erneutes Verbinden und Token-Ablauf.

Manuelle Abnahme

Führen Sie die folgenden Schritte in einem echten Browser mit der gehosteten Testumgebung aus.

Wiederholen Sie den grundlegenden Ablauf in jeder unterstützten Sprache der Benutzeroberfläche. Protokollwerte müssen unverändert bleiben, während Meldungen für Benutzer lokalisiert werden.

Nachweise für die Sicherheitsprüfung

Stellen Sie den Prüfenden Folgendes bereit:

• ein Datenflussdiagramm mit Browser, beiden Backends, Identitätsanbieter, APIs und Token-Speicher;
• Allowlists für Redirect-URIs und Origins;
• angeforderte Scopes und Ressourcenzuordnung;
• Konfiguration für Token-Verschlüsselung und -Aufbewahrung;
• Konfiguration für die Validierung des ID-Tokens;
• bereinigte Beispiele für Protokolle und Warnmeldungen;
• Ergebnisse der Abhängigkeits- und Geheimnisscans;
• Ergebnisse automatisierter Tests;
• das ausgefüllte Protokoll der manuellen Abnahme;
• Verfahren für die Rotation von Zugangsdaten und für Vorfälle.

Fügen Sie niemals aktive Codes, Tokens, Client Secrets, private Schlüssel, unbearbeitete UserInfo-Antworten oder Kunden-Payloads als Nachweise bei.

Beobachtbarkeit

Zeichnen Sie genügend Informationen zur Fehlerdiagnose auf, ohne Zugangsdaten oder personenbezogene Daten zu erfassen:

• vom Partner erzeugte Korrelations-ID;
• Umgebung und Integrationsrichtung;
• Vorgangsname;
• Kategorie des vorgelagerten Endpunkts, nicht dessen Abfrageparameter;
• HTTP-Status und sicherer OAuth-Fehlercode;
• Dauer und Anzahl der Wiederholungsversuche;
• bereinigte Ressourcenanzahl, sofern betrieblich nützlich.

Protokollieren Sie keine Autorisierungscodes, Zugriffstokens, Refresh-Tokens, ID-Tokens, Client Secrets, State- oder Nonce-Werte, PKCE-Verifier, vollständigen Redirect-URLs, E-Mail-Adressen oder Payloads von Parcoursentwürfen.

Warnmeldungen sollten zwischen Authentifizierungsfehlern, Autorisierungsfehlern, Partnerausfällen, Latenz, Schemafehlern und anhaltender Ratenbegrenzung unterscheiden.

Produktionsreife

Bevor produktive Zugangsdaten ausgegeben werden, müssen beide Teams Folgendes genehmigen:

• den exakten Produktions-Issuer und die exakte Redirect-URI;
• Client-Authentifizierung und verantwortliche Person für die Zugangsdaten;
• Scopes und zugängliche Ressourcen;
• erwartetes Volumen und aktuelle API-Limits;
• Verhalten bei Datenschutz, Aufbewahrung, Aufhebung der Verknüpfung und Löschung;
• Regeln für Timeout, Wiederholung, Idempotenz und Teilerfolg;
• Monitoring und Eskalation von Vorfällen;
• Supportanweisungen für Benutzer;
• Verfahren für Rollback oder Deaktivierung der Integration;
• Zeitfenster und verantwortliche Person für den Smoke-Test in der Produktionsumgebung.

Verwenden Sie für Test und Produktion unterschiedliche Client-Zugangsdaten. Übermitteln Sie diese über den genehmigten sicheren Kanal und überprüfen Sie die Rotation vor der Inbetriebnahme.

Smoke-Test in der Produktionsumgebung

Begrenzen Sie den ersten Produktionstest auf einen kleinen Umfang:

1. ein genehmigtes internes Konto autorisieren;
2. das ID-Token validieren und UserInfo abrufen;
3. die Veranstaltungsliste anfordern;
4. die Entwurfszusammenfassungen einer bekannten Veranstaltung anfordern;
5. Benutzerisolierung und erwartete Felder prüfen;
6. einmal aktualisieren und das Ersatz-Token dauerhaft speichern;
7. die Verbindung trennen und lokal gespeicherte Zugangsdaten entfernen;
8. bereinigte Protokolle und Warnmeldungen prüfen;
9. das Ergebnis dokumentieren und entscheiden, ob ein breiterer Zugriff aktiviert werden soll.

Testen Sie in der Produktionsumgebung kein destruktives Verhalten und kein Verhalten mit hohem Volumen, sofern es nicht ausdrücklich Bestandteil des genehmigten Inbetriebnahmeverfahrens ist.

Abnahmeprotokoll

Dokumentieren Sie für jedes Szenario:

• Umgebung und Build-Version;
• für den Test verantwortliche Person und Datum;
• anonymisierte Identität des Test-Fixtures;
• erwartetes Ergebnis;
• tatsächliches Ergebnis;
• Speicherort der Nachweise;
• Fehler oder akzeptierte Einschränkung;
• für die Genehmigung verantwortliche Person.

Eine nicht dokumentierte Einschränkung ist keine akzeptierte Einschränkung. Nehmen Sie ungelöste Vertrags- oder Sicherheitsprobleme in die Inbetriebnahmeentscheidung auf, bevor Sie den Produktionszugriff aktivieren.