Google-Login mit AWS Cognito integrieren – auch ohne Hosted UI

Die Kombination aus AWS Cognito und Google-Sign-In gestaltet sich oft unkompliziert – vorausgesetzt, man darf Cognitos Hosted UI nutzen. Doch was tun, wenn der Zugriff auf die AWS-Konsole fehlt oder die Standard-OAuth-Flows nicht infrage kommen? Ein Entwickler eines Tech-Teams stand genau vor diesem Dilemma und fand eine kreative Lösung, die beide Welten verbindet.

Die Herausforderung: Authentifizierung ohne Flexibilität

Das Team nutzte eine NestJS-Architektur mit AWS Cognito als Nutzerdatenbank. Die Vorgabe klang simpel: Nutzer sollten sich per Google-Login anmelden können. Doch zwei entscheidende Einschränkungen machten die Umsetzung komplex:

• Kein Zugriff auf die AWS-Konsole: Jede Änderung erforderte Freigaben durch das Management – ein zeitraubender Prozess.
• Keine Nutzung von Cognitos Hosted UI: Das Frontend sollte ein eigenes Design für den Login-Prozess verwenden, ohne Umleitungen zu AWS-Seiten.

Die Standardlösung für Google-Sign-In in Cognito sieht vor, Google als Identity-Provider zu konfigurieren und die OAuth-Flows über Cognitos Hosted UI abzuwickeln. Doch genau diese Wege waren blockiert. Plötzlich stand das Team vor der Frage: Wie lässt sich Google-Sign-In realisieren, wenn Cognito nicht mitspielt?

Der Ansatz: Google-Tokens prüfen und Nutzer direkt anlegen

Anstatt sich an Cognitos Standardprozesse zu klammern, analysierte der Entwickler, was er tatsächlich kontrollieren konnte:

1. Google-Tokens serverseitig verifizieren: Google stellt bereits verifizierte Nutzerdaten bereit – warum also noch einmal prüfen?
2. Cognitos Admin-APIs nutzen: Diese erlauben serverseitige Nutzerverwaltung, ohne Nutzerinteraktion oder Hosted UI.
3. Deterministische Passwörter generieren: Für Cognito wird ein Passwort benötigt – auch wenn der Nutzer es nie eingibt.

Der entscheidende Gedanke: Wenn Google die Authentifizierung übernimmt, muss Cognito nicht erneut verifizieren. Stattdessen extrahiert der Server die Nutzerdaten aus dem Google-Token und legt den Nutzer direkt in Cognito an – mit einem generierten Passwort, das aus Nutzer-ID und einem Server-Geheimnis abgeleitet wird. Das Ergebnis? Ein reibungsloser Login über Google, ohne Cognitos Hosted UI oder manuelle Konfiguration.

Schritt-für-Schritt: Wie die Integration funktioniert

Die Lösung besteht aus drei zentralen Komponenten, die in einer NestJS-Anwendung implementiert wurden:

1. Endpunkt für Anmeldung und Registrierung

Der Controller behandelt beide Flows – Google-Sign-In und klassische Registrierung – in einem einzigen Endpunkt. Die Logik verzweigt sich anhand des Vorhandenseins eines googleToken im Request:

@Post('signup')
@UseInterceptors(FileInterceptor('client_logo'))
async signup(
  @UploadedFile() clientLogoFile: Express.Multer.File,
  @Body('googleToken') googleToken: string,
  @Body('request_create_client_dto') requestCreateClientDto: string,
  @Body('request_signup_user_dto') requestSignupUserDto?: string,
) {
  const createClientDto = JSON.parse(requestCreateClientDto);

  // Google-Sign-In-Flow
  if (googleToken) {
    return await this.authService.googleSignupCompany(
      googleToken,
      createClientDto,
      clientLogoFile,
    );
  }

  // Klassischer Registrierungsflow
  if (!requestSignupUserDto) {
    throw new BadRequestException('Signup user data is required');
  }
  const signupUserDto = JSON.parse(requestSignupUserDto);
  return await this.authService.signupWithClientAndUser(
    createClientDto,
    signupUserDto,
    clientLogoFile,
  );
}

Die Trennung stellt sicher, dass Google-spezifische Logik nicht in den Standard-Login-Flow übergreift – und umgekehrt.

2. Google-Token verifizieren

Bevor irgendwelche Daten verarbeitet werden, muss das Google-Token serverseitig validiert werden. Hier kommt das google-auth-library-Paket zum Einsatz:

