Testowanie i uruchomienie

Przed wydaniem produkcyjnych danych uwierzytelniających przetestuj kompletną integrację w środowisku testowym Parkour Design. Testy automatyczne potwierdzają działanie protokołu i zgodność z kontraktem, a odbiór manualny weryfikuje ścieżkę użytkownika i odtwarzanie działania po awarii.

Warunek uruchomienia: Pomyślne wywołanie zwrotne autoryzacji nie wystarcza do odbioru integracji. Uruchomienie wymaga walidacji tożsamości, izolacji użytkowników, rotacji tokenów, testów kontraktu zasobów, odtwarzania działania po awarii oraz zatwierdzenia przez oba zespoły.

Wymagania wstępne do testów

Parkour Design i partner muszą przygotować:

• zarejestrowanego klienta testowego i sekret przekazany w bezpieczny sposób;
• dokładny testowy adres URI przekierowania;
• zatwierdzony zestaw zakresów uprawnień;
• co najmniej dwóch użytkowników testowych Parkour Design;
• Wydarzenia i projekty należące oddzielnie do każdego użytkownika;
• jedno puste konto lub Wydarzenie, jeśli ma to zastosowanie;
• osoby do kontaktu w sprawach technicznych i incydentów;
• oczekiwane wyniki każdego przypadku odbioru.

Użyj testowego wystawcy:

https://parkour-test.web.app

Nie używaj ponownie testowych danych uwierzytelniających, adresów URL wywołań zwrotnych, tokenów ani danych użytkowników w środowisku produkcyjnym.

Kontrole wstępne

Discovery

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

Sprawdź, czy:

• issuer jest dokładnie równy skonfigurowanemu testowemu wystawcy;
• endpointy authorization, token, UserInfo i JWKS używają HTTPS;
• obecne są wartości code, authorization_code, refresh_token, RS256 i S256;
• dokument discovery nie zawiera sekretu klienta ani prywatnej wartości właściwej dla danego środowiska.

Klucze podpisujące

Pobierz jwks_uri z dokumentu discovery i sprawdź, czy każdy klucz, którego można użyć, ma kid, kty, zastosowanie do podpisu i zatwierdzony algorytm. Po napotkaniu nieznanego kid klient musi jednokrotnie odświeżyć JWKS, zanim odrzuci token.

Nieuwierzytelnione żądanie zasobu

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

Oczekiwany wynik:

HTTP/2 401
Content-Type: application/json

{"error":"invalid_token"}

Automatyczne testy OAuth

Zautomatyzuj te przypadki na granicy systemu partnera. Używaj kontrolowanych danych testowych, a zewnętrzny krok wykonywany w przeglądarce zastępuj atrapą tylko wtedy, gdy pełny test przeglądarkowy jest niepraktyczny.

Żądanie autoryzacji

• zawiera dokładny identyfikator klienta, adres URI przekierowania i zatwierdzone zakresy uprawnień;
• generuje unikalne wartości state, nonce i weryfikatora PKCE o wysokiej entropii;
• wysyła code_challenge_method=S256;
• nie umieszcza sekretu klienta ani weryfikatora w adresie URL;
• podczas negatywnego testu środowiska odrzuca niezarejestrowany lub nieznacznie różniący się adres URI przekierowania.

Wywołanie zwrotne

• jednokrotnie akceptuje prawidłową wartość state;
• odrzuca brakującą, niezgodną, wygasłą i ponownie użytą wartość state;
• obsługuje access_denied bez wymiany kodu;
• odrzuca brak kodu w wywołaniu zwrotnym, które poza tym wskazuje na powodzenie;
• zachowuje wyłącznie zweryfikowaną lokalną ścieżkę powrotu;
• nie ujawnia przeglądarce diagnostyki protokołu ani danych osobowych.

Wymiana kodu

• uwierzytelnia za pomocą client_secret_basic;
• używa tego samego adresu URI przekierowania co żądanie autoryzacji;
• wysyła pierwotny weryfikator PKCE;
• odrzuca kody wygasłe, ponownie użyte, wystawione dla innego klienta oraz powiązane z nieprawidłowym weryfikatorem;
• traktuje odpowiedzi zawierające tokeny jako dane niepodlegające buforowaniu i przechowuje je po stronie serwera.

Walidacja tokena ID

Odrzucaj tokeny z:

• nieprawidłowym podpisem;
• nieznanym kluczem podpisującym po jednokrotnym odświeżeniu JWKS;
• nieprawidłowym wystawcą;
• nieprawidłowym odbiorcą;
• algorytmem innym niż RS256;
• brakującą lub nieprawidłową wartością nonce;
• wygasłymi lub niewiarygodnymi atrybutami czasowymi;
• brakującym identyfikatorem podmiotu.

