Diese Seite wurde von der Cloud Translation API übersetzt.

Migrationsanleitung für Loopback-IP-Adressenfluss

Überblick

Am 16. Februar 2022 haben wir Pläne angekündigt, die Google OAuth-Interaktionen durch die Verwendung sichererer OAuth-Abläufe sicherer zu machen. In dieser Anleitung werden die erforderlichen Änderungen und Schritte für eine erfolgreiche Migration vom Loopback-IP-Adressfluss zu unterstützten Alternativen erklärt.

Diese Maßnahme dient als Schutzmaßnahme gegen Phishing und App-Identitätsdiebstahl bei Interaktionen mit den OAuth 2.0-Autorisierungsendpunkten von Google.

Was ist der Loopback-IP-Adressprozess?

Der Loopback-IP-Adressablauf unterstützt die Verwendung einer Loopback-IP-Adresse oder die Verwendung von localhost als Hostkomponente des Weiterleitungs-URI, an den Anmeldedaten gesendet werden, nachdem ein Nutzer eine OAuth-Einwilligungsanfrage genehmigt hat. Dieser Ablauf ist anfällig für Man-in-the-Middle-Angriffe, bei denen eine bösartige Anwendung, die unter einigen Betriebssystemen auf dieselbe Loopback-Schnittstelle zugreift, die Antwort vom Autorisierungsserver an den angegebenen Weiterleitungs-URI abfängt und dann Zugriff auf den Autorisierungscode erhält.

Der Loopback-IP-Adressprozess wird für die nativen OAuth-Clienttypen von iOS, Android und Chrome eingestellt, in Desktop-Apps aber weiterhin unterstützt.

Wichtige Compliancedaten

14. März 2022 – Neue OAuth-Clients können den Loopback-IP-Adressprozess nicht mehr verwenden.
1. August 2022: Für nicht konforme OAuth-Anfragen wird möglicherweise eine Warnmeldung für Nutzer angezeigt.
31. August 2022: Der Loopback-IP-Adressvorgang wird für native Android-, Chrome-App- und iOS-OAuth-Clients, die vor dem 14. März 2022 erstellt wurden, blockiert.
21. Oktober 2022 – alle vorhandenen Clients werden blockiert (einschließlich ausgenommener Clients)

Für nicht konforme Anfragen wird eine Fehlermeldung für Nutzer angezeigt. Nutzer werden in der Meldung darüber informiert, dass die App blockiert ist, und sie zeigt die Support-E-Mail-Adresse an, die Sie auf dem OAuth-Zustimmungsbildschirm in der Google API Console registriert haben.

Für den Migrationsprozess sind zwei Hauptschritte erforderlich:

Stellen Sie fest, ob Sie betroffen sind.
Migrieren Sie zu einer unterstützten Alternative, falls Sie betroffen sind.

Ermitteln, ob Sie betroffen sind

Typ der OAuth-Client-ID prüfen

Rufe die Credentials page der Google API Console auf und sieh dir im Abschnitt OAuth 2.0-Client-IDs deinen OAuth-Client-ID-Typ an. Dabei kann es sich um eines der folgenden Geräte handeln: Webanwendung, Android, iOS, Universal Windows Platform (UWP), Chrome App, Fernseher und eingeschränkte Eingabegeräte, Desktop-App.

Fahren Sie mit dem nächsten Schritt fort, wenn Ihr Clienttyp Android, Chrome-App oder iOS ist und Sie den Loopback-IP-Adressprozess verwenden.

Sie müssen im Zusammenhang mit dieser Einstellung nichts unternehmen, wenn Sie den Loopback-IP-Adressprozess für den OAuth-Client einer Desktop-Anwendung verwenden, da die Verwendung mit diesem OAuth-Clienttyp weiterhin unterstützt wird.

So ermitteln Sie, ob Ihre App den Loopback-IP-Adressfluss verwendet

