Sicherheit im Paket

In diesem Leitfaden werden eine Reihe von Funktionen beschrieben, die zusätzliche Trust-Signale zu einem Google-Konto zurückgeben. Diese Trust-Signale helfen Ihrem Kontoverwaltungssystem, risikobasierte Entscheidungen bei der Registrierung, Kontoerstellung und später für wiederkehrende Nutzer zu treffen.

Sitzungen

Eine Authentifizierungsanfrage einer Anwendung gibt ein ID-Token zurück. Wenn beispielsweise auf die Schaltfläche „Über Google anmelden“ geklickt wird, wird ein ID-Token an die Android-, iOS- oder Web-Client- oder Serveranwendung zurückgegeben, die die Schaltfläche anzeigt.

Die Authentifizierung für die Anmeldung in einem Google-Konto ist ein separates Ereignis. Die im ID-Token zurückgegebenen Ansprüche stellen dieses Ereignis dar. Beispielsweise die Authentifizierungszeit und die Methoden, die für die Anmeldung im Google-Konto verwendet wurden.

Es gibt zwei Authentifizierungszeitpunkte und zwei Nutzersitzungen:

  • Nutzer <-> Google-Sitzung : Wird eingerichtet, wenn sich ein Nutzer in seinem Google-Konto anmeldet. Google verwaltet den Lebenszyklus und die Sicherheit dieser Sitzung. Die Ansprüche auth_time und amr geben Ihnen Einblicke in diese Sitzung.
  • Nutzer <-> Sitzung Ihrer Anwendung : Wird eingerichtet, nachdem sich der Nutzer in Ihrer Anwendung angemeldet hat. Dies wird häufig mit „Über Google anmelden“ initiiert. Ihre Anwendung verwaltet diese Sitzung mithilfe der Ansprüche, um Entscheidungen zur Sitzungs- und Kontoverwaltung zu verbessern.

Nutzer interagieren häufig mit Google-Diensten auf mehreren Geräten, z. B. Smartphones, Computern, Smart Displays oder Fernsehern. Wenn Sie sich auf jeder Plattform oder jedem Gerät anmelden, wird eine separate Sitzung eingerichtet. Bei Webanmeldungen wird eine Sitzung zwischen dem jeweiligen Browser und Google eingerichtet. Im privaten Browsing-Modus und im Inkognitomodus werden separate, isolierte Sitzungen erstellt. Daher können für ein einzelnes Google-Konto mehrere separate Sitzungen gleichzeitig in verschiedenen Browsern und auf verschiedenen Geräten aktiv sein. Weitere Informationen finden Sie unter Geräte mit Kontozugriff ansehen.

Status des Google-Kontos

Die typischen Ereignisse im Lebenszyklus eines Google-Kontos sind:

Die in diesem Leitfaden beschriebenen Security Bundle-Funktionen gelten für aktive oder deaktivierte Konten, aber nicht für Ereignisse zur Erstellung oder Löschung von Google-Konten.

Google kann ein Konto jederzeit deaktivieren. Einige Gründe dafür finden Sie unter Mein Konto wurde deaktiviert. In diesem Fall werden alle aktiven Google-Sitzungen beendet und ein RISC-Ereignis wird vom produktübergreifenden Kontoschutz-Dienst von Google gesendet. Deaktivierte Konten können nicht für „Über Google anmelden“ verwendet werden. Das bedeutet, dass kein ID-Token ausgestellt wird und daher nicht zur Überwachung deaktivierter Nutzerkonten verwendet werden kann.

Der Empfang von produktübergreifendem Kontoschutz-Ereignissen (RISC) ist optional. Diese Ereignisse dienen jedoch als wichtige Signale, um die Sitzung zwischen dem Nutzer und Ihrer App zu verwalten und zu prüfen, ob. Eine Anleitung zur Implementierung von RISC und zur Reaktion auf Ereignisse finden Sie unter Nutzerkonten mit Cross-Account Protection schützen.

Einrichtung