Sprawdź, czy łączenie kont używa pary iss i sub, a nie wyłącznie adresu e-mail.

Rotacja tokenów odświeżania

• prawidłowy token odświeżania zwraca nowy token dostępu i zastępczy token odświeżania;
• zastępczy token jest zapisywany atomowo;
• operacje odświeżania są serializowane dla każdej sesji użytkownika i klienta;
• ponowne użycie starego tokena odświeżania jest odrzucane;
• token wystawiony innemu klientowi jest odrzucany;
• wygasły token wymaga rozpoczęcia nowego przepływu autoryzacji;
• przekroczenie limitu czasu lub utrata odpowiedzi odświeżania o nieznanym wyniku powoduje usunięcie lokalnego stanu tokenów i rozpoczęcie nowego przepływu autoryzacji zamiast ponowienia żądania ze starym tokenem;
• równoczesne próby odświeżenia nie mogą konkurować o użycie tego samego tokena;
• lokalne rozłączenie usuwa aktywny token odświeżania i dane sesji.

Parkour Design nie ma obecnie publicznego endpointu unieważniania tokenów. Testy nie mogą przedstawiać lokalnego usunięcia jako unieważnienia po stronie serwera.

Automatyczne testy zasobów

Uwierzytelnianie i izolacja

• brak tokena zwraca 401 invalid_token;
• wygasły lub nieprawidłowo sformatowany token zwraca 401 invalid_token;
• token ID użyty jako token bearer API jest odrzucany;
• użytkownik A widzi tylko Wydarzenia i projekty użytkownika A;
• użytkownik B nie może pobrać Wydarzenia użytkownika A przez skopiowanie jego identyfikatora;
• zarówno niedostępne, jak i nieistniejące Wydarzenia zwracają 404 not_found.

Kontrakt schematu

Waliduj każdą odpowiedź względem danych testowych schematu należących do partnera:

• wymagane właściwości są obecne;
• właściwości dopuszczające wartość null akceptują null;
• daty są analizowane jako wartości ISO 8601;
• nieznane właściwości dodatkowe nie zakłócają działania klienta;
• puste kolekcje zwracają pustą tablicę items;
• identyfikatory są traktowane jako nieprzezroczyste ciągi znaków;
• tekst obsługuje Unicode i jest bezpiecznie renderowany.

Nie odtwarzaj kompletnego projektu parkuru na podstawie schematu podsumowania.

Limity i błędy

• klient obsługuje największą zatwierdzoną listę Wydarzeń;
• obecny limit 500 projektów w danych szczegółowych jest uwzględniony w ocenie ryzyka związanego z uruchomieniem;
• odpowiedzi 401, 404, 405, 429 i 5xx są obsługiwane zgodnie z uzgodnionymi zasadami ponawiania prób;
• przekroczenia limitu czasu nie powodują nieograniczonego ponawiania prób;
• nieprawidłowo sformatowany JSON powoduje bezpieczne zakończenie operacji i zapisanie oczyszczonych danych diagnostycznych;
• powtarzane idempotentne żądania GET nie modyfikują stanu partnera.

Testy eksportu z Parkour Design do partnera

Gdy Parkour Design wysyła dane do partnera, dodaj dwustronne testy kontraktowe obejmujące:

• wyświetlanie listy miejsc docelowych i walidację identyfikatorów;
• dostarczenie wyłącznie pliku;
• dostarczenie wyłącznie danych ustrukturyzowanych;
• pomyślne dostarczenie wszystkich części;
• każdą możliwą kombinację częściowego powodzenia;
• nieprawidłowo sformatowane dane ustrukturyzowane;
• puste i zbyt duże pliki;
• odpowiedzi partnera 401, 403, 404, 409, 413, 429 i 5xx;
• przekroczenie limitu czasu połączenia i limitu czasu odpowiedzi;
• wielokrotne przesłanie tych samych danych i zachowanie związane z idempotencją;
• rozłączenie, ponowne połączenie i wygaśnięcie tokena.

Odbiór manualny

Wykonaj poniższe czynności w rzeczywistej przeglądarce, korzystając z hostowanego środowiska testowego.

Powtórz podstawowy przepływ w każdym obsługiwanym języku interfejsu użytkownika. Wartości protokołu muszą pozostać niezmienione, a komunikaty przeznaczone dla użytkownika muszą być zlokalizowane.

Materiały do przeglądu bezpieczeństwa