Prüfe deinen Anwendungscode oder den ausgehenden Netzwerkaufruf, falls deine Anwendung eine OAuth-Bibliothek verwendet, um festzustellen, ob die von deiner Anwendung durchgeführte Google OAuth-Autorisierungsanfrage Loopback-Weiterleitungs-URI-Werte verwendet.

Anwendungscode prüfen

Prüfen Sie den Abschnitt Ihres Anwendungscodes, in dem Sie Aufrufe an die Autorisierungsendpunkte von Google OAuth senden, und ermitteln Sie, ob der Parameter redirect_uri einen der folgenden Werte hat:

redirect_uri=http://127.0.0.1:<port> z.B. redirect_uri=http://127.0.0.1:3000
redirect_uri=http://[::1]:<port> z.B. redirect_uri=http://[::1]:3000
redirect_uri=http://localhost:<port> z.B. redirect_uri=http://localhost:3000

Eine Beispielanfrage für einen Loopback-IP-Adressweiterleitungsfluss sieht so aus:

https://accounts.google.com/o/oauth2/v2/auth?
redirect_uri=http://localhost:3000&
response_type=code&
scope=<SCOPES>&
state=<STATE>&
client_id=<CLIENT_ID>

Hinweis: Prüfen Sie auch Ihre Anwendungskonfigurationsdateien (z. B. .env-Dateien), da die redirect_uri-Werte in der Regel je nach Umgebung, in der die Anwendung ausgeführt wird, unterschiedlich eingerichtet sind.

Ausgehende Netzwerkanrufe prüfen

Die Methode zum Prüfen von Netzwerkaufrufen hängt vom Clienttyp Ihrer Anwendung ab.

Webanwendung – Netzwerkaktivität in Chrome prüfen
Android: Netzwerktraffic mit dem Network Inspector prüfen
Chrome-Apps
- Rufe die Seite für Chrome-Erweiterungen auf.
- Klicken Sie rechts oben auf der Erweiterungsseite das Kästchen Entwicklermodus an.
- Erweiterung auswählen, die überwacht werden soll
- Klicken Sie auf der Erweiterungsseite im Bereich Ansichten prüfen auf den Link Hintergrundseite.
- Ein Pop-up-Fenster mit Entwicklertools wird geöffnet. Dort können Sie den Netzwerkverkehr auf dem Tab „Netzwerk“ überwachen.
iOS – HTTP-Traffic mit Instruments analysieren
Universal Windows Platform (UWP) – Netzwerktraffic in Visual Studio prüfen
Desktop-Apps: Verwendet ein Netzwerkerfassungstool, das für das Betriebssystem verfügbar ist, für das die App entwickelt wurde

Suchen Sie bei der Prüfung von Netzwerkaufrufen nach Anfragen, die an die Autorisierungsendpunkte von Google OAuth gesendet wurden. Prüfen Sie dann, ob der Parameter redirect_uri einen der folgenden Werte hat:

redirect_uri=http://127.0.0.1:<port> z.B. redirect_uri=http://127.0.0.1:3000
redirect_uri=http://[::1]:<port> z.B. redirect_uri=http://[::1]:3000
redirect_uri=http://localhost:<port> z.B. redirect_uri=http://localhost:3000

Hier ein Beispiel für eine Loopback-IP-Adressweiterleitungsanfrage:

https://accounts.google.com/o/oauth2/v2/auth?
redirect_uri=http://localhost:3000&
response_type=code&
scope=<SCOPES>&
state=<STATE>&
client_id=<CLIENT_ID>

Zu einer unterstützten Alternative migrieren

Mobile Clients (Android / iOS)

Wenn du feststellst, dass deine App den Loopback-IP-Adressfluss mit einem Android- oder iOS-OAuth-Clienttyp verwendet, solltest du zu unseren mobilen Google Log-in-SDKs (Android, iOS) migrieren.

Das SDK erleichtert den Zugriff auf Google APIs und verarbeitet alle Aufrufe der OAuth 2.0-Autorisierungsendpunkte von Google.

Unter den folgenden Dokumentationslinks erfährst du, wie du mit den Google Log-in SDKs auf Google APIs zugreifen kannst, ohne einen Weiterleitungs-URI für Loopback-IP-Adressen zu verwenden.

