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

Übersicht

Am 16. Februar 2022 haben wir Pläne angekündigt, die Google OAuth-Interaktionen sicherer zu machen, indem wir sicherere OAuth Abläufe verwenden. Diese Anleitung hilft Ihnen, die erforderlichen Änderungen und Schritte nachzuvollziehen, um erfolgreich vom OAuth-Out-of-Band-Ablauf (OOB) zu unterstützten Alternativen zu migrieren.

Diese Maßnahme dient dem Schutz vor Phishing- und App-Imitationsangriffen bei Interaktionen mit den OAuth 2.0-Autorisierungsendpunkten von Google.

Was ist OOB?

OAuth Out-of-Band (OOB), auch als manuelle Kopier- und Einfügeoption bezeichnet, ist ein Legacy-Ablauf, der entwickelt wurde, um installierte Clients zu unterstützen, die keinen Weiterleitungs-URI haben, um die Anmeldedaten zu akzeptieren, nachdem ein Nutzer eine OAuth-Zustimmungsanfrage genehmigt hat. Der OOB-Ablauf birgt ein Phishing-Risiko aus der Ferne 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, d.h. für Webanwendungen, Android, iOS, Universal Windows Platform (UWP), Chrome-Apps, Fernseher und Geräte mit eingeschränkter Eingabe, Desktop-Apps.

Wichtige Termine für die Einhaltung von Richtlinien

• 28. Februar 2022 : Neue OAuth-Nutzung für den OOB-Ablauf blockiert
• 5. September 2022 : Nutzern wird möglicherweise eine Warnmeldung für nicht konforme OAuth-Anfragen angezeigt
• 3. Oktober 2022 : Der OOB-Ablauf wird für OAuth-Clients eingestellt, die vor dem 28. Februar 2022 erstellt wurden
• 31. Januar 2023 : Alle vorhandenen Clients werden blockiert (einschließlich ausgenommener Clients)

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

Hinweis: Wenn Sie Erinnerungen und Benachrichtigungen von Google zu dieser Einstellung erhalten möchten, müssen Sie die Kontaktinformationen für Ihre App entsprechend konfiguriert haben. Überprüfen Sie dazu die Support- und Kontakt-E-Mail-Adressen für Ihr Projekt auf der Seite OAuth-Branding in der Google Cloud Console.

Der Migrationsvorgang umfasst zwei Hauptschritte:

1. Prüfen Sie, ob Sie betroffen sind.
2. Migrieren Sie zu einer sichereren Alternative, wenn Sie betroffen sind.

Prüfen, 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 „Testen“.

Hinweis: Die Einstellung gilt sowohl für interne als auch für externe Apps in der Produktion.

Prüfen Sie den Veröffentlichungsstatus auf der Seite OAuth-Branding in der Google Cloud Console und fahren Sie mit dem nächsten Schritt fort, wenn Sie den OOB-Ablauf in einem Projekt mit dem Veröffentlichungsstatus „In Produktion“ verwenden.

Prüfen, ob Ihre App den OOB-Ablauf verwendet

Prüfen Sie den App-Code oder den ausgehenden Netzwerkaufruf (falls Ihre App eine OAuth-Bibliothek verwendet), um festzustellen, ob die Google OAuth Autorisierungsanfrage Ihrer App einen OOB-Weiterleitungs-URI-Wert verwendet.

Hinweis: Wenn Sie eine Bibliothek verwenden, um Ihre Authentifizierungs- und Autorisierungsabläufe zu verwalten, sollten Sie trotzdem den Netzwerkaufruf prüfen, da einige Bibliotheken die Verwendung des OOB Weiterleitungs-URI-Werts abstrahieren.

Anwendungscode prüfen

Prüfen Sie den Abschnitt Ihres Anwendungscodes, in dem Sie Aufrufe an die Google OAuth-Autorisierungsendpunkte ausführen, und stellen Sie fest, ob der redirect_uri Parameter 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 den OOB-Weiterleitungsablauf 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: Sie sollten auch die Konfigurationsdateien Ihrer Anwendung prüfen (z. B. .env Dateien), da die redirect_uri Werte in der Regel je nach Umgebung, in der die Anwendung ausgeführt wird, unterschiedlich sind.

Ausgehenden Netzwerkaufruf prüfen

Die Methode zum Prüfen von Netzwerkaufrufen variiert je nach Clienttyp der Anwendung.

