Przepływy OAuth po stronie frontendu
Zaimplementuje Pan/Pani przepływ Authorization Code z PKCE w SPA, wymieni kod na tokeny, bezpiecznie przechowa tokeny dostępu i uniknie implicit flow.
Przepływy OAuth po stronie frontendu to bezpłatna lekcja Frontend Academy na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Frontend Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Frontend Academy zawiera 4 lekcji w sumie.
Czym jest OAuth?
OAuth 2.0 to protokół delegowania uprawnień: aplikacja otrzymuje zgodę na działanie w imieniu użytkownika w usłudze innej firmy (Google, GitHub itd.), nigdy nie uzyskując dostępu do jego hasła. Jest używany między innymi w funkcji „Zaloguj się przez Google”, aplikacjach OAuth GitHub i większości nowoczesnych systemów uwierzytelniania.
Najważniejsze role
Właściciel zasobu: użytkownik. Klient: Państwa aplikacja. Serwer autoryzacji: dostawca OAuth (Google, Auth0). Serwer zasobów: interfejs API chroniony tokenem dostępu.
Przepływ kodu autoryzacji
Standardowy, bezpieczny przepływ dla aplikacji działających po stronie serwera: 1) Przekierowanie użytkownika do logowania u dostawcy. 2) Użytkownik loguje się i wyraża zgodę. 3) Dostawca przekierowuje użytkownika z powrotem wraz z kodem. 4) Serwer wymienia kod na token dostępu (tajemnica przechowywana wyłącznie na serwerze).
Dlaczego PKCE jest potrzebne w SPA
SPA nie mogą bezpiecznie przechowywać sekretu klienta (znajdowałby się on w paczce przeglądarkowej). PKCE (Proof Key for Code Exchange) zastępuje sekret generowanym dla każdego żądania weryfikatorem i wyzwaniem kodu. Obecnie jest to standard w przypadku wszystkich publicznych klientów OAuth.
Przepływ PKCE krok po kroku
1) Należy wygenerować losowy code_verifier. 2) Obliczyć jego hash SHA-256 = code_challenge. 3) Przekierować użytkownika do /authorize z wyzwaniem. 4) Po wyrażeniu zgody odebrać kod. 5) Wymienić kod + weryfikator na token dostępu. Dostawca sprawdza, czy wyzwanie jest równe hashowi(weryfikatora).
Generowanie weryfikatora i wyzwania kodu
Weryfikator jest losowym ciągiem znaków, a wyzwanie to jego hash SHA-256 zakodowany w formacie base64-URL.
function base64url(arr) {
return btoa(String.fromCharCode(...arr))
.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
}
async function generatePKCE() {
const arr = new Uint8Array(32);
crypto.getRandomValues(arr);
const verifier = base64url(arr);
const hash = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(verifier));
const challenge = base64url(new Uint8Array(hash));
return { verifier, challenge };
}Przekierowanie do dostawcy
Należy zbudować URL autoryzacji zawierający wyzwanie, parametr state (ochrona CSRF) oraz zakresy uprawnień.
const { verifier, challenge } = await generatePKCE();
const state = crypto.randomUUID();
sessionStorage.setItem('pkce_verifier', verifier);
sessionStorage.setItem('oauth_state', state);
const url = new URL('https://accounts.google.com/o/oauth2/v2/auth');
url.searchParams.set('client_id', CLIENT_ID);
url.searchParams.set('redirect_uri', `${origin}/auth/callback`);
url.searchParams.set('response_type', 'code');
url.searchParams.set('scope', 'openid email profile');
url.searchParams.set('code_challenge', challenge);
url.searchParams.set('code_challenge_method', 'S256');
url.searchParams.set('state', state);
window.location.href = url.toString();Obsługa wywołania zwrotnego
Dostawca przekierowuje użytkownika do Państwa URL wywołania zwrotnego z parametrami ?code=...&state=.... Należy zweryfikować parametr state, aby zapobiec CSRF, a następnie wymienić kod.
// /auth/callback page:
const params = new URLSearchParams(window.location.search);
const code = params.get('code');
const returnedState = params.get('state');
const expected = sessionStorage.getItem('oauth_state');
if (returnedState !== expected) throw new Error('Bad state');
const verifier = sessionStorage.getItem('pkce_verifier');
const tokens = await fetch('https://oauth2.googleapis.com/token', {
method: 'POST',
headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
body: new URLSearchParams({
grant_type: 'authorization_code',
code,
client_id: CLIENT_ID,
redirect_uri: `${origin}/auth/callback`,
code_verifier: verifier
})
}).then(r => r.json());
// tokens: { access_token, id_token, refresh_token, expires_in }Bezpieczne przechowywanie tokenów
Najlepsza praktyka: nie należy przechowywać tokenów dostępu w localStorage (mogą zostać skradzione przez XSS). Dostępne opcje: 1) Wyłącznie w pamięci (pamięć jest czyszczona podczas odświeżenia — wymagane jest ponowne uwierzytelnienie). 2) Ciasteczko HttpOnly (ustawiane przez Państwa backend po zakończeniu przepływu PKCE, niedostępne dla JavaScriptu).
Należy unikać przepływu niejawnego
Stary przepływ niejawny zwraca token dostępu bezpośrednio we fragmencie URL. Został wycofany przez OAuth 2.0 Security BCP, ponieważ tokeny wyciekają do historii przeglądarki i nagłówków referrer. Zawsze należy używać kodu autoryzacji + PKCE.
Tokeny odświeżania
Tokeny dostępu wygasają (zwykle po 1 godzinie). Token odświeżania (ważny dłużej) umożliwia po cichu uzyskiwać nowe tokeny dostępu. W przypadku SPA tokeny odświeżania są coraz częściej dostarczane za pomocą ciasteczek HttpOnly — nigdy przez localStorage.
Tokeny ID a tokeny dostępu
Token ID (OpenID Connect): JWT potwierdzający tożsamość użytkownika. Token dostępu: nieprzejrzysty token lub JWT używany do wywoływania interfejsów API. Przed zaufaniem tokenowi ID należy zweryfikować jego podpis i deklaracje (iss, aud, exp, nonce).
Biblioteki uwierzytelniania
Nie należy implementować tego samodzielnie. Należy używać: oidc-client-ts dla surowego OIDC, auth0/spa-js dla Auth0, @clerk/clerk-react dla Clerk, NextAuth.js/Auth.js dla Next oraz Nuxt-auth dla Nuxt. Biblioteki te obsługują PKCE, odświeżanie i przechowywanie danych.
Szybkie sprawdzenie
Dlaczego aplikacje jednostronicowe muszą używać PKCE (Proof Key for Code Exchange) wraz z przepływem kodu autoryzacji, zamiast korzystać tylko z podstawowego przepływu kodu autoryzacji?
Podsumowanie: OAuth w frontendzie
Kod autoryzacji + PKCE to nowoczesny standard dla SPA. Dla każdego żądania należy generować weryfikator + wyzwanie S256. Należy przekierować użytkownika do /authorize z wyzwaniem + parametrem state. Przy wywołaniu zwrotnym należy zweryfikować parametr state. Następnie należy wymienić kod + weryfikator na tokeny. Nigdy nie należy używać przepływu niejawnego. Do przechowywania tokenów preferowane są ciasteczka HttpOnly. Należy używać bibliotek (auth0-spa-js, oidc-client-ts, NextAuth) — nie implementować tego samodzielnie.
Ucz się HTML dzięki korepetycjom AI — za darmo
Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.
- Kursy
- 41
- Lekcje
- 163
Często zadawane pytania
Czy lekcja „Przepływy OAuth po stronie frontendu” jest bezpłatna?
Tak — pełny tekst „Przepływy OAuth po stronie frontendu” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Frontend Academy, przejdź na CoddyKit PRO. Kurs Frontend Academy zawiera 4 lekcji w sumie.
Co nauczysz się w „Przepływy OAuth po stronie frontendu”?
Zaimplementuje Pan/Pani przepływ Authorization Code z PKCE w SPA, wymieni kod na tokeny, bezpiecznie przechowa tokeny dostępu i uniknie implicit flow. Ćwiczysz Frontend Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć Frontend Academy?
Nie wymagamy żadnego doświadczenia. Frontend Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.
Ile czasu zajmuje lekcja „Przepływy OAuth po stronie frontendu”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji Frontend Academy?
Tak. Każda lekcja Frontend Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Zapobieganie XSS: kodowanie danych wyjściowych i CSP
- CSRF: pliki cookie SameSite i tokeny
- Content Security Policy: nonce i hash
- Przepływy OAuth po stronie frontendu