Google-Login einbinden: OAuth und SSO für Websites

„Mit Google anmelden“ wird über OAuth 2.0 und dessen Identitätsschicht OpenID Connect (OIDC) in eine Website oder App eingebunden. Kurz gesagt: Der Nutzer wird zu Google weitergeleitet, Google prüft die Identität und schickt Ihrer Website ein signiertes ID-Token; Ihr Server prüft Signatur und Empfänger des Tokens, ordnet den Nutzer Ihren eigenen Datensätzen zu und eröffnet eine eigene Sitzung. Ihre Website sieht und speichert das Google-Passwort nie. Die technische Einrichtung geht schnell; was das Projekt verlängert, sind Kontoverknüpfung, Sitzungsverwaltung und die Single-Sign-on-Anforderungen (SSO) von Geschäftskunden. Dieser Beitrag beschreibt den Ablauf, den wir in Unternehmensprojekten umsetzen; er ist der Authentifizierungsteil unserer Webentwicklung.

OAuth, OpenID Connect und SSO: was ist was?

Die drei Begriffe werden im Alltag synonym verwendet, beantworten aber drei verschiedene Fragen. OAuth 2.0 ist ein Protokoll zur Rechtedelegation: Es sagt „diese App darf in meinem Namen meinen Kalender lesen“, nicht wer Sie sind. OpenID Connect ist die Identitätsschicht darüber: Ein signiertes ID-Token transportiert „dieser Nutzer ist diese Identität, die E-Mail ist bestätigt“. Google-Login ist in der Praxis OpenID Connect. SSO (Single Sign-on) ist ein Architekturziel: Der Nutzer meldet sich einmal an und erreicht mehrere Anwendungen ohne weiteres Passwort. Es gibt zwei unterschiedliche Bedarfe:

• Social Login (B2C): Ihre Kunden registrieren sich und melden sich mit einem Google-, Apple- oder Microsoft-Konto an. Ziel sind weniger Reibung und keine eigene Passwortverwaltung.
• Enterprise-SSO (B2B / interne Anwendungen): Mitarbeiter melden sich über den Identitätsanbieter des Unternehmens an (Google Workspace, Microsoft Entra ID, Keycloak). Ziel ist zentrale Zugriffsverwaltung: Wer das Unternehmen verlässt, verliert den Zugang an einer Stelle.

Beide nutzen dasselbe Protokoll, die Produktentscheidungen unterscheiden sich aber. Beim Social Login wählt der Nutzer den Anbieter; beim Enterprise-SSO bestimmt das Kundenunternehmen den Anbieter und will meist seinen eigenen Mandanten per SAML oder OIDC anbinden.

Der Google-Login-Ablauf Schritt für Schritt

Empfohlen ist der Ablauf „Authorization Code mit PKCE“. Der alte Implicit Flow, der Tokens im Browser erzeugte, wird nicht mehr empfohlen; Tokens werden immer auf dem Server geholt, der Browser erhält nur Ihr eigenes Sitzungscookie.

• In der Google Cloud Console wird ein OAuth-Client angelegt; die erlaubten Weiterleitungsadressen (Redirect URIs) werden als exakte Treffer registriert, ohne Platzhalter.
• Klickt der Nutzer auf „Mit Google anmelden“, erzeugt der Server einen zufälligen state und einen PKCE code_verifier, legt beides in einem kurzlebigen Cookie ab und leitet zum Autorisierungsendpunkt von Google weiter.
• Google prüft die Identität, zeigt dem Nutzer, welche Daten geteilt werden, und holt die Zustimmung ein; der Browser kehrt mit einem code zu Ihrer Callback-Adresse zurück.
• Der Server vergleicht state mit dem Cookie und tauscht den code am Token-Endpunkt von Google gegen ein ID-Token (mit client_secret und code_verifier).
• Die Signatur des ID-Tokens wird gegen die veröffentlichten Schlüssel von Google geprüft, ebenso iss, aud und Ablaufzeit; die E-Mail muss als bestätigt markiert sein.
• Der Nutzer wird in der Datenbank gefunden oder angelegt, Ihr Sitzungscookie schließt die Anmeldung ab. Das Google-Token wird nie an den Browser geschickt.

