Diese Seite wurde von der Cloud Translation API übersetzt.

Migrationsanleitung für Out-of-Band-Datenflüsse (OOB)

Ü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 die erfolgreiche Migration vom OAuth-Out-of-Band-Vorgang (OOB) 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 OOB?

OAuth Out-of-Band (OOB), auch als manuelle Option zum Kopieren und Einfügen bezeichnet, ist ein alter Ablauf, der für native Clients entwickelt wurde, die keinen Weiterleitungs-URI haben, über den die Anmeldedaten akzeptiert werden können, nachdem ein Nutzer eine OAuth-Zustimmungsanfrage genehmigt hat. Der OOB-Ablauf birgt ein Remote-Phishing-Risiko und Clients müssen zu einer alternativen Methode migrieren, um sich vor dieser Sicherheitslücke zu schützen.

Der OOB-Ablauf wird für alle Clienttypen eingestellt, z.B. Webanwendungen, Android, iOS, Universal Windows Platform (UWP), Chrome-Apps, Fernseher, Geräte mit begrenzter Eingabe und Desktop-Apps.

Wichtige Compliancedaten

28. Februar 2022: Neue OAuth-Nutzung im OOB-Ablauf blockiert
5. September 2022: Für Nutzer wird möglicherweise für nicht konforme OAuth-Anfragen eine Warnmeldung angezeigt.
3. Oktober 2022: Der OOB-Vorgang wird für OAuth-Clients, die vor dem 28. Februar 2022 erstellt wurden, eingestellt.
31. Januar 2023 – 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.

Der Migrationsprozess umfasst zwei Hauptschritte:

Stellen Sie fest, ob Sie betroffen sind.
Migrieren Sie zu einer sichereren Alternative, falls Sie betroffen sind.

Ermitteln, ob Sie betroffen sind

Diese Einstellung gilt nur für Produktions-Apps, d. h. Apps, deren Veröffentlichungsstatus auf In Produktion gesetzt ist. Der Ablauf funktioniert weiterhin für Apps mit dem Veröffentlichungsstatus „Test“.

Überprüfe deinen Veröffentlichungsstatus in den OAuth- der und fahre mit dem nächsten Schritt fort, wenn du den OOB-Vorgang in einem Projekt mit dem Veröffentlichungsstatus „In Produktion“ verwendest.

So findest du heraus, ob deine App den OOB-Ablauf verwendet

Prüfen Sie den Anwendungscode oder den ausgehenden Netzwerkaufruf, falls Ihre Anwendung eine OAuth-Bibliothek verwendet, um festzustellen, ob für die Google OAuth-Autorisierungsanfrage Ihrer Anwendung ein URI-Wert für die OOB-Weiterleitung verwendet wird.

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=urn:ietf:wg:oauth:2.0:oob
redirect_uri=urn:ietf:wg:oauth:2.0:oob:auto
redirect_uri=oob

Eine Beispielanfrage für einen OOB-Weiterleitungsvorgang sieht so aus:

https://accounts.google.com/o/oauth2/v2/auth?
response_type=code&
scope=<SCOPES>&
state=<STATE>&
redirect_uri=urn:ietf:wg:oauth:2.0:oob&
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=urn:ietf:wg:oauth:2.0:oob
redirect_uri=urn:ietf:wg:oauth:2.0:oob:auto
redirect_uri=oob

Hier ein Beispiel für eine OOB-Weiterleitungsanfrage:

https://accounts.google.com/o/oauth2/v2/auth?
response_type=code&
scope=<SCOPES>&
state=<STATE>&
redirect_uri=urn:ietf:wg:oauth:2.0:oob&
client_id=<CLIENT_ID>

Zu einer sicheren Alternative migrieren

Mobile Clients (Android / iOS)

Wenn du feststellst, dass deine App den OOB-Vorgang 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 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 OOB-Weiterleitungs-URI 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 du feststellst, dass deine Anwendung den OOB-Vorgang auf dem Chrome-Anwendungsclient verwendet, solltest du zur Chrome Identity API migrieren.

Im folgenden Beispiel wird gezeigt, wie Sie alle Nutzerkontakte abrufen können, ohne einen OOB-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)
    });
   });
 });
};

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.

Webanwendung

Wenn du feststellst, dass deine App den OOB-Ablauf für eine Webanwendung verwendet, solltest du zu einer unserer Google API-Clientbibliotheken migrieren. Clientbibliotheken für verschiedene Programmiersprachen

Die Bibliotheken erleichtern den Zugriff auf Google APIs und die Verarbeitung aller Aufrufe an die Google-Endpunkte.

Serverseitiger (Offline-)Zugriff

Für den serverseitigen (Offline-)Zugriff ist Folgendes erforderlich:

Richten Sie einen Server ein und definieren Sie einen öffentlich zugänglichen Endpunkt (den Weiterleitungs-URI) für den Empfang des Autorisierungscodes.
Konfigurieren Sie den Weiterleitungs-URI in der

Das folgende Code-Snippet zeigt ein NodeJS-Beispiel für die Verwendung der Google Drive API, um die Google Drive-Dateien eines Nutzers auf Serverseite aufzulisten, ohne einen OOB-Weiterleitungs-URI zu verwenden.

async function main() {
  const server = http.createServer(async function (req, res) {

  if (req.url.startsWith('/oauth2callback')) {
    let q = url.parse(req.url, true).query;

    if (q.error) {
      console.log('Error:' + q.error);
    } else {
      
      // Get access and refresh tokens (if access_type is offline)
      let { tokens } = await oauth2Client.getToken(q.code);
      oauth2Client.setCredentials(tokens);

      // Example of using Google Drive API to list filenames in user's Drive.
      const drive = google.drive('v3');
      drive.files.list({
        auth: oauth2Client,
        pageSize: 10,
        fields: 'nextPageToken, files(id, name)',
      }, (err1, res1) => {
        // TODO(developer): Handle response / error.
      });
    }
  }
}

Wie du serverseitig auf Google APIs zugreifen kannst, erfährst du im Leitfaden zu serverseitigen Webanwendungen.

Clientseitiger Zugriff

Das folgende Code-Snippet in JavaScript zeigt ein Beispiel für die Verwendung der Google API, um clientseitig auf die Kalendertermine von Nutzern zuzugreifen.


// initTokenClient() initializes a new token client with your
// web app's client ID and the scope you need access to

const client = google.accounts.oauth2.initTokenClient({
  client_id: 'YOUR_GOOGLE_CLIENT_ID',
  scope: 'https://www.googleapis.com/auth/calendar.readonly',
  
  // callback function to handle the token response
  callback: (tokenResponse) => {
    if (tokenResponse && tokenResponse.access_token) { 
      gapi.client.setApiKey('YOUR_API_KEY');
      gapi.client.load('calendar', 'v3', listUpcomingEvents);
    }
  },
});

function listUpcomingEvents() {
  gapi.client.calendar.events.list(...);
}

In der Anleitung für clientseitige Webanwendungen erfahren Sie, wie Sie clientseitig auf Google APIs zugreifen können.

Desktop-Client

Wenn Sie feststellen, dass Ihre Anwendung den OOB-Ablauf auf einem Desktop-Client verwendet, sollten Sie zum Loopback-IP-Adressvorgang (localhost oder 127.0.0.1) migrieren.