Firebase Authentication um Blockierfunktionen erweitern

Mit Blockierfunktionen können Sie benutzerdefinierten Code ausführen, der das Ergebnis einer Nutzerregistrierung oder Anmeldung bei Ihrer Anwendung ändert. Sie können beispielsweise verhindern, dass ein Nutzer sich authentifizieren kann, wenn er bestimmte Kriterien nicht erfüllt, oder seine Informationen aktualisieren, bevor sie an die Clientanwendung zurückgegeben werden.

Hinweis

Wenn Sie Blockierungsfunktionen verwenden möchten, müssen Sie Ihr Firebase-Projekt auf Firebase Authentication with Identity Platform aktualisieren. Wenn Sie noch kein Upgrade durchgeführt haben, sollten Sie dies zuerst tun.

Informationen zu Blockierfunktionen

Sie können Blockierfunktionen für zwei Ereignisse registrieren:

• beforeCreate: Wird ausgelöst, bevor ein neuer Nutzer im Firebase Authentication-Datenbank und bevor ein Token an Ihre Client-App.

• beforeSignIn: Wird ausgelöst, nachdem die Anmeldedaten eines Nutzers überprüft wurden, aber bevor Firebase Authentication ein ID-Token an Ihre Clientanwendung zurückgibt. Wenn Ihre Anwendung die Multi-Faktor-Authentifizierung verwendet, wird die Funktion ausgelöst, nachdem der Nutzer seinen zweiten Faktor überprüft hat. Beachten Sie, dass durch das Erstellen eines neuen Nutzers neben beforeCreate auch beforeSignIn ausgelöst wird.

Beachten Sie bei der Verwendung von Blockierfunktionen Folgendes:

• Die Funktion muss innerhalb von 7 Sekunden antworten. Nach sieben Sekunden gibt Firebase Authentication einen Fehler zurück und der Clientvorgang schlägt fehl.

• Andere HTTP-Antwortcodes als 200 werden an Ihre Clientanwendungen weitergeleitet. Achten Sie darauf, dass der Clientcode alle Fehler verarbeitet, die von der Funktion zurückgegeben werden.

• Funktionen gelten für alle Nutzer in Ihrem Projekt, einschließlich der in einem Mandanten enthaltenen Nutzer. Firebase Authentication stellt der Funktion Informationen über Nutzer bereit, einschließlich aller Mandanten, zu denen sie gehören, damit Sie entsprechend reagieren können.

• Durch die Verknüpfung eines anderen Identitätsanbieters mit einem Konto werden alle registrierten beforeSignIn-Funktionen noch einmal ausgelöst.

• Anonyme und benutzerdefinierte Authentifizierung lösen keine Blockierfunktionen aus.

Blockierfunktion bereitstellen

Wenn Sie Ihren benutzerdefinierten Code in die Nutzerauthentifizierungsabläufe einfügen möchten, stellen Sie die Blockierung bereit Funktionen. Nachdem Ihre Blockierfunktionen bereitgestellt wurden, muss Ihr benutzerdefinierter Code erfolgreich abgeschlossen werden, damit die Authentifizierung und Nutzererstellung erfolgreich abgeschlossen werden können.

Eine Blockierfunktion wird auf die gleiche Weise wie eine andere Funktion bereitgestellt. Weitere Informationen finden Sie auf der Seite Cloud Functions Einstieg. Zusammenfassung:

1. Schreiben Sie Cloud Functions, das das beforeCreate-Ereignis, das beforeSignIn-Ereignis oder beide verarbeitet.

   Sie können beispielsweise index.js die folgenden No-Op-Funktionen hinzufügen:

   const functions = require('firebase-functions/v1');
   
   exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
     // TODO
   });
   
   exports.beforeSignIn = functions.auth.user().beforeSignIn((user, context) => {
     // TODO
   });
   

   In den obigen Beispielen wurde die Implementierung der benutzerdefinierten Authentifizierungslogik ausgelassen. In den folgenden Abschnitten erfahren Sie, wie Sie Blockierfunktionen implementieren. Gängige Szenarien enthält konkrete Beispiele.

2. Funktionen mit der Firebase-Befehlszeile bereitstellen:

   firebase deploy --only functions
   

   Sie müssen die Funktionen bei jeder Aktualisierung neu bereitstellen.

Nutzer- und Kontextinformationen abrufen

Die Ereignisse beforeSignIn und beforeCreate stellen die Objekte User und EventContext bereit, die Informationen über den Nutzer enthalten, der sich anmeldet. Verwenden Sie diese Werte in Ihrem Code, um festzustellen, ob ein Vorgang fortgesetzt werden soll.