Beispiel: der Callback als Next.js Route Handler

// app/api/auth/google/callback/route.ts
import { createRemoteJWKSet, jwtVerify } from 'jose';

const GOOGLE_JWKS = createRemoteJWKSet(
  new URL('https://www.googleapis.com/oauth2/v3/certs'),
);

export async function GET(req: Request) {
  const url = new URL(req.url);
  const code = url.searchParams.get('code');
  const state = url.searchParams.get('state');

  // state wurde beim Start des Logins in ein Cookie geschrieben: CSRF-Prüfung
  if (!code || !state || state !== await readStateCookie()) {
    return new Response('Ungültige Anfrage', { status: 400 });
  }

  // der Tausch code -> Token findet immer auf dem Server statt
  const tokenRes = await fetch('https://oauth2.googleapis.com/token', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
      code,
      grant_type: 'authorization_code',
      client_id: process.env.GOOGLE_CLIENT_ID!,
      client_secret: process.env.GOOGLE_CLIENT_SECRET!,
      redirect_uri: process.env.GOOGLE_REDIRECT_URI!,
      code_verifier: await readVerifierCookie(),
    }),
  });
  const { id_token } = (await tokenRes.json()) as { id_token: string };

  // Prüfung von Signatur, Aussteller, Empfänger und Ablauf
  const { payload } = await jwtVerify(id_token, GOOGLE_JWKS, {
    issuer: ['https://accounts.google.com', 'accounts.google.com'],
    audience: process.env.GOOGLE_CLIENT_ID,
  });
  if (payload.email_verified !== true) {
    return new Response('E-Mail nicht bestätigt', { status: 403 });
  }

  // die Identität ist Googles dauerhaftes "sub", nicht die E-Mail-Adresse
  const user = await findOrLinkUser({
    provider: 'google',
    subject: payload.sub!,
    email: String(payload.email),
  });

  return createSessionAndRedirect(user.id, '/dashboard');
}

Kontoverknüpfung: hier bleiben Projekte hängen

Die meisten Websites, die Google-Login ergänzen, haben bereits Nutzer mit E-Mail und Passwort. Wird nicht vorab entschieden, was passiert, wenn dieselbe Person sich mit Google anmeldet, entstehen entweder zwei getrennte Konten oder es werden die falschen zusammengeführt. Drei Regeln lösen das. Erstens: Die Identität des Nutzers ist nicht die E-Mail-Adresse, sondern der dauerhafte sub-Wert von Google; E-Mails ändern sich, sub nicht. Zweitens: Eine automatische Zusammenführung mit einem bestehenden Konto erfolgt nur, wenn Google die E-Mail als bestätigt meldet; sonst könnte sich ein Konto anmelden, das die E-Mail eines anderen behauptet. Drittens: Ein Nutzer muss mehrere Anbieter verknüpfen können, daher stehen Anbieterdaten in einer eigenen Tabelle „Identitäten“ (Nutzer, Anbieter, sub) und nicht als Spalten der Nutzertabelle.

Der Schlüssel eines Nutzers ist nicht die E-Mail, sondern die dauerhafte Kennung des Anbieters. Ein System, das auf die E-Mail schlüsselt, verwechselt Konten, sobald sich eine Adresse ändert oder ein anderer Anbieter dieselbe Adresse ungeprüft liefert.

Enterprise-SSO: Google Workspace und Microsoft Entra

Wird SSO für ein B2B-Produkt oder ein internes Panel gewünscht, wächst die Aufgabe um einige Schritte. Es muss eingeschränkt werden, welche Domains sich anmelden dürfen: Der Claim hd im Google-ID-Token enthält die Workspace-Domain des Nutzers, ist aber nur eine Prüfung und kein Ersatz für Autorisierung. Werden Nutzer beim ersten Login automatisch angelegt (Just-in-time Provisioning), muss die Startrolle definiert sein; das Rollendesign haben wir in Benutzerrollen und Berechtigungen beschrieben. Soll Microsoft Entra oder ein anderer Mandant angebunden werden, registriert der Kunde Ihre Anwendung meist auf seiner Seite per SAML oder OIDC, und Sie halten je Kunde einen eigenen Aussteller und Schlüsselsatz. Am häufigsten vergessen wird die Abmeldung: Verlässt ein Mitarbeiter das Unternehmen, wird sein Konto beim Identitätsanbieter geschlossen, Ihre offene Sitzung lebt aber bis zu ihrem eigenen Ablauf weiter. Halten Sie Sitzungen kurz oder werten Sie die Logout-Benachrichtigung des Anbieters aus.

