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, Google OAuth-Interaktionen mithilfe sichererer OAuth-Abläufe sicherer zu machen. In diesem Leitfaden werden die Änderungen und Schritte erläutert, die für eine erfolgreiche Migration vom Loopback-IP-Adressfluss zu unterstützten Alternativen erforderlich sind.

Diese Maßnahme dient dem Schutz vor Phishing und Angriffen durch App-Identitätsdiebstahl bei Interaktionen mit den OAuth 2.0-Autorisierungsendpunkten von Google.

Was ist der Ablauf der Loopback-IP-Adresse?

Der Loopback-IP-Adressfluss unterstützt die Verwendung einer Loopback-IP-Adresse oder localhost als Hostkomponente des Weiterleitungs-URI, an den Anmeldedaten gesendet werden, nachdem ein Nutzer eine OAuth-Zustimmungsanfrage 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 Zugriff auf den Autorisierungscode erhält.

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

Wichtige Termine für die Einhaltung der Richtlinie

14. März 2022: Neue OAuth-Clients können den Loopback-IP-Adressfluss nicht mehr verwenden.
1. August 2022: Nutzer sehen bei nicht konformen OAuth-Anfragen möglicherweise eine Warnmeldung.
31. August 2022: Der Loopback-IP-Adressfluss 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 an den Nutzer angezeigt. In der Meldung wird den Nutzern mitgeteilt, dass die Anwendung blockiert ist. Gleichzeitig wird die Support-E-Mail angezeigt, 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, wenn Sie betroffen sind.

Ermitteln, ob Sie betroffen sind

OAuth-Client-ID-Typ überprüfen

Rufe die Credentials page der Google API Console auf und sieh dir im Abschnitt OAuth 2.0-Client-IDs den OAuth-Client-ID-Typ an. Es kann sich um eines der folgenden Formate handeln: Webanwendung, Android, iOS, Universelle Windows-Plattform (UWP), Chrome App, Fernseher und Geräte mit begrenzter Eingabe, Desktop-App.

Wenn Ihr Clienttyp Android, die Chrome-App oder iOS ist und Sie den Loopback-IP-Adressfluss verwenden, fahren Sie mit dem nächsten Schritt fort.

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

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

Prüfen Sie Ihren Anwendungscode oder den ausgehenden Netzwerkaufruf (falls Ihre Anwendung eine OAuth-Bibliothek verwendet), um festzustellen, ob die von Ihrer Anwendung gesendete 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 stellen Sie fest, 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:Sie sollten auch Ihre Anwendungskonfigurationsdateien (z. B. .env-Dateien) prüfen, da die redirect_uri-Werte in der Regel je nach Umgebung, in der die Anwendung ausgeführt wird, unterschiedlich eingerichtet sind.

Ausgehenden Netzwerkanruf prüfen

Die Methode zur Prüfung 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
- Rufen Sie 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, in dem Sie den Netzwerkverkehr auf dem Tab „Netzwerk“ überwachen können.
iOS – HTTP-Traffic mit Instrumenten analysieren
Universal Windows Platform (UWP) – Netzwerktraffic in Visual Studio prüfen
Desktop-Anwendungen: Verwenden Sie 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

Ein Beispiel für eine Loopback-IP-Adressweiterleitungsanfrage 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>

Zu einer unterstützten Alternative migrieren

Mobile Clients (Android / iOS)

Wenn du feststellst, dass deine App den Loopback-IP-Adressfluss mit einem OAuth-Clienttyp für Android oder iOS 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 an die 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 eine Loopback-IP-Adress-Weiterleitungs-URI zu verwenden.

Auf Google APIs auf Android-Geräten zugreifen

Serverseitiger (Offline-)Zugriff

Das folgende Beispiel zeigt, wie der serverseitige Zugriff auf Google APIs unter Android erfolgt.

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 erfahren Sie, wie Sie serverseitig auf Google APIs zugreifen können.

Mit einer iOS-App auf Google APIs zugreifen

Clientseitiger Zugriff

Das folgende Beispiel zeigt, wie Sie mit iOS clientseitig auf Google APIs zugreifen.

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. Fügen Sie dazu entweder das Zugriffstoken in den Header einer REST- oder gRPC-Anfrage (Authorization: Bearer ACCESS_TOKEN) ein oder verwenden Sie den Fetcher-Autorisierungscode (GTMFetcherAuthorizationProtocol) mit der Google APIs-Clientbibliothek für Objective-C für REST.

Lesen Sie in der Anleitung für den clientseitigen Zugriff nach, wie Sie clientseitig auf Google APIs zugreifen können. wie Sie clientseitig auf Google APIs zugreifen.

Serverseitiger (Offline-)Zugriff

Das folgende Beispiel zeigt, wie serverseitig auf Google APIs zugegriffen werden kann, 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 den serverseitigen Zugriff erfahren Sie, wie Sie serverseitig auf Google APIs zugreifen können.

Chrome-App-Client

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

Das folgende Beispiel zeigt, wie Sie alle Nutzerkontakte abrufen können, ohne eine Loopback-IP-Adress-Weiterleitungs-URI 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)
    });
   });
 });
};

Weitere Informationen dazu, wie Sie mit der Chrome Identity API auf Nutzer authentifizieren und Google-Endpunkte aufrufen, finden Sie im Leitfaden zur Chrome Identity API.