Eine Liste der im Objekt User verfügbaren Attribute finden Sie in der Referenz zur UserRecord API.

Das EventContext-Objekt weist die folgenden Attribute auf:

Registrierung oder Anmeldung blockieren

Wenn Sie einen Registrierungs- oder Anmeldeversuch blockieren möchten, geben Sie in der Funktionen den Fehler HttpsError aus. Beispiel:

throw new functions.auth.HttpsError('permission-denied');

In der folgenden Tabelle werden die Fehler, die Sie ausgeben können, zusammen mit der Standard-Fehlermeldung angezeigt:

Sie können auch eine benutzerdefinierte Fehlermeldung angeben:

throw new functions.auth.HttpsError('permission-denied', 'Unauthorized request origin!');

Das folgende Beispiel zeigt, wie Sie Nutzer, die nicht Mitglieder innerhalb einer bestimmten Domain sind, daran hindern, sich bei Ihrer Anwendung anzumelden:

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  // (If the user is authenticating within a tenant context, the tenant ID can be determined from
  // user.tenantId or from context.resource, e.g. 'projects/project-id/tenant/tenant-id-1')

  // Only users of a specific domain can sign up.
  if (user.email.indexOf('@acme.com') === -1) {
    throw new functions.auth.HttpsError('invalid-argument', `Unauthorized email "${user.email}"`);
  }
});

Unabhängig davon, ob Sie eine Standardnachricht oder eine benutzerdefinierte Nachricht verwenden, Cloud Functions fasst den Fehler zusammen und gibt ihn als interner Fehler. Beispiel:

throw new functions.auth.HttpsError('invalid-argument', `Unauthorized email user@evil.com}`);

Ihre Anwendung erkennt den Fehler und reagiert entsprechend. Beispiel:

// Blocking functions can also be triggered in a multi-tenant context before user creation.
// firebase.auth().tenantId = 'tenant-id-1';
firebase.auth().createUserWithEmailAndPassword('johndoe@example.com', 'password')
  .then((result) => {
    result.user.getIdTokenResult()
  })
  .then((idTokenResult) => {
    console.log(idTokenResult.claim.admin);
  })
  .catch((error) => {
    if (error.code !== 'auth/internal-error' && error.message.indexOf('Cloud Function') !== -1) {
      // Display error.
    } else {
      // Registration succeeds.
    }
  });

Nutzer ändern

Anstatt Registrierungen oder Anmeldeversuche zu blockieren, können Sie den Zugriff auf um fortzufahren, aber ändern Sie das User-Objekt, das unter Firebase Authentication-Datenbank und wird an den Client zurückgegeben.

Um einen Nutzer zu ändern, geben Sie ein Objekt aus Ihrem Ereignis-Handler zurück, der die zu ändernden Felder enthält. Sie können die folgenden Felder ändern:

• displayName
• disabled
• emailVerified
• photoUrl
• customClaims
• sessionClaims (nur beforeSignIn)

Mit Ausnahme von sessionClaims werden alle geänderten Felder in der Datenbank von Firebase Authentication gespeichert. Das bedeutet, dass sie im Antworttoken enthalten sind und zwischen Nutzersitzungen erhalten bleiben.

Im folgenden Beispiel wird gezeigt, wie ein Standard-Anzeigename festgelegt wird:

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  return {
    // If no display name is provided, set it to "Guest".
    displayName: user.displayName || 'Guest';
  };
});

Wenn Sie einen Ereignis-Handler für beforeCreate und beforeSignIn registrieren, beachten Sie, dass beforeSignIn nach beforeCreate ausgeführt wird. In beforeCreate aktualisierte Nutzerfelder sind in beforeSignIn sichtbar. Wenn Sie in beiden Event-Handlern ein anderes Feld als sessionClaims festlegen, überschreibt der in beforeSignIn festgelegte Wert den in beforeCreate festgelegten Wert. Nur für sessionClaims werden sie auf die Tokenanforderungen der aktuellen Sitzung übertragen, aber nicht in der Datenbank gespeichert oder gespeichert.

Wenn beispielsweise sessionClaims festgelegt sind, werden sie von beforeSignIn mit allen beforeCreate-Anforderungen zurückgegeben und zusammengeführt. Wenn ein sessionClaims-Schlüssel mit einem Schlüssel in customClaims übereinstimmt, werden die übereinstimmenden customClaims in den Tokenanforderungen vom sessionClaims-Schlüssel überschrieben. Der überschriebene customClaims-Schlüssel bleibt jedoch für zukünftige Anfragen in der Datenbank erhalten.