• Webanwendung - Netzwerkaktivität in Chrome prüfen
• Android - Netzwerkverkehr mit dem Netzwerk-Inspector prüfen
• Chrome-Apps
  • Rufen Sie die Seite mit den Chrome-Erweiterungen auf.
  • Aktivieren Sie das Kästchen Entwicklermodus rechts oben auf der Seite mit den Erweiterungen.
  • Wählen Sie die Erweiterung aus, die Sie beobachten möchten.
  • Klicken Sie im Abschnitt Ansichten prüfen der Erweiterungsseite auf den Link Hintergrundseite.
  • Ein Pop-up-Fenster mit den Entwicklertools wird geöffnet, in dem Sie den Netzwerkverkehr auf dem Tab Netzwerk beobachten können.
• iOS - HTTP-Traffic mit Instruments analysieren
• Desktop-Apps : Verw101}enden Sie ein Tool zur Netzwerkerfassung, das für das Betriebssystem verfügbar ist, für das die App entwickelt wurde.

Suchen Sie beim Prüfen von Netzwerkaufrufen nach Anfragen, die an die Google OAuth Autorisierungsendpunkte gesendet werden, und stellen Sie fest, ob der redirect_uri Parameter 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 den OOB-Weiterleitungsablauf 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>

Zu einer sicheren Alternative migrieren

Mobile Clients (Android / iOS)

Wenn Sie feststellen, dass Ihre App den OOB-Ablauf mit einem Android- oder iOS OAuth-Clienttyp verwendet, sollten Sie zu den empfohlenen SDKs migrieren (Android, iOS).

Mit dem SDK können Sie ganz einfach auf Google APIs zugreifen und alle Aufrufe an die OAuth 2.0-Autorisierungsendpunkte von Google verarbeiten.

In den folgenden Dokumentationslinks finden Sie Informationen zur Verwendung der empfohlenen SDKs für den Zugriff auf Google APIs ohne OOB Weiterleitungs-URI.

Auf Google APIs unter Android zugreifen

Clientseitiger Zugriff

Das folgende Beispiel zeigt, wie Sie unter Android clientseitig auf Google APIs zugreifen. Dazu wird die empfohlene Google Identity Services Android Library verwendet.

  List requestedScopes = Arrays.asList(DriveScopes.DRIVE_APPDATA);
    AuthorizationRequest authorizationRequest = AuthorizationRequest.builder().setRequestedScopes(requestedScopes).build();
    Identity.getAuthorizationClient(activity)
            .authorize(authorizationRequest)
            .addOnSuccessListener(
                authorizationResult -> {
                  if (authorizationResult.hasResolution()) {
                    // Access needs to be granted by the user
                    PendingIntent pendingIntent = authorizationResult.getPendingIntent();
                    try {
    startIntentSenderForResult(pendingIntent.getIntentSender(),
    REQUEST_AUTHORIZE, null, 0, 0, 0, null);
                    } catch (IntentSender.SendIntentException e) {
                    Log.e(TAG, "Couldn't start Authorization UI: " + e.getLocalizedMessage());
                    }
                  } else {
                    // Access already granted, continue with user action
                    saveToDriveAppFolder(authorizationResult);
                  }
                })
            .addOnFailureListener(e -> Log.e(TAG, "Failed to authorize", e));

Übergeben Sie authorizationResult an die von Ihnen definierte Methode, um Inhalte im Drive-Ordner des Nutzers zu speichern. Das authorizationResult hat die getAccessToken() Methode, die das Zugriffstoken zurückgibt.

Serverseitiger (Offline-)Zugriff

Das folgende Beispiel zeigt, wie Sie unter Android serverseitig auf Google APIs zugreifen.