Unter Android auf Google APIs zugreifen

Serverseitiger (Offline-)Zugriff

Das folgende Beispiel zeigt, wie unter Android serverseitig auf Google APIs zugegriffen wird.

Task<GoogleSignInAccount> task = GoogleSignIn.getSignedInAccountFromIntent(data);
try {
  GoogleSignInAccount account = task.getResult(ApiException.class);
  
  // request a one-time authorization code that your server exchanges for an
  // access token and sometimes refresh token
  String authCode = account.getServerAuthCode();
  
  // Show signed-in UI
  updateUI(account);

  // TODO(developer): send code to server and exchange for access/refresh/ID tokens
} catch (ApiException e) {
  Log.w(TAG, "Sign-in failed", e);
  updateUI(null);
}

In der Anleitung für den serverseitigen Zugriff erfährst du, wie du serverseitig auf Google APIs zugreifen kannst.

Mit einer iOS-App auf Google APIs zugreifen

Clientseitiger Zugriff

Das folgende Beispiel zeigt, wie über iOS clientseitig auf Google APIs zugegriffen wird.

user.authentication.do { authentication, error in
  guard error == nil else { return }
  guard let authentication = authentication else { return }
  
  // Get the access token to attach it to a REST or gRPC request.
  let accessToken = authentication.accessToken
  
  // Or, get an object that conforms to GTMFetcherAuthorizationProtocol for
  // use with GTMAppAuth and the Google APIs client library.
  let authorizer = authentication.fetcherAuthorizer()
}

Verwenden Sie das Zugriffstoken, um die API aufzurufen. Nehmen Sie dazu entweder das Zugriffstoken in den Header einer REST- oder gRPC-Anfrage (Authorization: Bearer ACCESS_TOKEN) auf oder verwenden Sie den Abruf-Autorisierenden (GTMFetcherAuthorizationProtocol) mit der Google APIs-Clientbibliothek für Objective-C für REST.

Wie du clientseitig auf Google APIs zugreifen kannst, erfährst du in der Anleitung für clientseitigen Zugriff. wie Sie clientseitig auf Google APIs zugreifen können.

Serverseitiger (Offline-)Zugriff

Das folgende Beispiel zeigt, wie serverseitig auf Google APIs zugegriffen wird, um einen iOS-Client zu unterstützen.

GIDSignIn.sharedInstance.signIn(with: signInConfig, presenting: self) { user, error in
  guard error == nil else { return }
  guard let user = user else { return }
  
  // request a one-time authorization code that your server exchanges for
  // an access token and refresh token
  let authCode = user.serverAuthCode
}

In der Anleitung für serverseitigen Zugriff erfährst du, wie du serverseitig auf Google APIs zugreifen kannst.

Chrome-App-Client

Wenn Sie feststellen, dass Ihre Anwendung den Loopback-IP-Adressfluss im Client der Chrome-Anwendung verwendet, sollten Sie zur Chrome Identity API migrieren.

Im folgenden Beispiel wird gezeigt, wie Sie alle Nutzerkontakte abrufen können, ohne einen Weiterleitungs-URI für Loopback-IP-Adressen zu verwenden.

window.onload = function() {
  document.querySelector('button').addEventListener('click', function() {

  
  // retrieve access token
  chrome.identity.getAuthToken({interactive: true}, function(token) {
  
  // ..........


  // the example below shows how to use a retrieved access token with an appropriate scope
  // to call the Google People API contactGroups.get endpoint

  fetch(
    'https://people.googleapis.com/v1/contactGroups/all?maxMembers=20&key=API_KEY',
    init)
    .then((response) => response.json())
    .then(function(data) {
      console.log(data)
    });
   });
 });
};

In der Anleitung zur Chrome Identity API finden Sie weitere Informationen dazu, wie Sie mit der Chrome Identity API auf Authentifizierung von Nutzern zugreifen und Google-Endpunkte aufrufen.