Übersicht
Am 16. Februar 2022 haben wir angekündigt, dass wir Google OAuth-Interaktionen durch die Verwendung sichererer OAuth-Abläufe sicherer machen möchten. Diese Anleitung hilft Ihnen, die Änderungen und Schritte nachzuvollziehen, die zur Migration vom Loopback-IP-Adressablauf zu unterstützten Alternativen erforderlich sind.
Diese Maßnahme dient dem Schutz vor Phishing- und App-Impersonation-Angriffen bei Interaktionen mit den OAuth 2.0-Autorisierungsendpunkten von Google.
Was ist der Loopback-IP-Adressen-Flow?
Der Loopback-IP-Adressablauf unterstützt die Verwendung einer Loopback-IP-Adresse oder von 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 schädliche Anwendung, die auf einigen Betriebssystemen auf dieselbe Loopback-Schnittstelle zugreift, die Antwort des Autorisierungsservers an die angegebene Weiterleitungs-URI abfangen und Zugriff auf den Autorisierungscode erhalten kann.
Der Loopback-IP-Adressen-Ablauf wird für die OAuth-Client-Typen iOS, Android und Chrome eingestellt, wird aber weiterhin in Desktop-Anwendungen unterstützt.
Wichtige Termine für die Einhaltung der Richtlinie
- 14. März 2022: Neue OAuth-Clients können den Loopback-IP-Adressablauf nicht mehr verwenden.
- 1. August 2022: Bei nicht konformen OAuth-Anfragen wird möglicherweise eine für Nutzer sichtbare Warnmeldung angezeigt.
- 31. August 2022: Der Loopback-IP-Adressen-Ablauf wird für Android-, Chrome-App- und iOS-OAuth-Clients blockiert, die vor dem 14. März 2022 erstellt wurden.
- 21. Oktober 2022: Alle vorhandenen Clients werden blockiert (einschließlich ausgenommener Clients).
Bei nicht konformen Anfragen wird eine für Nutzer sichtbare Fehlermeldung angezeigt. Die Nachricht informiert die Nutzer darüber, dass die App blockiert ist, und zeigt die Support-E-Mail-Adresse an, die Sie im OAuth-Zustimmungsbildschirm in der Google Cloud Console registriert haben.
Die Migration umfasst zwei Hauptschritte:
- Prüfen Sie, ob Sie betroffen sind.
- Wenn Sie betroffen sind, migrieren Sie zu einer unterstützten Alternative.
Prüfen, ob Sie betroffen sind
Typ der OAuth-Client-ID prüfen
Rufen Sie in der Google Cloud Console die Seite Clients auf und sehen Sie sich im Abschnitt OAuth 2.0-Client-IDs den Typ Ihrer OAuth-Client-ID an. Es handelt sich um einen der folgenden Typen: Webanwendung, Android, iOS, Universelle Windows-Plattform (UWP), Chrome-App, Fernseher und Geräte mit eingeschränkter Eingabe, Desktop-Anwendung.
Fahren Sie mit dem nächsten Schritt fort, wenn Ihr Clienttyp Android, Chrome-App oder iOS ist und Sie den Loopback-IP-Adressen-Ablauf verwenden.
Wenn Sie den Loopback-IP-Adressen-Ablauf auf einem OAuth-Client für Desktop-Anwendungen verwenden, müssen Sie nichts weiter tun, da die Verwendung mit diesem OAuth-Clienttyp weiterhin unterstützt wird.
So ermitteln Sie, ob Ihre App den Loopback-IP-Adressablauf verwendet
Prüfen Sie Ihren App-Code oder den ausgehenden Netzwerkaufruf (falls Ihre App eine OAuth-Bibliothek verwendet), um festzustellen, ob die von Ihrer App gestellte 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 Weiterleitungsablauf mit einer Loopback-IP-Adresse 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>
Ausgehenden Netzwerkaufruf prüfen
Die Methode zum Prüfen von Netzwerkaufrufen hängt vom Clienttyp Ihrer Anwendung ab.
- 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.
- Klicken Sie rechts oben auf der Seite „Erweiterungen“ das Kästchen Entwicklermodus an.
- Wählen Sie die Erweiterung aus, die Sie beobachten möchten.
- Klicken Sie auf der Seite der Erweiterung im Bereich Ansichten prüfen auf den Link Hintergrundseite.
- Das Dialogfeld Entwicklertools wird geöffnet. Dort können Sie den Netzwerkverkehr auf dem Tab Netzwerk beobachten.
- iOS – HTTP-Traffic mit Instruments analysieren
- Desktop-Apps: Verwenden 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 Autorisierungsendpunkte von Google OAuth gesendet werden, und prüfen 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 Weiterleitungsablauf mit einer Loopback-IP-Adresse 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 und iOS)
Wenn Sie feststellen, dass Ihre App den Loopback-IP-Adressen-Vorgang mit einem Android- oder iOS-OAuth-Clienttyp verwendet, sollten Sie zu den empfohlenen SDKs (Android, iOS) migrieren.
Das SDK unterstützt Sie beim Zugriff auf Google APIs und verarbeitet alle Aufrufe an die OAuth 2.0-Autorisierungsendpunkte von Google.
In den folgenden Dokumentationslinks finden Sie Informationen dazu, wie Sie die empfohlenen SDKs verwenden, um auf Google APIs zuzugreifen, ohne einen Loopback-IP-Adress-Weiterleitungs-URI zu verwenden.
Auf Google APIs unter Android zugreifen
Clientseitiger Zugriff
Das folgende Beispiel zeigt, wie Sie mit der empfohlenen Android-Bibliothek für Google Identity Services auf der Clientseite unter Android auf Google APIs zugreifen.
List<Scopes> 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 die authorizationResult an Ihre definierte Methode, um Inhalte im Drive-Ordner des Nutzers zu speichern. authorizationResult hat die Methode getAccessToken(), die das Zugriffstoken zurückgibt.
Serverseitiger (Offline-)Zugriff
Im folgenden Beispiel wird gezeigt, wie Sie auf Android-Geräten serverseitig auf Google APIs zugreifen.
List<Scopes> 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));
authorizationResult hat die Methode getServerAuthCode(), die den Autorisierungscode zurückgibt. Diesen kannst du an dein Backend senden, um ein Zugriffs- und Aktualisierungstoken zu erhalten.
In einer iOS-App auf Google APIs zugreifen
Clientseitiger Zugriff
Das folgende Beispiel zeigt, wie Sie auf iOS-Geräten 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 das Zugriffstoken in den Header einer REST- oder gRPC-Anfrage (Authorization: Bearer <var>ACCESS_TOKEN</var>) ein oder verwenden Sie den Fetcher-Authorizer (GTMFetcherAuthorizationProtocol) mit der Google APIs-Clientbibliothek für Objective-C für REST.
Informationen zum clientseitigen Zugriff auf Google APIs finden Sie im Leitfaden für den clientseitigen Zugriff.
Serverseitiger (Offline-)Zugriff
Das folgende Beispiel zeigt, wie Sie serverseitig auf Google APIs zugreifen, 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
}Informationen zum Zugriff auf Google APIs von der Serverseite finden Sie im Leitfaden für den serverseitigen Zugriff.
Chrome-App-Client
Wenn Sie feststellen, dass Ihre App den Loopback-IP-Adressen-Ablauf auf dem Chrome-App-Client verwendet, sollten Sie zur Chrome Identity API migrieren.
Im folgenden Beispiel wird gezeigt, wie Sie alle Nutzerkontakte ohne Verwendung eines Loopback-IP-Adress-Weiterleitungs-URI abrufen.
window.onload = function() { document.querySelector('button').addEventListener('click', function() { // retrieve access token chrome.identity.getAuthToken({interactive: true}, function(token) { // .......... // the following example 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 im Leitfaden zur Chrome Identity API.