Unterstützte OAuth-Anmeldedaten und -Daten

Sie können OAuth-Anmeldedaten und -Daten an Blockierfunktionen von verschiedenen Identitätsanbietern übergeben. Die folgende Tabelle zeigt, welche Anmeldedaten und Daten für die einzelnen Identitätsanbieter unterstützt werden:

Aktualisierungstokens

Wenn Sie ein Aktualisierungstoken in einer Blockierfunktion verwenden möchten, müssen Sie zuerst das Kästchen auf der Seite Blockierfunktionen der Firebase Console anklicken.

Aktualisierungstokens werden von Identitätsanbietern nicht zurückgegeben, wenn die Anmeldung direkt über OAuth-Anmeldedaten erfolgt, wie z. B. mit einem ID-Token oder Zugriffstoken. In diesem Fall werden die clientseitigen OAuth-Anmeldedaten an die Blockierfunktion übergeben.

In den folgenden Abschnitten werden die verschiedenen Arten von Identitätsanbietern und ihre unterstützten Anmeldedaten und Daten beschrieben.

Generische OIDC-Anbieter

Wenn sich ein Nutzer mit einem generischen OIDC-Anbieter anmeldet, werden die folgenden Anmeldedaten übergeben:

• ID-Token: Wird angegeben, wenn der Ablauf id_token ausgewählt ist.
• Zugriffstoken: Wird angegeben, wenn der Codeablauf ausgewählt ist Beachten Sie, dass der Codeablauf derzeit nur über die REST API unterstützt wird.
• Aktualisierungstoken: Wird angegeben, wenn der offline_access-Bereich ausgewählt ist.

Beispiel:

const provider = new firebase.auth.OAuthProvider('oidc.my-provider');
provider.addScope('offline_access');
firebase.auth().signInWithPopup(provider);

Google

Wenn sich ein Nutzer mit Google anmeldet, werden die folgenden Anmeldedaten übergeben:

• ID-Token
• Zugriffstoken
• Aktualisierungstoken: Wird nur angegeben, wenn die folgenden benutzerdefinierten Parameter angefordert werden:
  • access_type=offline
  • prompt=consent, wenn der Nutzer zuvor zugestimmt hat und kein neuer Bereich angefordert wurde

Beispiel:

const provider = new firebase.auth.GoogleAuthProvider();
provider.setCustomParameters({
  'access_type': 'offline',
  'prompt': 'consent'
});
firebase.auth().signInWithPopup(provider);

Weitere Informationen zu Google-Aktualisierungstokens

Facebook

Wenn sich ein Nutzer mit Facebook anmeldet, werden die folgenden Anmeldedaten übergeben:

• Zugriffstoken: Ein Zugriffstoken wird zurückgegeben und kann durch ein anderes Zugriffstoken ersetzt werden. Weitere Informationen zu den verschiedenen Arten von Zugriffstokens, die von Facebook unterstützt werden, und wie Sie diese gegen langfristige Tokens tauschen können.

GitHub

Wenn sich ein Nutzer mit GitHub anmeldet, werden die folgenden Anmeldedaten übergeben:

• Zugriffstoken: läuft nicht ab, es sei denn, es wird widerrufen.

Microsoft

Wenn sich ein Nutzer mit Microsoft anmeldet, werden die folgenden Anmeldedaten übergeben:

• ID-Token
• Zugriffstoken
• Aktualisierungstoken: Wird an die Blockierfunktion übergeben, wenn der offline_access-Bereich ausgewählt ist.

Beispiel:

const provider = new firebase.auth.OAuthProvider('microsoft.com');
provider.addScope('offline_access');
firebase.auth().signInWithPopup(provider);

Yahoo

Wenn sich ein Nutzer mit Spammer anmelden, werden die folgenden Anmeldedaten ohne benutzerdefinierte Parameter oder Bereiche übergeben:

• ID-Token
• Zugriffstoken
• Aktualisierungstoken

LinkedIn

Wenn sich ein Nutzer mit LinkedIn anmeldet, werden folgende Anmeldedaten übergeben:

• Zugriffstoken

Apple

Wenn sich ein Nutzer mit Apple anmeldet, werden die folgenden Anmeldedaten ohne benutzerdefinierte Parameter oder Bereiche übergeben:

• ID-Token
• Zugriffstoken
• Aktualisierungstoken

Gängige Szenarien

Die folgenden Beispiele veranschaulichen gängige Anwendungsfälle für Blockierfunktionen:

Registrierung über eine bestimmte Domain zulassen