Damit Ihre App zusätzliche Ansprüche empfangen kann, muss sie veröffentlicht und bestätigt sein und die Security Bundle-Funktionen müssen aktiviert sein. Prüfen Sie zuerst, ob Ihre App veröffentlicht und bestätigt ist:

  1. Öffnen Sie die Google Auth Platform.
  2. Wählen Sie das Projekt für Ihre App aus oder erstellen Sie es.
  3. Klicken Sie auf Zielgruppe und prüfen Sie, ob der Veröffentlichungsstatus In Produktion ist.
  4. Klicken Sie auf Bestätigungscenter und prüfen Sie, ob der Bestätigungsstatus Bestätigt ist.

Aktivieren Sie als Nächstes zusätzliche Ansprüche:

  1. Klicken Sie im Menü auf Einstellungen.
  2. Wählen Sie unter Erweiterte Einstellungen Folgendes aus:
    • Ansprüche zum Sitzungsalter , um auth_time zu aktivieren
    • Ansprüche zur Authentifizierungsstärke , um amr zu aktivieren

Weitere Informationen finden Sie in der Hilfe zur OAuth-App-Bestätigung.

Unterstützte Funktionen

In diesem Abschnitt werden die einzelnen Funktionen beschrieben, aus denen das Security Bundle besteht.

Referenzen zu Authentifizierungsmethoden

„Referenzen zu Authentifizierungsmethoden“ (amr) ist ein OpenID Connect-Anspruch, der die Methoden beschreibt, die beim letzten Authentifizierungsereignis zwischen dem Nutzer und Google verwendet wurden.

Von den möglichen IANA.AMR-Werten unterstützt Google die folgenden Werte, die Folgendes angeben:

  • hwk : Es wurde ein Hardware-Sicherheitsschlüssel verwendet.
  • mfa : Die Multi-Faktor-Authentifizierung wurde abgeschlossen.
  • pwd : Es wurde ein Passwort verwendet.
  • swk : Es wurde ein Softwareschlüssel wie ein Passkey verwendet.
  • sms : Für die Bestätigung wurde eine SMS verwendet.
  • tel : Für die Bestätigung wurde ein Anruf verwendet.

Einer oder mehrere dieser Werte werden als JSON-Array von Strings im ID-Token-Anspruch amr zurückgegeben.

Der Anspruch amr ist nur dann im ID-Token enthalten, wenn Informationen zur verwendeten Authentifizierungsmethode verfügbar sind. Er ist möglicherweise auch dann nicht vorhanden, wenn er angefordert wurde.

Inhaber von Google-Konten können die Bestätigung in zwei Schritten und die zu verwendenden MFA-Methoden festlegen. Wenn erweiterte Sicherheit auf einem Google-Konto aktiviert ist, ist eine starke 2SV Methode wie Titan-Sicherheitsschlüssel (hwk) oder Passkey (swk) erforderlich. In beiden Fällen ist der Wert mfa vorhanden, wenn bei der Anmeldung im Google-Konto mehr als ein Faktor verwendet wird.

Das Vorhandensein von mfa bestätigt, dass das Authentifizierungsereignis die Anforderungen von Google für die Multi-Faktor-Authentifizierung erfüllt hat. Beispiel: Eine Google-Konto Authentifizierung mit einem Passwort (pwd) und einem Passkey (swk) führt zu diesem Anspruch "amr": ["mfa", "pwd", "swk"].

Weitere Informationen zur Kontosicherheit und Nutzer authentifizierung: Bester Kontoschutz von Google mit dem erweiterten Sicherheitsprogramm, Statt eines Passworts einen Passkey verwenden, und Sicherheitsschlüssel für die Bestätigung in zwei Schritten verwenden.

Workspace-Administratoren steuern die Authentifizierungsrichtlinie für verwaltete Workspace-Konten und können MFA oder die Verwendung von Sicherheitsschlüsseln verlangen. Weitere Informationen finden Sie unter Übersicht zur Google-Identitätsverwaltung und Anforderung der Multi-Faktor-Authentifizierung für Google Cloud Anmeldeschutz und ‑Steuerelemente.

