0Pricing
Frontend Academy · Lektion

OAuth-Flows im Frontend

Implementieren Sie den Authorization-Code-Flow mit PKCE in einer SPA, tauschen Sie den Code gegen Tokens ein, speichern Sie Access-Tokens sicher und vermeiden Sie den Implicit Flow.

OAuth-Flows im Frontend ist eine kostenlose Frontend Academy-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Frontend Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Frontend Academy-Kurs umfasst insgesamt 4 Lektionen.

Was ist OAuth?

OAuth 2.0 ist ein Delegationsprotokoll: Ihre Anwendung erhält die Erlaubnis, im Namen des Benutzers bei einem Drittanbieterdienst (Google, GitHub usw.) zu handeln, ohne jemals das Passwort des Benutzers zu sehen. Es wird für „Sign in with Google“, GitHub-OAuth-Apps und die meisten modernen Authentifizierungslösungen verwendet.

Zentrale Rollen

Resource Owner: der Benutzer. Client: Ihre Anwendung. Authorization Server: der OAuth-Anbieter (Google, Auth0). Resource Server: die durch das Access-Token geschützte API.

Der Authorization-Code-Flow

Der standardmäßige, sichere Flow für serverseitige Anwendungen: 1) Leiten Sie den Benutzer zur Anmeldung beim Anbieter weiter. 2) Der Benutzer meldet sich an und erteilt seine Zustimmung. 3) Der Anbieter leitet mit einem code zurück. 4) Der Server tauscht den Code gegen ein access token (ein ausschließlich serverseitiges Geheimnis) aus.

Warum PKCE für SPAs?

SPAs können kein Client-Geheimnis sicher verwahren, da es sich im Browser-Bundle befinden würde. PKCE (Proof Key for Code Exchange) ersetzt das Geheimnis durch einen Code-Verifier und eine Challenge pro Anfrage. PKCE ist inzwischen der Standard für alle öffentlichen OAuth-Clients.

Der PKCE-Flow Schritt für Schritt

1) Erzeugen Sie einen zufälligen code_verifier. 2) Berechnen Sie daraus den SHA-256-Hash = code_challenge. 3) Leiten Sie mit der Challenge an /authorize weiter. 4) Nach der Zustimmung erhalten Sie einen Code zurück. 5) Tauschen Sie Code und Verifier gegen ein Access-Token aus. Der Anbieter prüft, ob Challenge = hash(Verifier) gilt.

Code-Verifier und Challenge erzeugen

Der Verifier ist eine zufällige Zeichenkette; die Challenge ist die Base64-URL-kodierte SHA-256-Darstellung davon.

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 };
}

Zum Anbieter weiterleiten

Erstellen Sie die Authorize-URL mit der Challenge, dem State (CSRF-Schutz) und den Scopes.

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();

Den Callback verarbeiten

Der Anbieter leitet mit ?code=...&state=... an Ihre Callback-URL weiter. Prüfen Sie den State, um CSRF zu verhindern, und tauschen Sie anschließend den Code aus.

// /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 }

Tokens sicher speichern

Best Practice: Speichern Sie Access-Tokens nicht in localStorage, da sie dort durch XSS gestohlen werden können. Optionen: 1) Nur im Speicher (wird beim Aktualisieren gelöscht — eine erneute Authentifizierung ist erforderlich). 2) HttpOnly-Cookie (wird von Ihrem Backend nach dem PKCE-Flow gesetzt und kann nicht von JavaScript gestohlen werden).

Verzichten Sie auf den Implicit-Flow

Der alte Implicit-Flow gibt das Access-Token direkt im URL-Fragment zurück. Er ist durch das OAuth 2.0 Security BCP veraltet — Tokens können in Browserverlauf und Referrern offengelegt werden. Verwenden Sie immer Authorization Code + PKCE.

Refresh-Tokens

Access-Tokens laufen ab (typischerweise nach einer Stunde). Ein länger gültiges Refresh-Token ruft unbemerkt neue Access-Tokens ab. Bei SPAs werden Refresh-Tokens zunehmend über HttpOnly-Cookies bereitgestellt — niemals über localStorage.

ID-Tokens und Access-Tokens

ID-Token (OpenID Connect): ein JWT, das die Identität des Benutzers bestätigt. Access-Token: ein undurchsichtiges Token oder JWT, das zum Aufrufen von APIs verwendet wird. Prüfen Sie Signatur und Claims des ID-Tokens (iss, aud, exp, nonce), bevor Sie ihm vertrauen.

Auth-Bibliotheken

Entwickeln Sie keine eigene Lösung. Verwenden Sie: oidc-client-ts für reines OIDC, auth0/spa-js für Auth0, @clerk/clerk-react für Clerk, NextAuth.js/Auth.js für Next und Nuxt-auth für Nuxt. Diese Bibliotheken übernehmen PKCE, Refresh und Speicherung.

Kurztest

Warum müssen Single-Page-Anwendungen PKCE (Proof Key for Code Exchange) mit dem Authorization-Code-Flow verwenden, statt nur den einfachen Authorization-Code-Flow einzusetzen?

Zusammenfassung: OAuth im Frontend

Authorization Code + PKCE ist der moderne Standard für SPAs. Erzeugen Sie pro Anfrage einen Verifier und eine S256-Challenge. Leiten Sie mit Challenge + State an /authorize weiter. Prüfen Sie den State beim Callback. Tauschen Sie Code + Verifier gegen Tokens aus. Verwenden Sie niemals den Implicit-Flow. Bevorzugen Sie HttpOnly-Cookies für die Token-Speicherung. Verwenden Sie Bibliotheken (auth0-spa-js, oidc-client-ts, NextAuth) — entwickeln Sie keine eigene Lösung.

Häufig gestellte Fragen

Ist die Lektion „OAuth-Flows im Frontend“ kostenlos?

Ja — der vollständige Text von „OAuth-Flows im Frontend“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Frontend Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Frontend Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „OAuth-Flows im Frontend“?

Implementieren Sie den Authorization-Code-Flow mit PKCE in einer SPA, tauschen Sie den Code gegen Tokens ein, speichern Sie Access-Tokens sicher und vermeiden Sie den Implicit Flow. Du übst Frontend Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Frontend Academy zu starten?

Keine Vorkenntnisse erforderlich. Frontend Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „OAuth-Flows im Frontend“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Frontend Academy-Lektion Code schreiben und ausführen?

Ja. Jede Frontend Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. XSS-Schutz: Ausgabekodierung und CSP
  2. CSRF: SameSite-Cookies und Tokens
  3. Content Security Policy: Nonce und Hash
  4. OAuth-Flows im Frontend
← Zurück zu Frontend Academy