Das folgende Beispiel zeigt, wie Sie verhindern können, dass sich Nutzer, die nicht zur example.com-Domain gehören, bei Ihrer Anwendung registrieren:

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (!user.email || user.email.indexOf('@example.com') === -1) {
    throw new functions.auth.HttpsError(
      'invalid-argument', `Unauthorized email "${user.email}"`);
  }
});

Nutzer mit unbestätigten E-Mails für die Registrierung blockieren

Das folgende Beispiel zeigt, wie Sie verhindern können, dass sich Nutzer mit unbestätigten E-Mails bei Ihrer Anwendung registrieren:

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (user.email && !user.emailVerified) {
    throw new functions.auth.HttpsError(
      'invalid-argument', `Unverified email "${user.email}"`);
  }
});

E-Mail-Bestätigung bei der Registrierung anfordern

Das folgende Beispiel zeigt, wie ein Nutzer seine E-Mail-Adresse nach der Registrierung bestätigen muss:

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  const locale = context.locale;
  if (user.email && !user.emailVerified) {
    // Send custom email verification on sign-up.
    return admin.auth().generateEmailVerificationLink(user.email).then((link) => {
      return sendCustomVerificationEmail(user.email, link, locale);
    });
  }
});

exports.beforeSignIn = functions.auth.user().beforeSignIn((user, context) => {
 if (user.email && !user.emailVerified) {
   throw new functions.auth.HttpsError(
     'invalid-argument', `"${user.email}" needs to be verified before access is granted.`);
  }
});

E-Mail-Adressen von bestimmten Identitätsanbietern als bestätigt behandeln

Das folgende Beispiel zeigt, wie Nutzer-E-Mails von bestimmten Identitätsanbietern als bestätigt behandelt werden:

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (user.email && !user.emailVerified && context.eventType.indexOf(':facebook.com') !== -1) {
    return {
      emailVerified: true,
    };
  }
});

Anmeldung von bestimmten IP-Adressen blockieren

Im folgenden Beispiel wird gezeigt, wie die Anmeldung aus bestimmten IP-Adressbereichen blockiert wird:

exports.beforeSignIn = functions.auth.user().beforeSignIn((user, context) => {
  if (isSuspiciousIpAddress(context.ipAddress)) {
    throw new functions.auth.HttpsError(
      'permission-denied', 'Unauthorized access!');
  }
});

Benutzerdefinierte Anforderungen und Sitzungsanforderungen festlegen

Im folgenden Beispiel wird gezeigt, wie benutzerdefinierte Anforderungen und Sitzungsanforderungen festgelegt werden:

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (context.credential &&
      context.credential.providerId === 'saml.my-provider-id') {
    return {
      // Employee ID does not change so save in persistent claims (stored in
      // Auth DB).
      customClaims: {
        eid: context.credential.claims.employeeid,
      },
      // Copy role and groups to token claims. These will not be persisted.
      sessionClaims: {
        role: context.credential.claims.role,
        groups: context.credential.claims.groups,
      }
    }
  }
});

Tracking von IP-Adressen zum Überwachen verdächtiger Aktivitäten

Sie können den Diebstahl von Tokens verhindern, indem Sie die IP-Adresse erfassen, mit der sich ein Nutzer anmeldet, und diese mit der IP-Adresse bei nachfolgenden Anfragen vergleichen. Wenn die Anfrage verdächtig erscheint, z. B. weil die IP-Adressen aus verschiedenen geografischen Regionen stammen, können Sie den Nutzer auffordern, sich noch einmal anzumelden.

1. Erfassen Sie mithilfe von Sitzungsanforderungen die IP-Adresse, mit der sich der Nutzer anmeldet:

   Node.js

   exports.beforeSignIn = functions.auth.user().beforeSignIn((user, context) => {
     return {
       sessionClaims: {
         signInIpAddress: context.ipAddress,
       },
     };
   });
   