Authentifizierungszeit

Der auth_time Anspruch ist ein Standardbestandteil des OpenID Connect-Protokolls der Informationen darüber enthält, wann sich der Endnutzer zuletzt authentifiziert hat bei Google. Es ist eine JSON-Zahl, die die Anzahl der Sekunden seit der Unix-Epoche (1. Januar 1970, 00:00:00 UTC) darstellt und die Zeit angibt, zu der sich der Nutzer zuletzt authentifiziert hat. Sie können sich das als Zeitstempel vorstellen, der das letzte Anmeldeereignis des Nutzers in seinem Google-Konto auf dem aktuellen Gerät oder im aktuellen Browser angibt. Dieser Anspruch ist im ID-Token enthalten, einem JSON-Web-Token (JWT), das bestätigte Informationen zur Authentifizierung und zum Nutzer enthält.

Der Anspruch auth_time ist für Ihre Anwendung wertvoll, da Sie damit feststellen können, wie lange es her ist, dass sich ein Nutzer auf dem verwendeten Gerät oder im verwendeten Browser aktiv in einem Google-Konto angemeldet hat. Dies kann aus Sicherheitsgründen besonders wichtig sein, z. B.:

  • Eine fundierte Entscheidung darüber treffen, ob Ihre App vor der Ausführung sensibler Nutzeraktionen wie dem Löschen des Kontos, dem Ändern der Kontaktmethoden für das Konto oder dem Ausführen einer Zahlung eine zusätzliche Authentifizierung in zwei Schritten erfordern sollte. Google unterstützt keine Anfragen zur erneuten Authentifizierung von Google-Konten.

  • Die Aktualität und Stabilität der Google-Kontositzung des Nutzers als Vertrauenssignal verwenden. Im Allgemeinen deutet ein aktueller Wert für auth_time auf Aktualität hin, während ein älterer Wert auf Stabilität hindeutet.

Bei Webanwendungen stellt die Kombination aus Browser und Betriebssystem des Nutzers eine Sitzung dar, nachdem sich der Nutzer in seinem Google-Konto angemeldet hat. Unabhängig davon verwaltet Ihre Website auch eine separate Nutzersitzung. Ein neuerer Wert für auth_time gibt an, dass sich der Nutzer kürzlich in seinem Google-Konto angemeldet hat. Dies ist oft ein Hinweis auf einen aktiven, engagierten Nutzer und kann als Signal für ein geringeres Risiko interpretiert werden.

Auf mobilen Plattformen wie Android melden sich Nutzer in der Regel direkt auf ihrem Gerät mit biometrischen Methoden wie Fingerabdruck oder Gesichtserkennung und gerätespezifischen PIN- oder Muster-Entsperrungen an. Mobile Apps und Plattformen verwenden häufig diese plattformbasierten Authentifizierungsmethoden, anstatt eine neue Sitzung mit Google zu erstellen. Dies führt zu seltenen Google-Kontoanmeldungen und entsprechenden Aktualisierungen von auth_time. Ein aktueller Wert für auth_time kann hier also eine Änderung an einer lang andauernden Google-Kontositzung und damit ein erhöhtes Risiko signalisieren.

Trust-Signale sind ein komplexes Thema. auth_time sollte zusammen mit anderen Signalen verwendet werden, z. B. ob die Multi-Faktor-Authentifizierung (MFA) aktiviert ist, welche Authentifizierungsmethode verwendet wurde und wie lange die Nutzersitzung zwischen Ihrer Anwendung und Ihrer Plattform dauert.

Anfragen

Die spezifische Methode zum Anfordern der Ansprüche auth_time und amr hängt von der verwendeten API ab. Jede API enthält jedoch einen optionalen Parameter claims, mit dem auth_time und amr angefordert werden können.

OIDC-Protokoll

Wenn Sie die OAuth-Plattform direkt verwenden, fordern Sie auth_time an, indem Sie sie dem optionalen Anforderungsparameter claims hinzufügen. Legen Sie für das Feld id_token des JSON-Objekts für Ansprüche den Wert {"auth_time":{"essential":true}} fest. Fügen Sie {"amr":{"essential":true}} zu claims hinzu, um amr anzufordern:

