PKCE: zabezpieczanie klientów publicznych

Bez PKCE aplikacje mobilne są podatne na ataki polegające na przechwyceniu kodu autoryzacyjnego. Gdy serwer autoryzacji przekierowuje kod autoryzacyjny do zarejestrowanego przez aplikację niestandardowego schematu URI, na przykład myapp://callback, dowolna złośliwa aplikacja na tym samym urządzeniu, która zarejestruje ten sam schemat URI, może przechwycić przekierowanie i ukraść kod.

Atak przebiega następująco: złośliwa aplikacja rejestruje ten sam niestandardowy schemat URI co prawidłowa aplikacja. Gdy serwer autoryzacji przekierowuje kod do myapp://callback, system operacyjny może wyświetlić obie aplikacje jako programy obsługujące ten schemat. Jeśli użytkownik wybierze złośliwą aplikację lub system operacyjny ustawi ją jako domyślną, atakujący otrzyma kod autoryzacyjny i będzie mógł wymienić go na tokeny bez znajomości sekretu klienta.

PKCE (RFC 7636) dodaje dynamicznie generowany sekret do przepływu kodu autoryzacji. Przed rozpoczęciem przepływu klient generuje kryptograficznie losowy ciąg o długości od 43 do 128 znaków, nazywany weryfikatorem kodu. Ciąg ten jest unikatowy dla każdego żądania autoryzacji i nie jest przesyłany aż do etapu wymiany tokenu.

Klient oblicza wyzwanie kodu na podstawie weryfikatora: code_challenge = BASE64URL(SHA256(code_verifier)). Użycie SHA256 jest metodą wymaganą przez RFC 7636; metoda "plain", która przesyła weryfikator bezpośrednio, nie jest zalecana. Wyzwanie kodu jest jednokierunkowym przekształceniem weryfikatora, co oznacza, że znajomość wyzwania nie ujawnia weryfikatora.

Żądanie autoryzacji zawiera dwa dodatkowe parametry: "code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256". Serwer autoryzacji przechowuje wyzwanie kodu powiązane z wydanym kodem autoryzacyjnym. Na tym etapie do serwera nie jest przesyłany żaden sekret, który można przechwycić.

Podczas wymiany tokenu (żądanie POST do punktu końcowego tokenu) klient dołącza "code_verifier=ORIGINAL_RANDOM_STRING" wraz z kodem autoryzacyjnym. Serwer autoryzacji oblicza BASE64URL(SHA256(code_verifier)) i sprawdza, czy wynik jest zgodny z zapisanym code_challenge. Tę kontrolę może przejść wyłącznie prawidłowy klient, który wygenerował weryfikator.

Jeśli atakujący przechwyci kod autoryzacyjny, otrzyma tylko kod i wyzwanie kodu, które jest publiczne. Aby wymienić kod na tokeny, musi podać weryfikator kodu. Ponieważ weryfikator został wygenerowany przez prawidłowego klienta i nie był przesyłany aż do etapu wymiany tokenu, który odbywa się bezpiecznie, atakujący nie może go obliczyć ani odzyskać.

PKCE zapobiega również atakom polegającym na wstrzyknięciu kodu autoryzacyjnego, w których napastnik zastępuje prawidłowy kod skradzionym kodem w przekierowaniu. Wyzwanie skradzionego kodu nie odpowiada wartości code verifier, którą klient ofiary przedstawi, przez co wymiana tokenu kończy się niepowodzeniem. PKCE zapewnia dodatkową warstwę ochrony przed wieloma wektorami ataku jednocześnie.

Chociaż dokument RFC 7636 początkowo opisywał PKCE jako rozwiązanie dla klientów publicznych (czyli takich, które nie mają sekretów klienta), OAuth Security BCP i OAuth 2.1 wymagają stosowania PKCE przez wszystkich klientów, także klientów poufnych mających sekrety klienta. PKCE zapewnia ochronę niezależną od uwierzytelniania klienta, dlatego jest korzystne w każdym przypadku.

OAuth 2.1 (draft-ietf-oauth-v2-1) konsoliduje najlepsze praktyki bezpieczeństwa z OAuth 2.0 Security BCP w jednym dokumencie. Wymaga stosowania PKCE we wszystkich przepływach z kodem autoryzacyjnym, wycofuje przepływ niejawny i wymaga rotacji refresh tokenów. PKCE jest w praktyce wymaganym poziomem bazowym każdej nowej implementacji OAuth 2.0.

Poprawna implementacja PKCE wymaga: użycia kryptograficznie bezpiecznego generatora losowego do wygenerowania wartości code verifier (co najmniej 32 losowych bajtów, następnie zakodowanych w base64url), bezpiecznego przechowywania code verifier po stronie klienta (nie w adresie URL ani w logach), użycia metody S256 (nie plain) oraz usunięcia code verifier po wymianie tokenu. Większość nowoczesnych bibliotek OAuth obsługuje PKCE automatycznie.

W PKCE jaka jest zależność między code verifier a code challenge?

PKCE (RFC 7636) zapobiega przechwyceniu kodu autoryzacyjnego, wiążąc każdy kod z dynamicznie wygenerowaną wartością code verifier znaną tylko prawidłowemu klientowi. Wartość code verifier jest haszowana w celu uzyskania code challenge (przesyłanego publicznie). Wymiana tokenu wymaga oryginalnej wartości code verifier. PKCE zapobiega zarówno przechwytywaniu, jak i wstrzykiwaniu kodów. OAuth 2.1 wymaga stosowania PKCE we wszystkich przepływach z kodem autoryzacyjnym.