Sicherheits-Checkliste

• state und PKCE sind bei jeder Anfrage Pflicht; state ist einmalig und wird beim Callback mit dem Cookie verglichen.
• Redirect URIs sind als exakte Treffer registriert; Test und Produktion nutzen getrennte Clients, und client_secret gelangt nie in den Browser oder ein App-Paket.
• Das ID-Token dient nur der Identität; API-Aufrufe autorisiert Ihre eigene Sitzung oder ein selbst ausgestelltes Token. Das ID-Token wie einen Zugriffsschlüssel an andere Dienste zu schicken, ist ein verbreiteter Fehler.
• Scopes bleiben minimal: openid, email und profile reichen für die meisten Websites. Kalender- oder Drive-Zugriff wird bei Bedarf getrennt und später angefordert.
• Der Wiederherstellungsweg für Nutzer, die ihr Google-Konto verlieren, wird vorab entworfen: ein einmaliger E-Mail-Link oder ein zweiter Anbieter. Konten mit nur einem Anbieter sind die häufigste Quelle von Support-Anfragen.
• Login-Endpunkte werden ratenbegrenzt, fehlgeschlagene Versuche protokolliert; die übrigen Angriffsflächen behandelt unser Beitrag zur Website-Sicherheit.

Bei risikoreichen Aktionen (Zahlungsfreigabe, Rechteänderung) sollte der Google-Login allein nicht genügen; verlangen Sie im Moment der Aktion eine zweite Bestätigung. Diese Seite behandeln wir in SMS-OTP-Verifizierung.

Gehosteter Identitätsdienst oder eigene Lösung?

Gehostete Dienste wie Auth0, Firebase Authentication und Clerk sowie selbst betriebene Produkte wie Keycloak liefern den gesamten Ablauf, Passwort-Reset und Mehrfaktor-Authentifizierung fertig mit. Für einen einzigen Anbieter und ein einfaches Nutzermodell genügt eine eigene Lösung mit einer Bibliothek wie Auth.js, und die Nutzerdaten bleiben in Ihrer Datenbank. Werden mandantenfähiges SSO, SAML, Mehrfaktor-Authentifizierung und Audit-Logs zusammen verlangt, verkürzt ein gehosteter Dienst oder Keycloak das Projekt um Wochen. Zwei Fragen entscheiden: Wo liegen die Nutzerdaten, und lassen sich beim Ausstieg aus dem Dienst die Nutzer samt Passwort-Hashes exportieren? Liegt die Nutzertabelle in Ihrer eigenen Datenbank, beantwortet sich die zweite Frage von selbst; dieser Ansatz passt auch zum mandantenfähigen Modell aus unserem Beitrag zur SaaS-Produktentwicklung.

Datenschutzhinweis

Beim Google-Login erhält Ihre Seite Name, E-Mail und Profilbild; das sind personenbezogene Daten, und die Datenschutzerklärung sollte Quelle (Identitätsanbieter) und Zweck nennen. Fordern Sie nur an, was der Login braucht, und speichern Sie das Profilbild nicht ohne Verwendung. Den türkischen Rahmen beschreibt unser Beitrag zur KVKK-konformen Website; dieser Text ist keine Rechtsberatung.

Fazit

Richtig umgesetzt gibt der Google-Login den Nutzern eine reibungslose Registrierung und erspart Ihrer Website die Passwortspeicherung. Der technische Ablauf ist Standard; das Projekt prägen die Regeln zur Kontoverknüpfung, die Sitzungsdauer und die SSO-Erwartungen von Geschäftskunden. Wenn Sie Social Login oder Enterprise-SSO in eine bestehende Website einbauen möchten, senden Sie uns Ihre Anforderungen über das Angebotsformular; wir planen den Ablauf gemeinsam mit Ihrer vorhandenen Nutzertabelle.