https://accounts.google.com/o/oauth2/v2/auth?
response_type=id_token&
client_id=YOUR_CLIENT_ID&
scope=openid email profile&
redirect_uri=https://example.com/user-login&
nonce=123-456-7890&
claims={ "id_token": {
            "auth_time": { "essential":true },
            "amr": {"essential":true}
          }
        }

Weitere Informationen finden Sie unter OpenID Connect.

Google Identity Services für das Web

Die Bibliothek „Über Google anmelden“ für das Web enthält zwei APIs: HTML und JavaScript, um zusätzliche Ansprüche anzufordern. Fordern Sie beispielsweise auth_time und amr mit der JavaScript API an:

<html>
<body>
  <script src="https://accounts.google.com/gsi/client" async></script>
  <script>
    window.onload = function () {
      google.accounts.id.initialize({
        client_id: "YOUR_WEB_CLIENT_ID",
        callback: function(rsp) { console.log(rsp.credential); },
        essential_claims: "auth_time, amr",
      });
      google.accounts.id.renderButton(
        document.getElementById("buttonDiv"),
        { type: "standard", size: "large" }
      );
    }
  </script>
  <div id="buttonDiv"></div>
</body>
</html>

Weitere Informationen finden Sie unter Über Google anmelden für das Web.

Google Identity Services für Android

Eine setClaims Methode und ein Claim Objekt werden verwendet, um auth_time und amr anzufordern.

Aktualisieren Sie Ihre Build-Abhängigkeiten, um die neuesten Versionen der Bibliotheken androidx.credentials:credentials-play-services-auth und com.google.android.libraries.identity.googleid:googleid zu verwenden.

Instanziieren Sie Claim Objekte vom Typ auth_time und amr, und fügen Sie sie mit setClaims der Liste der Anmeldeoptionen hinzu:

val googleIdOption: GetGoogleIdOption = GetGoogleIdOption.Builder()
    .setAutoSelectEnabled(true)
    .setFilterByAuthorizedAccounts(true)
    .setServerClientId(WEB_CLIENT_ID)
    .setNonce("NONCE")
    .setClaims(ImmutableList.of(
           new Claim("auth_time", true),
           new Claim("amr", true)
    ))
    .build()

Weitere Informationen finden Sie unter Nutzer mit „Über Google anmelden“ authentifizieren.

iOS

Das Über Google anmelden-SDK für iOS fügt der Klasse GIDSignIn ein Objekt authTimeClaim und einen Parameter claims hinzu, mit denen optional auth_time und amr angefordert werden können.

Apps, die ASWebAuthenticationSession verwenden, aktualisieren einen geräteübergreifenden gemeinsamen Cookie-Speicher. GIDSignIn verwendet diese Methode standardmäßig unter iOS 12 oder höher und macOS 10.15 oder höher. In diesem Fall wird ein Nutzer, der sich in seinem Google-Konto anmeldet, authentifiziert und die Sitzung wird im gemeinsamen Cookie-Speicher gespeichert. Hier ist auth_time die letzte Google-Authentifizierung des Nutzers auf dem Gerät, nicht nur in Ihrer App.

SFSafariViewController, WKWebView und UIWebView werden in isolierten Sandboxes in Ihrer App ausgeführt. Verwenden Sie sie nicht, wenn Sie auth_time verwenden. Hier ist auth_time die letzte Anmeldung des Nutzers in der App selbst. Da der Wert immer aktuell ist, ist er weniger aussagekräftig.

Wenn Sie auth_time anfordern möchten, aktualisieren Sie die GoogleSignIn-Abhängigkeiten auf die neueste Version und erstellen Sie ein authTimeClaim-Objekt, das Sie dem Satz claims hinzufügen.

Wenn Sie amr anfordern möchten, erstellen Sie ein amrClaim-Objekt und fügen Sie es dem Satz claims hinzu.

Swift