Hinweis: Für den serverseitigen (Offline-)Zugriffsmodus müssen Sie einen Server einrichten und einen öffentlich verfügbaren Endpunkt haben, um den Autorisierungscode zu empfangen.

  List requestedScopes = Arrays.asList(DriveScopes.DRIVE_APPDATA);
    AuthorizationRequest authorizationRequest = AuthorizationRequest.builder()
    .requestOfflineAccess(webClientId)
            .setRequestedScopes(requestedScopes)
            .build();
    Identity.getAuthorizationClient(activity)
            .authorize(authorizationRequest)
            .addOnSuccessListener(
                authorizationResult -> {
                  if (authorizationResult.hasResolution()) {
                    // Access needs to be granted by the user
                    PendingIntent pendingIntent = authorizationResult.getPendingIntent();
                    try {
    startIntentSenderForResult(pendingIntent.getIntentSender(),
    REQUEST_AUTHORIZE, null, 0, 0, 0, null);
                    } catch (IntentSender.SendIntentException e) {
                    Log.e(TAG, "Couldn't start Authorization UI: " + e.getLocalizedMessage());
                    }
                  } else {
                    String authCode = authorizationResult.getServerAuthCode();
                  }
                })
            .addOnFailureListener(e -> Log.e(TAG, "Failed to authorize", e));

Das authorizationResult hat die getServerAuthCode() Methode, die den Autorisierungscode zurückgibt. Sie können ihn an Ihr Back-End senden, um ein Zugriffs- und Aktualisierungstoken zu erhalten.

In einer iOS-App auf Google APIs zugreifen

Clientseitiger Zugriff

Das folgende Beispiel zeigt, wie Sie unter 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. Dazu können Sie das Zugriffstoken in den Header einer REST- oder gRPC-Anfrage einfügen (Authorization: Bearer ACCESS_TOKEN), oder den Fetcher-Autorisierer (GTMFetcherAuthorizationProtocol) mit der Google APIs-Clientbibliothek für Objective-C für REST verwenden.

In der Anleitung zum clientseitigen Zugriff erfahren Sie, wie Sie clientseitig auf Google APIs zugreifen. In der Anleitung zum clientseitigen Zugriff erfahren Sie, wie Sie clientseitig auf Google APIs zugreifen.

Serverseitiger (Offline-)Zugriff

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

Hinweis: Für den serverseitigen (Offline-)Zugriffsmodus müssen Sie einen Server einrichten und einen öffentlich verfügbaren Endpunkt haben, um den Autorisierungs- code zu empfangen.

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 zum serverseitigen Zugriff erfahren Sie , wie Sie serverseitig auf Google APIs zugreifen.

Chrome-App-Client

Wenn Sie feststellen, dass Ihre App den OOB-Ablauf auf dem Chrome App-Client verwendet, sollten Sie zur Verwendung der Chrome Identity API migrieren.

Das folgende Beispiel zeigt, wie Sie alle Nutzerkontakte ohne OOB-Weiterleitungs-URI abrufen.

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 zum Authentifizieren von Nutzern und zum Aufrufen von Google Endpunkten mit der Chrome Identity API finden Sie in der Anleitung zur Chrome Identity API.

Webanwendung

Wenn Sie feststellen, dass Ihre App den OOB-Ablauf für eine Webanwendung verwendet, sollten Sie zu einer unserer Google API-Clientbibliotheken migrieren. Eine Liste der Google API-Clientbibliotheken für verschiedene Programmiersprachen finden Sie hier.

Die Bibliotheken vereinfachen den Zugriff auf Google APIs und verarbeiten alle Aufrufe an die Google-Endpunkte.

Serverseitiger (Offline-)Zugriff

Für den serverseitigen (Offline-)Zugriffsmodus müssen Sie Folgendes tun:

• Richten Sie einen Server ein und definieren Sie einen öffentlich zugänglichen Endpunkt (den Weiterleitungs-URI), um den Autorisierungscode zu empfangen.
• Konfigurieren Sie den Weiterleitungs-URI auf der Seite „Clients“ in der Google Cloud Console.

Das folgende Code-Snippet zeigt ein NodeJS-Beispiel für die Verwendung der Google Drive API zum Auflisten der Google Drive-Dateien eines Nutzers serverseitig, 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.
      });
    }
  }
}

In der Anleitung zur serverseitigen Webanwendung erfahren Sie, wie Sie serverseitig auf Google APIs zugreifen.

Clientseitiger Zugriff

Das folgende Code-Snippet in JavaScript zeigt ein Beispiel für die Verwendung der Google API, um clientseitig auf die Kalendertermine eines Nutzers 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 zur clientseitigen Webanwendung erfahren Sie, wie Sie clientseitig auf Google APIs zugreifen.

Desktop-Client

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

Hinweis: Für diese Implementierung müssen Sie auf einem lokalen Webserver (z. B. mit dem Apache HTTP Server) auf Anfragen warten, um den Autorisierungscode zu empfangen.