Przekaż osobom przeprowadzającym przegląd:

• diagram przepływu danych przedstawiający przeglądarkę, oba backendy, dostawcę tożsamości, interfejsy API i magazyn tokenów;
• listy dozwolonych adresów URI przekierowań i źródeł (origins);
• żądane zakresy uprawnień i mapowanie zasobów;
• konfigurację szyfrowania i retencji tokenów;
• konfigurację walidacji tokena ID;
• oczyszczone przykłady logów i alertów;
• wyniki skanowania zależności i sekretów;
• wyniki testów automatycznych;
• uzupełniony protokół odbioru manualnego;
• procedury rotacji danych uwierzytelniających i obsługi incydentów.

Nigdy nie załączaj jako materiałów dowodowych aktywnych kodów, tokenów, sekretów klienta, kluczy prywatnych, nieprzetworzonych odpowiedzi UserInfo ani danych klientów.

Obserwowalność

Zapisuj informacje wystarczające do diagnozowania błędów, nie rejestrując danych uwierzytelniających ani danych osobowych:

• identyfikator korelacji wygenerowany przez partnera;
• środowisko i kierunek integracji;
• nazwa operacji;
• kategoria endpointu systemu nadrzędnego, bez parametrów zapytania;
• status HTTP i bezpieczny kod błędu OAuth;
• czas trwania i liczba ponowień;
• oczyszczona liczba zasobów, jeśli jest przydatna operacyjnie.

Nie zapisuj w logach kodów autoryzacyjnych, tokenów dostępu, tokenów odświeżania, tokenów ID, sekretów klienta, wartości state, nonce, weryfikatora PKCE, pełnych adresów URL przekierowań, adresów e-mail ani danych projektu parkuru.

Alerty powinny rozróżniać błędy uwierzytelniania, błędy autoryzacji, awarie partnera, opóźnienia, błędy schematu i utrzymujące się ograniczanie liczby żądań.

Gotowość produkcyjna

Przed wydaniem produkcyjnych danych uwierzytelniających oba zespoły muszą zatwierdzić:

• dokładnego produkcyjnego wystawcę i adres URI przekierowania;
• sposób uwierzytelniania klienta i właściciela danych uwierzytelniających;
• zakresy uprawnień i dostępne zasoby;
• oczekiwany wolumen i obecne limity API;
• zasady dotyczące prywatności, retencji, odłączania i usuwania danych;
• zasady dotyczące limitu czasu, ponawiania prób, idempotencji i częściowego powodzenia;
• monitoring i eskalację incydentów;
• instrukcje wsparcia przeznaczone dla użytkowników;
• procedurę wycofania zmian lub wyłączenia integracji;
• termin produkcyjnego testu poprawności działania i osobę za niego odpowiedzialną.

Używaj innych danych uwierzytelniających klienta w środowiskach testowym i produkcyjnym. Przekaż je zatwierdzonym bezpiecznym kanałem i zweryfikuj rotację przed uruchomieniem.

Produkcyjny test poprawności działania

Ogranicz zakres pierwszego testu produkcyjnego:

1. autoryzuj jedno zatwierdzone konto wewnętrzne;
2. zweryfikuj token ID i pobierz UserInfo;
3. zażądaj listy Wydarzeń;
4. zażądaj podsumowań projektów dla jednego znanego Wydarzenia;
5. zweryfikuj izolację użytkowników i oczekiwane pola;
6. jednokrotnie odśwież token i zapisz token zastępczy;
7. rozłącz integrację i usuń lokalnie przechowywane dane uwierzytelniające;
8. sprawdź oczyszczone logi i alerty;
9. zapisz wynik i zdecyduj, czy włączyć szerszy dostęp.

Nie testuj w środowisku produkcyjnym operacji destrukcyjnych ani generujących duży ruch, chyba że stanowią one jawny element zatwierdzonej procedury uruchomienia.

Protokół odbioru

Dla każdego scenariusza zapisz:

• środowisko i wersję kompilacji;
• osobę odpowiedzialną za test i datę;
• zanonimizowaną tożsamość danych testowych;
• oczekiwany wynik;
• rzeczywisty wynik;
• lokalizację materiałów dowodowych;
• błąd lub zaakceptowane ograniczenie;
• osobę odpowiedzialną za zatwierdzenie.

Nieudokumentowane ograniczenie nie jest ograniczeniem zaakceptowanym. Przed włączeniem dostępu produkcyjnego uwzględnij nierozwiązane problemy z kontraktem lub bezpieczeństwem w decyzji o uruchomieniu.