Fügen Sie den Satz für Ansprüche der Methode GIDSignIn.sharedInstance.signIn hinzu:

let authTimeClaim = GIDClaim.authTime()
let amrClaim = GIDClaim.amr()
let claims = Set([authTimeClaim, amrClaim])

// Start the sign-in process GIDSignIn.sharedInstance.signIn( withPresenting: rootViewController, claims: claims ) { signInResult, error in guard let result = signInResult else { print("Error signing in: (error?.localizedDescription ?? "No error description")") return } // If sign in succeeded, display the app's main content View print("ID Token: (result.user.idToken?.tokenString ?? "No token")") }

Objective-C

Fügen Sie den Satz für Ansprüche der Methode signInWithPresentingViewController hinzu:

GIDClaim *authTimeClaim = [GIDClaim authTimeClaim];
GIDClaim *AMRClaim = [GIDClaim AMRClaim];
NSSet *claims = [NSSet setWithArray:@[authTimeClaim, AMRClaim]];

// Include the claims set and start the sign-in process [GIDSignIn.sharedInstance signInWithPresentingViewController:self hint:nil claims:claims completion:^(GIDSignInResult * _Nullable signInResult, NSError * _Nullable error) { // On success signInResult.user.idToken // contains the requested claims. }];

Weitere Informationen finden Sie unter Google Log-in in Ihre iOS- oder macOS-App einbinden.

Antworten

Wenn die Ansprüche auth_time oder amr in der Anfrage enthalten sind, werden sie in der Nutzlastantwort des ID-Tokens zusammen mit anderen Standardansprüchen wie iss (Aussteller), sub (Subjekt), aud (Zielgruppe) und exp (Ablaufzeit) zurückgegeben.

Fehlende Ansprüche sind wahrscheinlich darauf zurückzuführen, dass die App nicht bestätigt wurde oder zusätzliche Einstellungen deaktiviert sind. Das ist die Standardeinstellung. Folgen Sie der Anleitung unter Einrichtung, um zu prüfen, ob die Client-ID und die verwendete App bestätigt sind und zusätzliche Ansprüche aktiviert sind.

Der Wert des Anspruchs auth_time ist eine JSON-Zahl, die die Anzahl der Sekunden seit der Unix-Epoche (1. Januar 1970, 00:00:00 UTC) bis zum Zeitpunkt der letzten Nutzerauthentifizierung darstellt.

Der Wert des Anspruchs amr ist ein JSON-Array von Strings, die die Authentifizierungsmethoden darstellen, die beim letzten Anmeldeereignis für das Google-Konto verwendet wurden.

Hier sehen Sie ein Beispiel für ein decodiertes ID-Token, das die Ansprüche auth_time und amr enthält:

{
  "iss": "https://accounts.google.com",
  "azp": "YOUR_CLIENT_ID",
  "aud": "YOUR_CLIENT_ID",
  "sub": "117726431651943698600",
  "email": "alice@example.com",
  "email_verified": true,
  "nonce": "123-456-7890",
  "auth_time": 1748875426,
  "amr": ["mfa", "pwd", "tel"],
  "nbf": 1748880889,
  "name": "Elisa Beckett",
  "picture": "https://lh3.googleusercontent.com/a/default-user=s96-c",
  "given_name": "Elisa",
  "family_name": "Beckett",
  "iat": 1748881189,
  "exp": 1748884789,
  "jti": "8b5d7ce345787d5dbf14ce6e08a8f88ee8c9b5b1"
}

Das ID-Token enthält auch einen Anspruch iat (ausgestellt am), der den Zeitpunkt angibt, zu dem das JWT ausgestellt wurde. Wenn Sie die Ansprüche iat und auth_time vergleichen, können Sie die Zeit ermitteln, die seit der letzten Authentifizierung des Nutzers bis zur Erstellung des jeweiligen ID-Tokens vergangen ist. Wenn iat beispielsweise 1748881189 und auth_time 1748875426 ist, beträgt die Differenz 5763 Sekunden, was 1 Stunde, 36 Minuten und 3 Sekunden entspricht.