2. Wenn ein Nutzer versucht, auf Ressourcen zuzugreifen, die eine Authentifizierung mit Firebase Authentication erfordern, vergleichen Sie die IP-Adresse in der Anfrage mit der IP-Adresse, die für die Anmeldung verwendet wird:

   Node.js

   app.post('/getRestrictedData', (req, res) => {
     // Get the ID token passed.
     const idToken = req.body.idToken;
     // Verify the ID token, check if revoked and decode its payload.
     admin.auth().verifyIdToken(idToken, true).then((claims) => {
       // Get request IP address
       const requestIpAddress = req.connection.remoteAddress;
       // Get sign-in IP address.
       const signInIpAddress = claims.signInIpAddress;
       // Check if the request IP address origin is suspicious relative to
       // the session IP addresses. The current request timestamp and the
       // auth_time of the ID token can provide additional signals of abuse,
       // especially if the IP address suddenly changed. If there was a sudden
       // geographical change in a short period of time, then it will give
       // stronger signals of possible abuse.
       if (!isSuspiciousIpAddressChange(signInIpAddress, requestIpAddress)) {
         // Suspicious IP address change. Require re-authentication.
         // You can also revoke all user sessions by calling:
         // admin.auth().revokeRefreshTokens(claims.sub).
         res.status(401).send({error: 'Unauthorized access. Please login again!'});
       } else {
         // Access is valid. Try to return data.
         getData(claims).then(data => {
           res.end(JSON.stringify(data);
         }, error => {
           res.status(500).send({ error: 'Server error!' })
         });
       }
     });
   });
   

Nutzerfotos bereinigen

Das folgende Beispiel zeigt, wie Sie Profilbilder von Nutzern bereinigen:

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (user.photoURL) {
    return isPhotoAppropriate(user.photoURL)
      .then((status) => {
        if (!status) {
          // Sanitize inappropriate photos by replacing them with guest photos.
          // Users could also be blocked from sign-up, disabled, etc.
          return {
            photoUrl: PLACEHOLDER_GUEST_PHOTO_URL,
          };
        }
      });
});

Weitere Informationen zum Erkennen und Bereinigen von Bildern finden Sie in der Cloud Vision-Dokumentation.

Auf OAuth-Anmeldedaten eines Nutzeranbieters zugreifen

Das folgende Beispiel zeigt, wie Sie ein Aktualisierungstoken für einen Nutzer abrufen, der sich bei Google angemeldet hat, und damit die Google Calendar APIs aufrufen. Das Aktualisierungstoken wird für den Offlinespeicher gespeichert.

const {OAuth2Client} = require('google-auth-library');
const {google} = require('googleapis');
// ...
// Initialize Google OAuth client.
const keys = require('./oauth2.keys.json');
const oAuth2Client = new OAuth2Client(
  keys.web.client_id,
  keys.web.client_secret
);

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (context.credential &&
      context.credential.providerId === 'google.com') {
    // Store the refresh token for later offline use.
    // These will only be returned if refresh tokens credentials are included
    // (enabled by Cloud console).
    return saveUserRefreshToken(
        user.uid,
        context.credential.refreshToken,
        'google.com'
      )
      .then(() => {
        // Blocking the function is not required. The function can resolve while
        // this operation continues to run in the background.
        return new Promise((resolve, reject) => {
          // For this operation to succeed, the appropriate OAuth scope should be requested
          // on sign in with Google, client-side. In this case:
          // https://www.googleapis.com/auth/calendar
          // You can check granted_scopes from within:
          // context.additionalUserInfo.profile.granted_scopes (space joined list of scopes).

          // Set access token/refresh token.
          oAuth2Client.setCredentials({
            access_token: context.credential.accessToken,
            refresh_token: context.credential.refreshToken,
          });
          const calendar = google.calendar('v3');
          // Setup Onboarding event on user's calendar.
          const event = {/** ... */};
          calendar.events.insert({
            auth: oauth2client,
            calendarId: 'primary',
            resource: event,
          }, (err, event) => {
            // Do not fail. This is a best effort approach.
            resolve();
          });
      });
    })
  }
});

reCAPTCHA Enterprise-Ergebnis für Nutzervorgang überschreiben

Im folgenden Beispiel wird gezeigt, wie Sie ein reCAPTCHA Enterprise-Urteil für unterstützte Nutzerflüsse überschreiben.

Weitere Informationen zum Einbinden von reCAPTCHA Enterprise in Firebase Authentication finden Sie unter reCAPTCHA Enterprise aktivieren.

Blockierfunktionen können verwendet werden, um Datenflüsse basierend auf benutzerdefinierten Faktoren zuzulassen oder zu blockieren und so das von reCAPTCHA Enterprise gelieferte Ergebnis zu überschreiben.

 const {
   auth,
 } = require("firebase-functions/v1");

exports.checkrecaptchaV1 = auth.user().beforeSignIn((userRecord, context) => {
 // Allow users with a specific email domain to sign in regardless of their recaptcha score.
 if (userRecord.email && userRecord.email.indexOf('@acme.com') === -1) {
   return {
     recaptchaActionOverride: 'ALLOW',
   };
 }

 // Allow users to sign in with recaptcha score greater than 0.5
 if (context.additionalUserInfo.recaptchaScore > 0.5) {
   return {
     recaptchaActionOverride: 'ALLOW',
   };
 }

 // Block all others.
 return {
   recaptchaActionOverride: 'BLOCK',
 };
});