async verifyGoogleToken(googleToken: string) {
  try {
    const ticket = await this.googleClient.verifyIdToken({
      idToken: googleToken,
      audience: process.env.GOOGLE_CLIENT_ID,
    });
    return ticket.getPayload();
  } catch (error) {
    throw new BadRequestException('Ungültiges Google-Token');
  }
}

Die Methode prüft:

• Die Signatur des Tokens gegen Googles öffentliche Schlüssel.
• Die audience (die Client-ID der eigenen Anwendung).
• Die Gültigkeitsdauer des Tokens.

Erst nach dieser Validierung werden die Nutzerdaten aus dem Token extrahiert.

3. Nutzer in Cognito anlegen und Passwort generieren

Mit den extrahierten Daten – E-Mail, Name und Google-Nutzer-ID – wird der Nutzer nun in Cognito angelegt. Da Cognito zwingend ein Passwort erwartet, wird ein deterministisches Passwort generiert:

async createCognitoUser(email: string, googleUserId: string) {
  const password = this.generateDeterministicPassword(googleUserId);
  
  return await this.cognitoClient.adminCreateUser({
    UserPoolId: process.env.AWS_COGNITO_USER_POOL_ID,
    Username: email,
    UserAttributes: [
      { Name: 'email', Value: email },
      { Name: 'email_verified', Value: 'true' },
    ],
    TemporaryPassword: password,
    MessageAction: 'SUPPRESS',
  }).promise();
}

private generateDeterministicPassword(googleUserId: string): string {
  const secret = process.env.PASSWORD_SECRET;
  const hash = crypto.createHash('sha256').update(googleUserId + secret).digest('hex');
  return hash.substring(0, 32); // Cognito akzeptiert Passwörter bis 32 Zeichen
}

Die Passwortgenerierung nutzt:

• Die Google-Nutzer-ID als eindeutigen Identifier.
• Ein Server-Geheimnis (PASSWORD_SECRET), das nur auf dem Backend hinterlegt ist.

Das gleiche Passwort lässt sich später bei erneuten Logins neu generieren – Cognito erkennt den Nutzer trotzdem wieder.

Vorteile und Grenzen der Lösung

Diese Methode bietet entscheidende Vorteile, wenn Cognitos Standardprozesse nicht nutzbar sind:

• Keine Hosted UI nötig: Nutzer sehen nie eine AWS-Seite, der Login bleibt im eigenen Frontend.
• Keine manuelle Konfiguration: Kein Bedarf für die AWS-Konsole oder Cognito-Einstellungen.
• Automatisierte Nutzerverwaltung: Neue Nutzer werden sofort in Cognito angelegt, ohne manuelle Freigaben.

Allerdings gibt es auch Einschränkungen:

• Keine native Federated Identity: Nutzer können sich nur über Google anmelden – andere Provider sind nicht eingebunden.
• Passwortmanagement: Obwohl Nutzer das Passwort nie sehen, muss es generiert und sicher verwaltet werden.
• Keine E-Mail-Bestätigung: Da Google die E-Mail bereits verifiziert hat, wird email_verified auf true gesetzt – eine zusätzliche Bestätigung entfällt.

Fazit: Eine pragmatische Lösung für komplexe Anforderungen

Die Integration von Google-Sign-In in AWS Cognito ohne Hosted UI und ohne AWS-Konsole-Zugriff ist möglich – wenn man die Standardprozesse von Cognito umgeht. Dieser Ansatz eignet sich besonders für Teams, die maximale Kontrolle über das Nutzererlebnis benötigen oder in Umgebungen mit eingeschränkten Zugriffsrechten arbeiten.

Für zukünftige Projekte lohnt es sich jedoch, frühzeitig zu prüfen, ob Cognitos Standardfunktionen genutzt werden können. Denn obwohl diese Lösung funktioniert, bleibt sie ein Workaround. Wer langfristig skalierbare und wartbare Authentifizierungssysteme aufbauen möchte, sollte auf native Cognito-Funktionen wie Hosted UI oder Custom Authentication Flows setzen – sofern die Rahmenbedingungen dies zulassen.

Die hier beschriebene Methode zeigt einmal mehr: In der Softwareentwicklung gibt es selten nur einen richtigen Weg. Manchmal führt der ungewöhnlichste Ansatz zum Ziel – wenn man bereit ist, die Regeln zu brechen, um sie neu zu definieren.